This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS570LC4357: I2C Master reads set the flag before the data is available

Part Number: TMS570LC4357


Dear Sirs.

We are having an issue with our implementation of the I2C while reading data from an external ADC.

The sequence is:

1) Set I2C Slave Address

2) Set Mode to I2C Master

3) Set Direction to I2C Transmitter

4) Set Start

5) Send the Address

6) Check I2C_TX_INT in i2cREG1->STR

7) Read i2cREG1->DRR to clear the flag

8) Set Start

9) Set Direction to I2C Receiver

10) Receive 2 bytes from the ADC

11) Set Stop

12) Receive last byte (3rd)

13) Clear SCD

This algorithm works fine for many hours, but sometimes, in step 10, the Rx flag is set (cleared in step 7) before the actual byte has arrived to the I2C module, resulting in a reading of 0x00.

The result is that instead of reading byte1-byte2-byte3 we read 0x00-byte1-byte2, resulting in a bad ADC reading.

I've tried to change the sequence 7-9 so the flag gets reset just before entering 10), same result.

So it seems like the I2C module is setting the Rx flag erroneously.

Any clue on why this may happen and how to solve it?

Thank you

  • Hi,

    I think the #9 and #8 should be swapped. Why is the #11 placed before reading the 3rd byte?

  • Hi Wang.

    First I have to tell that it was really difficult to find a library or good documentation about how to use the I2C peripheral. The implementation took me some time and is based on some code examples that I found in the Internet (including TI I2C Master demo code) and on-target experimentation.

    Swapping #9 and #8 is indeed something that I figured out and tested, but it did not improve the result, the issue remains there.

    I also moved #7 after #8 to let less time for the I2C module to falsely set the Rx flag. Same result.

    Regarding #11 before reading the last byte, that's what I understood that has to be done. Tell the I2C module to send a stop when it receives the last byte before it actually occurs. It works fine as it is and I don't believe it can be related to the reported issue, but if it's not really needed, the code would be cleaner without that odd trick.

    Note that this function is executed every 20ms and we have to leave the system working for hours in order to catch a fault. So the probability of occurrence is very low and it's therefore very difficult to debug. I'd rather like to have this code based on good documentation instead of trial and error.