• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 83 subscribers
  • Views 197 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:

TMS320F280048C-Q1: I2C not able to generate stop condition

TMS320F280039: I2C SCL Line Stuck Low and Stop Condition Not Triggering

Ardavan Pourkeramati
Prodigy 20 points

Part Number: TMS320F280039

Hello,

I have written an I2C driver based on i2c_ex2_eeprom.c, and I am facing an issue with the SCL line becoming stuck low. This is an intermittent issue occurs somewhat randomly. 

When this occurs, I notice the final message before faulting is correct (using logic analyzer), except that the stop condition does not occur.

I believe this is similar to the issue found here: https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1447879/tms320f280048c-q1-i2c-not-able-to-generate-stop-condition

I have noticed that this issue does not occur when the SYSCLK is 120MHz. However, I encounter it with a SYSCLK of 72MHz.


Was this issue ever resolved internally? Thank you in advance.

  • 0
    TI__Expert 4110 points

    Hi, 

    The expert is currently out of office, please expect a response when they return to office next week.

    Kind regards,
    AJ Favela 

  • 0 in reply to AJ Favela
    Prodigy 20 points

    Hi AJ,

    Thank you for the message. I look forward to hearing from them. Are they back on Monday?

    Best,

    Ardavan

  • 0
    TI__Mastermind 21495 points

    Hi Ardavan,

    Thank you for your patience while I was out of office. I will get back to you by tomorrow on this, thank you.

    Best Regards,

    Aishwarya

  • 0 in reply to Aishwarya Rajesh
    Prodigy 20 points

    Hello Aishwarya,

    Sounds good, thanks. I just wanted to note that this problem does not occur when the sysclk is 120MHz. I only see this issue happening when I reduce the sysclk to 72MHz. I will add this to the main post as well. Thanks.

  • 0
    TI__Mastermind 21495 points

    Ardan,

    Noted, let me take a look at this.

    Best Regards,

    Aishwarya

  • 0
    TI__Mastermind 21495 points

    Ardan,

    I'm still looking into this issue. Do you have a scope shot that more clearly shows the rise, setup, hold, fall, etc. times. Can you confirm the I2C FSM clock, baud rate, and related clocking configurations? The FSM clock should be in the 7-12 MHz range to properly meet timing requirements, and it is possible with your clock dividers, the FSM clock value @120 MHz is more precise than @72 MHz. The I2C_initController() function also assumes a nominal FSM clock freq = 10 MHz.

    In addition, make sure to replace any CPU-cycle timeout loops (ie. for loops) with I2C status checks (ex. while (I2C_getStopConditionStatus(myI2C0_BASE))) as this can cause variations as well. 

    Best Regards,

    Aishwarya

  • 0 in reply to Aishwarya Rajesh
    Prodigy 20 points

    Hello Aishwarya,

    Thank you for your detailed response. By FSM clock I assume you mean the I2C module clock, is that correct? I have already checked that with a 72MHz clock, the module clock is within 7-12MHz (as per the reference manual).

    Also, I have tried infinitely polling the I2C stop condition status (like what you have added here), and it does not fully solve the issue. Have you been able to run the i2c_ex2_eeprom.c on your end with 72MHz?

  • 0
    TI__Mastermind 21495 points

    Ardavan,

    As requested above, can you send me your exact clocking configurations and confirm via scope shot if the timing requirements are being met? Can you try using an exact FSM clock, so PSC = 8 and try the results?

    Ardavan Pourkeramati said:
    Also, I have tried infinitely polling the I2C stop condition status (like what you have added here), and it does not fully solve the issue.

    Can you elaborate what "it does not fully solve the issue" mean? Are you using any device_delay_us() or loop counters still?

    Unfortunately, I'm unable to run the example on my end right now. 

    Best Regards,

    Aishwarya