• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 54 subscribers
  • Views 1251 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.

CC1310: I2C not working after some time, SDA pin is low

Serious_man
Prodigy 110 points
Part Number: CC1310

Hi,

    I am using a custom cc1310 module. The slave is a MCP23017 IO expander.

1. The problem with I2C I am facing is

  • After some I2C transactions the bus stops working. When I checked the SDA pin it is in low logic level and SCK is high.
  • I checked I2C register MSTAT: BUSBSY and IDLE bits, both are 1.

A device reset gets back i2c to work and but the above issue occurs again.

FYI, I have tried using i2c in blocking and callback mode also tried different clock, with both i am facing this same type of state in the MSTAT register.

2. Can anyone brief about I2C error handling routine. Is it about monitoring different MSTAT bits and taking some corrective measures?

SDK version: 4.10.1.01

CCS: 10.1

Board : Custom board

LF_osc configured as LF clock derived from High Frequency XOSC

I2C pullups : 2k2

Thanks in Advance.

-Titus.

  • 0
    TI__Guru 58425 points

    Hi Titus,

    Sounds like you might get stuck in a NACK (can't see another reason for it other then the two device being out of sync). I would suggest you try (if not done so already) to lower the I2C clock and see if that solves it for you. You can also try to size up the pull-up resistors to 4k7 in case it is a "drive strength" related issue. 

  • 0 in reply to IUsedToBeARealPerson (M-W)
    Prodigy 110 points

    Hi M-W,

    Thankyou for your time :)

    The Clock is already working in 100kHz. I have changed the pullup to 4.7k. Still I am facing the same issue.

    MSTAT: BUSBSY and IDLE bits, both are 1 - Is this expected behaviour during I2C NACK.

    I tried closing and opening the I2C handle, but that did not work. After closing and opening I2C, MSTAT register stayed in the same state IDLE =1, BUSBSY = 1.

    Next might be to check for "Stuck at NACK" issue.

    May I know what workaround do you suggest for this problem? 

    With Thanks,

    -Titus.

  • 0 in reply to Serious_man
    Prodigy 110 points

    Hi M-W,

    I checked with logic analyser and found that last issued write transaction has ended with NACK and after this I2C has stopped working. 

    But other RF functions(like Tx and Rx) keeps on working.

    How to recover from this state and get I2c back to working.

    With Thanks,

    -Titus.

  • 0 in reply to Serious_man
    TI__Guru 58425 points

    Hi Titus,

    It would depend on the reason you end up here, for example, if it is the sensor being out of sync (imagine it missed a clock cycles for some reason) then you would need to manually clock it until it releases the SDA line again. You could try to "steal control" of the clock pin (using the IOC DriverLib APIs) and setup a "toggle loop" where you step over and toggle the pin a few times to see if this releases the SDA. While this might not be a good workaround, it would be a good test to see if it is the sensor locking the bus up.

  • 0 in reply to IUsedToBeARealPerson (M-W)
    Prodigy 110 points

    Hi M-W,

        I recreated the issue and disconnected the SDA line from slave while the pullup was still connected. I found that it is the CC1310 that holds the SDA line low. Anyway I will try your suggestion and get back

    With Thanks,

    -Titus.

  • 0 in reply to Serious_man
    TI__Guru 58425 points

    Hi Titus, 

    Can you recreate it on a launchpad without the slave? If so, could you share the project? There is no reason for the master to keep the SDA pulled down, could it be that your slave is stretching the SCL in your case?

  • 0 in reply to IUsedToBeARealPerson (M-W)
    Prodigy 110 points

    Hi M-W,

       1.  I will try to recreate using launchpad.

       2.  If the slave is stretching the clock, SCL pin should be held in low level(please correct me if I am wrong), but in my case SCL is high and only SDA pin is held low and it stays low. 

    I recently noticed that this situation with I2C module occurs only when I am switching 220VAC load through relay. But other functions like RF tx rx still works while I2C stops. That was weird. If I disconnect those AC power lines from relay terminals the soc works just fine. 

    So this may be related to emi interference and changes in layout might help. 

    I am considering that this thing also needs to be handled in the software. Is it possible to power down whole I2C module in a way it clear all its register values?

    With Thanks,

    Titus.

  • 0 in reply to Serious_man
    TI__Guru 58425 points

    Hi Titus,

    2) You are correct, guess that is not the issue but that it might be EMI related as you suggest.

    As for the "clear" of the I2C module, there is really only one way to fully reset it and that is to power cycle the domain it is in. That will typically only happen if you go and out of standby but it does depend a bit on which peripherals you use. Either way, there is no clean "reset the I2C" signal that you can pull. You could try to close the driver and use the DriverLib APIs (basically register access) to force it out of the state. One thing you could try is to close it and then manually issue START/STOP conditions and see if it clears up.