• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 40 subscribers
  • Views 406 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.

LAUNCHCC3220MODASF: Problem with I2C communication.

Carlos Takahashi
Intellectual 430 points
Part Number: LAUNCHCC3220MODASF
Other Parts Discussed in Thread: CC3220SF

Hello support team.

I am communicating the CC3220SF with a FRAM memory and an RTC via I2C.
I'm using TI-RTOS and the Texas Instruments I2C driver.
The frequency of the I2C is 400 KHz.
Communication with both devices works only after a few seconds.
I am using the I2C_transferTimeout function, when the error occurs, the function's return is I2C_STATUS_ERROR.
I took a look at the Texas I2C.c driver code but found no clues to the problem.
I connected a Logic Analyzer to the I2C pins and a trigger signal on a led that I called "BLU".
I programmed the "BLU" led to go up when the I2C_transferTimeout function returns I2C_STATUS_ERROR.
The figure is from a transfer with FRAM.
In this transaction I configured:
Slave address = 0x50;
Number of write bytes = 2, these two bytes being the address of the FRAM memory to be accessed 0x00 and 0x18;
Number of reading bytes = 6, in this case it is 6 bytes from address 0x0018 that will be read.

In the figure below, I placed a capture at the top, when the communication was successful, and at the bottom, when the error occurred.

The two parts of the figure are from the same capture, the upper part around 19.3 ms and the error occurring around 49.9 ms.

The difference I noticed was that after sending the address to FRAM,:
1 - only ACK (A) occurs and CC3220SF does not perform Repeated Start (Sr);
2 - for some reason the I2C bus is kept idle without SCL clock;
3 - after a period of almost 2 bytes, STOP (P) occurs;
4 - after a while, START (S) occurs;
5 - The address of the slave is placed for reading and the same data seen at the top is sent by the FRAM;
6 - however the I2C_transferTimeout function returns I2C_STATUS_ERROR, triggering the BLU signal.

After this error, all subsequent transactions indicate I2C_STATUS_ERROR.
I noticed that even restarting the debugging, the problem remains and I need to do a Power On Reset. I don't know any of the devices are holding the I2C bus.
I also tested with the I2C_transfer function and the same symptom occurs, after a while, the function returns false and looking at the logic analyzer the behavior is similar.

I'm using CCS 10.3.0.0000007 and SimpleLink CC32xx SDK 5.10.0.02.

I also put an image with the I2C registers at the moment the problem occurs.

Thanks for any help.

  • 0
    TI__Mastermind 40965 points

    Hi,

    Thanks for providing your detailed debug info. Looking through the I2C registers, these were the notes I had:

    Bus in RX mode
    no clock timeout error, bus appears to be idle [MCS]
    RX FIFO full, STOP detected, interrupts pending [MRIS]
    no interrupts masked, interrupts disabled? [MIMR]
    SDA, SCL detected high [MBMON]
    6 byte burst [MBLEN]
    burst complete [MBCNT]
    all I2C slave regs 0, only master mode active (correct)
    FIFO has 0x0 - unclear whether no data, or simply current byte is 0x0
    RX FIFO triggered when 6+ bytes present. RX FIFO is not empty
    TX FIFO is empty

    That being said, I suspect that the registers above do not reflect the error condition are seeing, as depending on what error processing the drivers have already done the state may have changed since the I2C_STATUS_ERROR was returned.

    Looking at the drivers, it seems like the only plausible way that I2C_STATUS_ERROR is returned is if a clock timeout occurs. This would roughly line up with the register contents provided - looking at the driver if a clock timeout is detected, a STOP is issued and cleanup is performed.

    That being said, by default there shouldn't be a clock timeout enabled. Did you enable a SCL timeout? If so, what happens if you disable it?

    Regards,

    Michael

  • 0 in reply to Michael Reymond
    Intellectual 430 points

    Hi Michael, thanks for the tip.

    I was actually setting up the SCL timeout.
    When initializing the I2C interface, I was calling the I2C_setClockTimeout function.
    So the CNTL value of register I2CMCLKOCNT was indicating 2.
    I disabled the call to I2C_setClockTimeout, making the register I2CMCLKOCNT = 0.
    This really solved the problem, I left the program running for more than 1 hour with the logical analyzer the trigger did not fire.

    Thank you very much.