• State
  • Locked Locked
  • Replies 11 replies
  • Subscribers 42 subscribers
  • Views 417 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.

CC3220SF: No I2C communication

Mathias Vandel
Prodigy 70 points
Part Number: CC3220SF
Other Parts Discussed in Thread: BQ25601D

Hi TI, 

We are seeing a weird problem with I2C communication with CC3220SF. 

In 99% of the devices the I2C communication works flawless, however in some cases it doesn't.
The I2C bus interfaces to a BQ25601D battery charger, and a LTC2941 fuel gauge.

A sketch of the initialization code is as follows:
I2C_Init()
I2C_Params_init()
Handle = I2C_open()

Which is performing as expected, i.e. the handle is not equal to NULL.

The bus is initialized to Non-Blocking mode.
The actual transfer (I2C_transfer(Handle, I2C_Transaction)), doesn't work.

We simply do not see any communication at all on the bus. Both SDA and SCL is constantly 3.3V.
Since the I2C communication is done with Non-blocking mode, the I2C_Transfer() function always returns TRUE.

After a few days where the product was sitting on the bench, I turned on again the device again and the I2C bus had recovered and worked as intended. We have seen the problem in other devices as well, but haven't found a solution as it seems the error comes and goes.  

Do you know of any known errors with I2C and CC3220SF, where the I2C bus is simply not transmitting any data at all?  


Best,
Mathias Vandel

  • 0
    TI__Mastermind 38980 points

    Hi Mathias,

    Are you testing a LaunchPad or a custom board? What SDK are you using? Can you verify you are not setting those I2C pins as another peripheral (like GPIOs)?

    Best regards,

    Sarah

  • 0 in reply to Sarah P
    Prodigy 70 points

    Sarah P said:

    Hi Mathias,

    Are you testing a LaunchPad or a custom board? What SDK are you using? Can you verify you are not setting those I2C pins as another peripheral (like GPIOs)?

    Best regards,

    Sarah

    Hi Sarah, 

    I'm using a custom board, with 2.2k pull ups on the bus.

    SDK: 4.20. 

    Yes, the pins are only set as I2C pins.  

    Best,

    Mathias

  • 0 in reply to Mathias Vandel
    TI__Mastermind 46471 points

    Mathias,

    Have you tried increasing the resistor value? Here is an appnote that covers how to calculate I2C pull up resistor values.

    Can you share clear oscilloscope shots of the I2C signals when it works properly? 

    BR,

    Seong

  • 0 in reply to Seong Kim
    Prodigy 70 points

    Seong Kim said:

    Mathias,

    Have you tried increasing the resistor value? Here is an appnote that covers how to calculate I2C pull up resistor values.

    Can you share clear oscilloscope shots of the I2C signals when it works properly? 

    BR,

    Seong

    Yes, I tried to use a larger pull-up value - but without any difference. 

    I don't have a PCB that is failing at the moment, but the signal we see is a 3.3V DC, without any clock at all. 

    Best Regards,

    Mathias

  • 0 in reply to Mathias Vandel
    TI__Mastermind 46471 points

    Mathias,

    Are you saying that the I2C clock is stuck LOW? The I2C slave device work as state machines and may be blocked if the CC3220 was reset before sending a stop condition.

    An easy solution you can implement is to toggle the clock multiple times before doing any I2C operations after the CC3220 powers up. 

    BR,

    Seong

  • 0 in reply to Seong Kim
    Prodigy 70 points

    Hi Seong, 

    No, I'm saying that the SCL and SDA are pulled up to 3.3V and the CC3220 (or the slaves) are never toggled low when the communication should happen. 

    The issue is not permanent, i.e. 95% of the time the product boots up it works flawlessly... 

    Best,

    Mathias

  • 0 in reply to Mathias Vandel
    Guru 79945 points

    Hi Mathias,

    Just a comment. Information which you provided not make sense me. I think there are two options:

    • hardware issue - SCL or SDA line directly shorted to Ucc.
    • or there need to be visible some activity at SCL and SDA (some pulling low when SPI code is executed). In this case please use oscilloscope and check I2C levels and use logical analyser to show what is going on bus.

    It is not technically possible that CC3220 is functional with some I2C chips but some not together with properly pull-up of bus but no activity at bus (always SDA and SDL at HI).

    Jan

  • 0 in reply to Jan D
    Prodigy 70 points

    Hi Jan, 

    It doesn't make sense to me either, but my colleague and I have seen it with our own eyes.... 

    But what we see is a constant 3.3V on both SDA and SCL, and there is proper pull-ups on the bus. 

    But with the exact same FW, the exact same HW (the same CC3220), the I2C communication stops to work. After some time, the I2C communication magically starts to work again as expected. 

    We have seen this happening on ~5 devices now. 

    The I2C bus is communicating with a battery charger and a battery fuel gauge, and I'm starting to suspect that it happens when the battery is at a specific voltage/capacity. But still this would be weird, as I would assume that at least something would happen on the SCL/SDA line... 

    /Mathias

  • 0 in reply to Mathias Vandel
    Guru 79945 points

    Hi Mathias,

    Without sniffing I2C lines at moment of issue (and before them) will be hard to say what is going on.

    Just to be sure. In case of issue re-initialization of SPI peripheral does not fix issue, right?

    Jan

  • 0 in reply to Jan D
    Prodigy 70 points

    Hi Jan, 

    Indeed, but sniffing is boring in this case as it would be absolutely empty... 

    I haven't tried that, but will do soon. Thanks! 

    Mathias

  • 0 in reply to Mathias Vandel
    Guru 79945 points

    Hi Mathias,

    But from this reason you need sniff moment before issue. It could to be possible I2C peripheral is at error state, TI-driver failed somehow or you have other bug inside your code which cause malfunction (e.g. stack or buffer overflow).

    Jan