• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 51 subscribers
  • Views 514 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.

Original question:

RTOS/CC2640R2F: I2C working but stuck after a while when doing successive write

RTOS/CC2640R2F: FALSE I2C MSTAT.BUSBSY

m w
Intellectual 360 points
Part Number: CC2640R2F

Tool/software: TI-RTOS

I seem to have a problem where I am getting false  I2C MSTAT.BUSBSY flags.

I have two devices on the I2C bus.  I regularly open and close the I2C to access these devices.  I seem to occasionally get the I2C MSTAT.BUSBSY bit set (causing the ti driver to abort the transfers).  I access one device every 200ms the other every 3-5 seconds.

  1. I have check the previous I2C transaction on a SCOPE and it executed properly.  When the error happens, there is no activity on the I2C bus... both SDA and SCL are high
  2. I found that if I disable the software for one of the I2C devices, the other one works fine.
  3. I also have an LCD driver on SPI.  if I disable the SPI driver the two I2C devices work fine.
    1. Note I have no data traffic on the SPI bus, just the act of having the SPI device open causes the error.
  4. I have tried operations at both 100 and 400KHz
  5. I have verified I have no stack or heap errors.

Any suggestions on where the problem could be?

  • 0
    TI__Mastermind 22935 points

    It sounds like there is a misuse somewhere along the way. There may be something wrong in the way you are handling multiple peripherals that cause their functionality to stop. If you can include code related to I2C and SPI I can better assist you.


    Out of curiosity, is there any pins are being shared for this functionality?

    Regards,

    Jesus

  • 0 in reply to Jesu
    Intellectual 360 points

    There are no pins that have shared functionality.  The scope plots from before the problem also look good, so I believe the problem is strictly on the cc2640r2f side (not the peripheral)

    Unfortunately the code is part of a much larger project and is also integrated with I2S operations(reconfiguring I2S codec every 200ms).   I am not sure if I can isolate the code very well.  I will see what I can do about getting you the relevant snippets.

    Another note: I have changed the LCD code so the SPI interface is only open when it needs to write to the LCD(rather than always open as in the TI examples), so the SPI and I2C interfaces are never open at the same time.  This seems to prevent (hide?) the problem.

  • 0 in reply to m w
    TI__Mastermind 22935 points
    Your note towards the end correlates with my original response. The fact that you're peripherals are working independently of each other and not when you put it all together leads me to believe there is a misuse somewhere in your firmware.

    Would it be possible to isolate the problem by creating a separate project that only uses SPI and I2C? If so, that would make it a lot easier to debug.