• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 31 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.

AM2434: TI's i2c driver gets stuck in some situations

Peta
Prodigy 30 points

Part Number: AM2434
Other Parts Discussed in Thread: SYSCONFIG

Hi,

We are using TI's lld for I2C on AM243x to read out data of a bunch of ICs on a custom board. Some of these ICs are supplied by a separate power supply that can be switched off by the user. In that case the device is not available on I2C, of course. Sometimes this leads to a situation where the driver code gets stuck. We are using mcu_plus_sdk_am243x_11_01_00_19 .

To narrow it down I was able to reproduce it with a modified TI example and the AM243x launch pad.
Example: i2c_temperature_interrupt_lld_am243x-evm_r5fss0-0_nortos_ti-arm-clang
I attached the changed files i2c_temperature_interrupt_lld.c and a picture of the logic analyzer:

i2c_ti_stuck.png

I run the code on a launch pad without temperature sensor. I get this output:

[I2C] I2C Temperature Read test Started in interrupt mode ... !!!
ERROR: i2c_temperature_main:105: [I2C] Temperature sensor not found at device address 0x48 
[I2C] Sample 0: 0.000000 (celcius)
[I2C] Sample 1: 0.000000 (celcius)
[I2C] Sample 2: 0.000000 (celcius)
[I2C] Sample 3: 0.000000 (celcius)
[I2C] Sample 4: 0.000000 (celcius)
[I2C] Sample 5: 0.000000 (celcius)
[I2C] Sample 6: 0.000000 (celcius)
[I2C] Sample 7: 0.000000 (celcius)
[I2C] Sample 8: 0.000000 (celcius)
[I2C] Sample 9: 0.000000 (celcius)
[I2C] Sample 10: 0.000000 (celcius)

From here the code get's stuck. 

My changes in code does the following:
It jumps over the check for the device address due to the reasons I stated above.
It simulates an ISR with higher priority or a code region with disabled interrupts of 8us right at the end of the transmission of the first byte, the device address.
This period of time is shown by the signal J1_8_PIN in the attached picture.
After this the transfer complete callback is not called and the loop around the mutex will not be left.

My questions:
Is this intentional behavior?
How can I avoid or break this situation?
How do I get aware of a failed transaction? 
Thanks in advance.

  • 0
    TI__Guru 63478 points

    Hi,

    I can see that you have not connected any sensor to the I2C and the I2C Probe fails and the logs are coming no sensor found.

    Also you have tried reading 10 samples and then disabling the interrupts for 8 us and then re-enabling it. 

    Question here is, Is this issue only coming after you disable the interrupts? Also Is this coming only if we have 8 us delay or is it independent of it?

    Also instead of disabling all interrupt have you tried reproducing it with only disabling the I2C interrupt?

    Regards,

    Tushar

  • 0 in reply to Tushar Thakur
    Prodigy 30 points

    Hi Tushar,

    Thank your for your quick response. The issue is only coming after disable the interrupts. In the example it is at a fixed point in time. In our real use case this occurs sporadically depending on other tasks that disable interrupts for a short time span. I arranged the 8us at the end of the i2c transfer because I assumed that the driver code misses (or clears) interrupt requests at this specific point in time. No, I did not try to disable i2c interrupt only. For my use case I only have minimal control what the other tasks do.

    Regards,
    Peter

  • 0 in reply to Peta
    Prodigy 30 points

    More precisely: The issue occurs only if no device acknowledges the transmitted device address (NAK) and there  are interrupts disabled at the end of the transmission of the device address.

  • 0
    TI__Guru 63478 points
    Peta said:
    After this the transfer complete callback is not called and the loop around the mutex will not be left.

    Have you configured the I2C in callback mode? Have you also tried with blocking mode as well?

    Regards,

    Tushar

  • 0 in reply to Tushar Thakur
    Prodigy 30 points

    My first approach was the HLD i2c driver in callback mode. With that setting I ran into the issue the first time. The issue occurs as soon as I enable the i2c interrupts in the sysconfig. Then it doesn't care if the transfer mode is callback or blocking. In both cases interrupts are used. Only if I disable the i2c interrupts in sysconfig I cannot observe the issue. But since I don't want to block code execution, this is no option for me. What I miss is an API service that polls if an i2c transfer is done, without blocking or interrupts. Btw: Were you able to reproduce my example?

  • +1 in reply to Peta
    TI__Guru 63478 points

    Hi Peta,

    In the I2C ISR we are processing all interrupts in one loop. It looks like in the driver code we are not calling the I2C_lld_completeCurrTransfer() API for Fatal Errors. Please apply the below patch which will modify the I2C_lld_controllerIsr() API found at ${MCU_SDK}\source\drivers\i2c\v0\lld\i2c_v0_lld.c file.

    diff --git a/source/drivers/i2c/v0/lld/i2c_v0_lld.c b/source/drivers/i2c/v0/lld/i2c_v0_lld.c
index 06340347a..a9943563d 100644
--- a/source/drivers/i2c/v0/lld/i2c_v0_lld.c
+++ b/source/drivers/i2c/v0/lld/i2c_v0_lld.c
@@ -1433,6 +1433,10 @@ void I2C_lld_controllerIsr(void *args)
                 I2CControllerIntEnableEx(object->baseAddr, I2C_INT_STOP_CONDITION);
                 /* Issue the stop condition */
                 I2CControllerStop(object->baseAddr);
+            
+                /* Finish current transfer */
+                I2C_lld_completeCurrTransfer(object, xferStatus);
+                
                 /* Breat out of the interrpt Loop */
                 break;
             }

    After applying the above patch, rebuild the drivers. After this rebuild the example project and test. 

    The above procedure should resolve the issue above.

    Regards,

    Tushar

  • 0 in reply to Tushar Thakur
    Prodigy 30 points

    Hi Tushar,

    Sorry for my late response. I was out of office a couple of days. Your patch resolves the issue. Thank you.
    Will the patch be part of the next SDK?

    Best Regards,
    Peta

  • 0 in reply to Peta
    TI__Guru 63478 points

    Hi Peta,

    Thanks for the above confirmation. The internal code freeze for the next SDK release is already done and will not accept any new changes. This patch cannot be integrated to the next SDK release. I have created an internal Jira ticket for the issue and will most likely be fixed by SDK v12.1.

    Regards,

    Tushar