• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 285 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

AM625: I2C controller becomes stuck with SCL low

AM623: I2C controller becomes stuck under high load

M K
Prodigy 50 points
Part Number: AM623


Tool/software:

Hello,

We run into the same problem as in the linked original post.

Since then some time has passed and I wanted to check, whether there are any known issues with the controller in stress scenarios?

We have a TQMa62xx SOM with AM6234, not running Linux, but an RTOS with our own I2C driver (polling mode).

During normal operation, driver checks "bus busy" BB == 0, then starts transfer. New bytes are indicated either by XRDY (transmit ready) or RRDY (receive ready).
At the end ARDY (access ready) indicates the completion and that the configuration registers can be written for the next transfer.
Under normal conditions all I2C communication is working fine.

During the stress test we see XRDY being set during read operation (0x1410/0x1010) and ARDY not getting set.
Viewing it on an oscilloscope, SCL gets stuck low in this case (as in OP). After some time the SCL gets unstuck, but does not create a stable clock anymore, which probably lead to the spurious status bits.

CH1: SDA, CH2: SCL

The problem appears in a scenario of 3 or more threads running on 2 or more cores and each thread is either reading or writing continuously on the bus. 
The driver serializes the accesses to ensure that one transfer is completed before starting a new one.

Are there known hardware limitations which restrict the transaction frequency? If I insert a short delay in between the calls, everything works fine.
I will try to capture the SCL again to see if I can find at which point in a transaction the error happens.

Thanks.

  • 0
    TI__Guru 55928 points

    Hi,

    Which version of MCU+SDK are you using?

    M K said:
    The problem appears in a scenario of 3 or more threads running on 2 or more cores and each thread is either reading or writing continuously on the bus.

    Does the bus here means I2C_SDA line?

    M K said:
    The driver serializes the accesses to ensure that one transfer is completed before starting a new one.

    So, is it okay to assume that no simultaneous read/write are happening on I2C bus?

    M K said:
    If I insert a short delay in between the calls, everything works fine.

    Where are you keeping this delay?

    Regards,

    Tushar

  • 0 in reply to Tushar Thakur
    Prodigy 50 points

    Hello,

    Tushar Thakur said:
    Which version of MCU+SDK are you using?

    The firmware we use is from MCU+SDK 09.01.00. For application development we use our own driver without the SDK.

    Tushar Thakur said:
    Does the bus here means I2C_SDA line?

    Yes.

    Tushar Thakur said:
    So, is it okay to assume that no simultaneous read/write are happening on I2C bus?

    Yes, the code only allows a single thread access to the hardware until it finishes its transaction.

    Tushar Thakur said:
    Where are you keeping this delay?

    As a quick workaround the delay is currently on application level between the calls to the driver.

    Latest investigations show, that it may be related to the creation of start and stop conditions off the controller. While the driver always sets STT and STP in the control register to create both start and stop conditions, at one point a repeated start condition is visible.
    After this occurence the controller does not continue clocking SCL: 

    I continue analyzing the behavior.

    Regards.

  • 0 in reply to M K
    TI__Guru 55928 points

    Hi

    M K said:
    While the driver always sets STT and STP in the control register to create both start and stop conditions, at one point a repeated start condition is visible.

    What is the state of I2C when the issue occurs?

    Is the repeated start condition triggered by custom driver you have implemented? 

    Regards,

    Tushar

  • 0 in reply to Tushar Thakur
    Prodigy 50 points

    Hello Tushar,

    Tushar Thakur said:

    What is the state of I2C when the issue occurs?

    Is the repeated start condition triggered by custom driver you have implemented? 

    From my understanding a repeated start condition is created when I set STT but not STP in the control register and at a later point STT | STP. Our driver always sets both STT and STP, so I do not expect a repeated start on the line. From the data on the bus in this case it looks like there is indeed a conflicting access from two threads. Further analysis showed that they both can acquire the spinlock at the same time. So maybe it is not an I2C issue but more of a hardware synchronization issue.

    Regards

  • 0 in reply to M K
    TI__Guru 55928 points

    Hi M K,

    Thanks for confirming that issue is not with the I2C driver but with the synchronization between threads.

    Have you implemented the correct sequence to achieve hardware synchronization?

    Regards,

    Tushar

  • 0 in reply to Tushar Thakur
    Prodigy 50 points

    Hello Tushar,

    Tushar Thakur said:
    Have you implemented the correct sequence to achieve hardware synchronization?

    I thought that it was properly synchronized. Further analysis showed, that the locking was not completely atomic. After fixing it, only a single thread can access the bus and the error states do no longer appear.

    Thank you for your time.

  • 0 in reply to M K
    TI__Guru 55928 points

    Hi M K,

    Thanks for the above confirmation that issue is resolved. Closing the thread.

    Regards,

    Tushar