Hello,
I am using the RT632 as an I2C master to read data from an I2C slave device. The slave device, when active, interrupts the master (via a GPIO) once every 7ms. The master is then expected to read out 72 bytes of data from the slave via I2C. Out of 932 such 72-byte transfers, 4 such transfers failed. The failure signature is the same in all cases: when reading one of the 72-bytes from the slave, the RT632 I2C master NACKs one of the bytes received (usually the 31st byte).
The I2C master controller operates in programmed I/O mode. We initiate the read request to the slave and we get an interrupt for every byte received. We then get an I2C IRQ and our ISR sets an event. The worker thread picks up the event and services the I2C master controller by reading a byte out of its data register and setting the MSTCONTINUE bit in the MSTCTL. We keep track of the number of bytes received. When the Rx byte count reaches 72, we set the MSTSTOP bit in the MSTCTL to end the transfer.
Bytes 29, 30 and sometimes the 31st byte are read out incorrectly from the data register (MSTDAT). Please see the attached screen capture of the logic analyzer trace. Byte 0xB7 was read from the slave and it was NACK'd by the I2C master. I don't see anything obviously wrong with the LA trace to suggest why the I2C master would have NACK'd the transaction. The slave appears to do a fair bit of clock stretching but the same slave works fine with a different microcontroller (no NACK observed, clock stretching also observed.)
I think the I2C master can NACK a byte received if the software were to set the MSTSTOP bit in the master control register. I don't see a way for our software to do this but I will double check to make sure.
Can you think of a reason as to why the I2C master controller would NACK the byte in question?
