Dear TI team,
we believe we've found a bug in the I2C driver implementation that is used for the AM65x in processor SDK 06.01.
We're using the I2C driver to access an EEPROM device connected to I2C0 (i.e. main domain) both from the SBL and a TI-RTOS based application.
From within the TI-RTOS based application our code for accessing the EEPROM has been working fine from the beginning.
From within the SBL we got NACK errors from the driver.
The main difference between the two scenarios was that the application used interrupt mode, whereas the SBL used polling mode.
We debugged the driver code, and found that the I2C_primeTransfer_v1() implementation for the polling case unconditionally generates a stop condition after the writing part of the transaction is complete. The comments in the code suggest that the author was aware of this but we don't think the implementation is correct:
/* generate stop when requested */
I2CMasterStop(hwAttrs->baseAddr);
This code is executed unconditionally after the writing part of the transaction, causing our EEPROM to execute the internal write cycle, which takes ~5ms. The subsequent read then fails with a NACK from the device, since we didn't generate a re-START condition but a STOP-START condition.
The interrupt mode seems to work fine, although we didn't verify that it really generates the desired restart condition.
We fixed this for ourselves by executing the I2CMasterStop() and the following I2C_v1_waitForPin() waiting for the STOP condition only if there are no object->readCountIdx bytes in this transaction, but it would be nice to get confirmation that there was a bug and maybe have it fixed in a future version. I checked the PDK git and that part of the code still seems to be the same.
Regards,
Dominic
