• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 81 subscribers
  • Views 1270 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.

TMS320F28069: I2C Problem When NACK Is Not Followed by a STOP Condition

Runyu Cai
Prodigy 30 points

Part Number: TMS320F28069
Other Parts Discussed in Thread: C2000WARE

Thank you in advance for providing support for this issue!

 

During the prototyping of our product that utilizes the MCU (TMS320F28069PNT) as a master on a simple I2C bus, we have observed that not all NACKs (issued by slave) were followed by a STOP condition and whenever that happens the next transaction would demonstrate undesired behavior (a NACK that should be an ACK).  See attached figure.  We believe there are some corner cases that we did not consider in the firmware code.  Would you provide us with some robust I2C example code for handling NACKs and STOP condition during read/write? 

 

Please do not hesitate to ask us for more clarifications if needed and we will get back to you within 24h if not immediately. 

 

Runyu Cai

Electrical Engineer

Acutronic Actuation Inc.

Aerospace Components Division

 

Office:  +1 737 241 0559

Email:   rcai@acutronic.com

  • 0
    TI__Mastermind 45606 points

    Hi Runyu,

    You can review the I2C examples in C2000WARE, 'i2c_Lib_eeprom_interrupt' or 'i2c_Lib_eeprom_polling'. Directory location below:

    C:\ti\c2000\C2000Ware_4_01_00_00\device_support\f2806x\examples\c28

    Best,

    Kevin

  • 0 in reply to Kevin Allen18
    Prodigy 30 points

    Thanks Kevin,

    I debugged the example code [i2c_eeprom] on a launch pad (equipped the same MCU).  I used the targeted slave device AM4096 chip as the EEPROM for I2C bus to interact with.  I have captured some very strange behaviors as shown in figure below.

    A zoomed in and annotated version is below

        

    The core functionality of the code remains the same as in the original example, I just changed the slave address to 0x00 because that is the default address of AM4096, then I changed the EEPROM address to 0x01 and the message to 0x0000 & 0x001b (to confirm the message is indeed sent out).

    I do not understand why there is no STP signal/condition generated after performing the write action (prior to the second START signal/condition), the code says there should be a STP condition.

    Also, why the bus were pulled low after the burst, and the bus would not recover from the low state until I reset the launch pad.

    Last, why the {slave address (7bit) + read/write (1bit) + ACK (1bit) } section is repeated twice?

    Thank you! 

  • 0 in reply to Runyu Cai
    TI__Mastermind 45606 points

    Hi Runyu,

    AM4096 I2C protocol looks to just use a single memory address byte where the original example uses two (High/Low) Bytes. Maybe this difference still needs to be considered.

    Best,

    Kevin

  • 0 in reply to Kevin Allen18
    Prodigy 30 points

    Indeed, thank you Kevin.  Also there is actually a STP bit/condition once I look more at it.  The bus was stopped due to the slave device confusion. 

  • 0 in reply to Runyu Cai
    TI__Mastermind 45606 points

    Hi Runyu,

    You're welcome! Is the I2C communication and bus behavior as expected now? Let me know if you have any further questions.

    Best,

    Kevin