ST25DV Communication error when reading I2C

[MMoro.4]

Hello all

I use ST25DV64K.

If the I2C communication is normal, it returns ACK after receiving data, and after receiving the last data, it returns NACK response and issues Stop Condition.

If the I2C communication is abnormal, and the master issues a stop condition without returning a NACK response to the NFC tag, will the NFC tag be able to receive the stop condition normally?

Also, after the Stop Condition is issued, will the NFC tag be able to accept the next Start Condition normally?

Or will it not accept the next input data until the maximum value of TCHCL or TCLCH (25ms) has elapsed?

BR

Morooka

[JL. Lebon]

Dear Morooka,

In a normal I2C read transaction, the master is signaling to the slave that it doesn't want to read more data by sending a NACK on the 9th bit of the last byte received from the slave.

On the contrary, the master is signaling to the slave that it wants to read one more byte by sending a ACK.

If the slave is receiving a ACK, it means that it has to deliver one more byte. So, after the ACK condition, it will start to present the next byte on the next clock rising edge.

So, if the master is not sending a NACK, but instead is sending a ACK and then a STOP, here is what can happen: on the rising edge of the clock following the ACK, the slave will present on the bus the first bit of the next byte in memory (MSB bit)

Then, there is two possible cases:

1. The MSB bit of the next byte in slave memory is a 1: on the rising edge of the clock following the ACK, the slave will keep the SDA line "released" to transmit a 1. The master is then free to release the SDA line after SCL line goes high to send the STOP. Everything is working well in this case.
2. The MSB bit of the next byte in slave memory is a 0: on the rising edge of the clock following the ACK, the slave will drive the SDA line to low to transmit a 0 and keep it low as long as the SCL is high. Then the master will release the SDA line to 1 to signal the STOP, but it will not work as the slave is driving the line low. The SDA line will stay low, and the SCL line will stay high since the master is not driving it anymore after the stop => system will be "hang" until the 25ms timeout is trigged and the slave release the SDA line.

So, it is definitely a bad idea to send a ACK after last byte read and before the STOP, but in any case the situation will be recovered after 25ms thanks to the internal timeout of the ST25DV.

Hope this help and best regards.

[MMoro.4]

Thanks @JL. Lebon_O (ST Employee)

I understood that ST25DV Communication error when reading I2C

Thank you.

Best regards.