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 Driver + UART Driver in conjunction problem

Part Number: CC1310


Low Power RF Friends & Family,

Our customer has ran into an issue with the I2C driver.  They can use the I2C driver in isolation no problem, however if they want to use it in conjunction with the UART, they appear to run into a problem where it doesn’t shutdown cleanly. If they never shut it down, it works fine, but calling I2C_close/I2C_open results in the driver getting screwed up on the second open. The problem is with the BUSBSY bit in the MSTAT register under I2C0.  It should be 0 (idle) but gets stuck at 1 (busy) even though the bus is not in use. Note that the bit is 0 just prior to closing the I2C driver, the previous I2C transaction completes successfully. However on reopening the I2C driver it immediately has a BUSBSY of 1 and all transaction attempts fail immediately as a result (there is no signaling on the I2C lines at all). Trying to close and reopen the I2C driver doesn’t clear the bit either. However if the UART is closed, then the I2C will recover on the next cycle.

They have interestingly found that both the I2C and UART (also SPI) share the same power domain on the chip, apparently as long as one of them are active prevents any of the others from fully shutting down. Closing the driver then doesn’t fully shutdown the device and seems to cause problems. Also the driver interface doesn’t seem to have any sort of reset functionality that would allow the device to be cleanly reset. They haven’t yet tried direct register writes as they are concerned that could interfere with the driver.

 Have we encountered this type of problem before and if so, is there a way to resolve it?

TY,
CY

  • Hi Chris,

    This is a known issue and it is related to the state of the bus when closing it. Because the driver release the PINs before disabling the I2C module, the I2C module can go into "busy" mode when the PIN is released and get stuck here after being disabled.

    This mode is unfortunately not reset when disabling/enabling the module, this is only done when power cycled. This is why it works while UART is not active as the power domain is shutdown.

    There is a quick fix to this and that is to go into the I2CCC26XX_close call (add the I2CCC26XX.c file to the project) and move the "PIN_close" call to after the I2C module have been disabled. This does however not solve the issue if the bus was actually busy when closing.

    The better fix is to modify the I2CCC26XX_open function to send a I2C STOP condition before calling PIN_open. This is however a bit more complicated. This issue are being worked on but I would not expect it to be fixed in the upcoming Q2 SDK release.
  • M-W,

    Thanks so much for your reply and detailed input.  This should indeed offer some options to help mitigate the issue.

    TY,

    CY

  • M-W,

    Can you point me for our customer to the list of known issues including this particular one please? Just want to make sure they are on the same page.

    TY,
    CY
  • M-W,

    I should clarify.  As far as silicon Errata, we are already aware of the latest list:

    http://www.ti.com/lit/er/swrz062c/swrz062c.pdf

     I’d like to check on it from the software side of things too though – as you noted, from a SimpleLink SDK standpoint.

    Any comments welcomed.

    TY,

    CY

  • Hi Chris,

    The document overview for the SDK contains each components release not, in these most known issues and fixed bugs are listed:

    dev.ti.com/.../

    There could be a gap in some cases here in terms of listed known issues depending on when the bug entered the tracking system in relation to the SDK release. It should however be able to provide some overview on what have been fixed and if there is any major known issue currently in the SDK.
  • Thanks M-W, understood.  Appreciate your reply. Our customer was also specifically looking for the I2C errata and Henry and I are working to track that down. Of course, if you have that location handy please pass along too.

    Regards,

    Chris