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.

RM57L843: I2C Module issue where an intended I2C write appears as an I2C read on a bus periodically.

Part Number: RM57L843

Hi,

Our team has been encountering an issue after running for about 8 hours with successful regular I2C write/write-read/read transactions occurring every few seconds.

The issue shows up in an I2C write transaction to 0x23 where the TRX bit on the I2CMDR is set (as verified through a serial output) but the following is captured on a serial analyzer.

As you can see, the R/W bit is set signaling a READ which should not happen if the TRX bit is set.

Here is the intended transaction (captured a few seconds before this failure).

This bug can be reliably replicated after running the system for several hours. Based on the way our circuit is designed we are confident that it is the RM57 setting the R/W bit incorrectly.

Any help would be appreciated.

Best,

John King

Veo Robotics

  • Hi John,

    The data on the SDA line must be stable during the high period of the clock. The SDA can only change when the clock signal is low. The I2C specification says that the SDA setup time is >250ns, and hold time > 300ns. 

    Can you double check if the 8th bit (R/W) meets the 300ns hold time?

  • Hi QJ,

    Thanks for your response.

    This particular bit actually needs to be held LOW in order to be a `WRITE`. However I did check the timing and it is indeed held HIGH for more than the 300ns (see picture below).

    Best,

    John King

    Veo Robotics

  • Hi John,

    Thanks for your clarification.

    From your test data, the I2C module on this device delivers an incorrect level for W (write) bit. Is the previous I2C operation a READ or a WRITE? 

    Can you please share your test code and the method that you capture the error? I guess there is only one master in your setup. 

  • Hi John,

    Can you please share your test code and the method that you capture the error? I'd like to replicate the issue on my bench. Thanks