I have a question on using the I2Cmodule. I am writing the driver for an I2C EEPROM and I need to do the following for performing a read operation on the EEPROM. Note that after sending the address of the byte I want to read, I have to send a start again (without a preceeding stop). This doesn’t seem to be possible in I2C module.

How I am trying to achieve this is by doing two transactions on the I2C bus. First to write the “Byte addr” bytes. This I am ending without a STOP bit. The next to read the data byte.

You don’t want to know the reason as it does not add to your knowledge. The phenomenon operating here was optical illusion. When there are pins around the ground pin, you can end up connecting a non-connected pin to ground, thinking you have connected the ground pin to ground.

Fix that and it starts to work.

Thanks for investigations and spending the time and your responses. I appreciate.

Now my understanding is that a repeated start means when a "start" is sent without a "stop" preceding it. I now think I was doing it wrong earlier. So I changed the red colored code below to "masterXfer.flags = kI2C_TransferRepeatedStartFlag". With this, I see that the read is sent on the bus. Now the problem is that no data is returned.

See the appendix of http://www.utasker.com/docs/uTasker/uTasker_I2C.pdf for details about the issue and the way to work around it.If you would like an immediate and complete solution proven in many industrial products using double-buffered I2C Kinetis parts just use the uTasker Open Source project (link below) which also simulates your chip and the I2C operation.

Thanks for this information. So my understanding is that this is a bug in the microcontroller's I2C module.

I have to admit that I don't completely understand the cause and hence don't know how to handle it. It seems that I have to either integrate uTasker in my project which would be quite risky to do at this stage or do a manual workaround in the SDK which I don't prefer doing.

If you or NXP can send me changed and validated SDK files for the I2C driver (fsl_i2c.c) with this workaround implemented, it will be much helpful.

You will need to contact NXP since I don't work with the SDK. In case of emergencies I can correct code and validate operation but this will need a contact which can be arranged at http://www.utasker.com/services.html

I figure out from the Appendix you shared that the typical issue is that the i2c master, after sending the repeated start sends a wrong slave address. But this doesn't seem to be happening in my case. Here it seems to be that I am able to read but the slave is not returning the right information.

In this, I write 0xAA at address 0x0004 and then try to read address 0x0004. What do you think could be wrong here? Do you think its the double buffering bug? how?

I am not sure whether this is a chip issue, driver issue or application issue yet but it looks like your write doesn't correspond to what you display in the initial post. There you show that you wantW50, 0, 4, W50, AAbut your oscilloscope is displaying W50, 0, 4, AA, which is different because the slave is never being addressed for the data write (the second W50 is missing).In this case it may be normal that the read is a 0xff since you haven't written anything yet.

If you intended to send the second W50 between the 4 and the AA if could be the chip bug where the second start address is lost (as noted in the appendix of the uTasker I2C document).

"If the addressed location is Write-protected, by Write Control (WC) being driven high, thedevice replies with NoAck, and the location is not modified. If, instead, the addressedlocation is not Write-protected, the device replies with Ack."

The oscilloscope is showing correct operation on the bus but the slave is responding with 0xff.

In this case the question is whether you can believe the oscilloscope's interpretation - I would look at the SDA/SCL signals directly to check the start, stop, ack, nack, timing etc. If all is correct it is not a I2C driver/chip issue but something at the slave.

I am also printing the value that I read from the slave on my UART terminal. it is 0xFF.

BTW I am using repeated-start for the read. With that in mid, do you think what I see on the scope is correct in the sense that the issue that you know of, which is described in you uTasker documentation is not present here in the read?

Maybe the EEPROM requîres a STOP condition to start writing the data (meaning a repeated start after the write could be wrong)?Also, after you have written something to an EEPROM it may take several ms before it has been programmed - usually one polls its status register until it shows that it is no longer busy before reading.I don't see I2S bus problems at the moment and the application is more likely to be the issue.

When the bus master generates a Stop condition immediately after a data byte Ack bit (in

the “10th bit” time slot), either at the end of a Byte Write or a Page Write, the internal Write

cycle tW is triggered. A Stop condition at any other time slot does not trigger the internal

Write cycle.

A repeated start will presumably effectively cancel a write before it starts.

Also, the user's manual discusses how to poll for the write to complete in 5.1.6.

I also agree that, from 5.2.1, a repeated start is required (must be used) when reading.

From 5.1.1. the write address plus the data should be written in one single I2C frame. It doesn't state that it won't work if a repeated start is used but it is not the method that is explained and possibly will fail. Sending as two write frames looks to be incorrect since the second one's data will presumably be understood as a part of a new address and not as data.

Therefore it looks like the present problem is at the application level where there are one or more errors as it is being performed at the moment.

You don’t want to know the reason as it does not add to your knowledge. The phenomenon operating here was optical illusion. When there are pins around the ground pin, you can end up connecting a non-connected pin to ground, thinking you have connected the ground pin to ground.

Fix that and it starts to work.

Thanks for investigations and spending the time and your responses. I appreciate.