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.

RTOS/CC3200MOD: I2C Clock Glitch

Part Number: CC3200MOD
Other Parts Discussed in Thread: ADS1015, OPT3001, HDC1080, CC3200

Tool/software: TI-RTOS

Hi,

I am working on a custom PCB using PIN_02 and PIN_05 as the I2C lines.  I am seeing a glitch on the SCL line after 10-20 minutes when polling once per second (see below).

Screen Shot 2017-06-19 at 8.04.17 AM.png

In software I am getting stuck in I2CTransact(...):

while ((MAP_I2CMasterIntStatusEx(I2C_BASE, false)
			& (I2C_INT_MASTER | I2C_MRIS_CLKTOUT)) == 0) {
	}

I have three chips on the slave (HDC1080, OPT3001, and an ADS1015) with a pull-up resistor value of 2.7k Ohms (calculated using the following resource: http://www.ti.com/lit/an/slva689/slva689.pdf)

Here is what I have tried:

  • a larger pull-up value of 10k Ohms  
  • adding PinModeSet(PIN_01, PIN_MODE_0); to PinMuxConfig (processors.wiki.ti.com/.../CC32xx_Summary_of_Known_Issues)
  • using TI-RTOS and non RTOS environments
  • various power supplies 
  • 100KHz and 400KHz clock speeds
  • generating a pulse on the SCL line to unfreeze the slave before every transaction
  • clearing all interrupts  

I have scoured the forums to find another solution, but so far I've just come across unanswered problems.  I've yet to find anything from TI stating there is a problem with the chip itself so I'm not sure what the solution is.  Any help would be greatly appreciated.

Thanks,


Kyle

  • Hi Kyle,

    I think reason of your issue is that your I2C slave held SCL at low and it cause stuck in the I2CTransact(). The _if middle-ware libraries are not that bulletproof at all situations. Also this libraries not use interrupts and from this reason waste of CPU cycles.

    You should add some timeout into this I2C code and only in case of freeze generate SCL pulse. Error code in this case is I2C_MASTER_ERR_ARB_LOST.

    Jan
  • It appears to me that it does recover.  I will try adding the pulse just to be sure though.

  • Hi Kyle,

    OK, let me know.

    We don't use _if middleware libraries because we found that are in real application not reliable.

    Jan
  • Providing a timeout in the I2C transaction works okay, but it is a little concerning how frequent the clock gets locked up.  This may be okay for now, but it doesn't seem like a solution I want to sell to my customers. Additionally I have experienced some of my boards never recovering even after reconfiguring the pinmux and restarting the boards completely. Have you experience similar issues in the past?  I still have some suspicion that the root of this problem it trigged by my power management ICs as I wasn't able to replicate this issue with bench top power. 

    Thanks for you help Jan. This definitely helped.

  • Hi Kyle,

    According my experience recovery mechanism which I use is reliable. In my application I use interrupt driven I2C communication, but in this case this is not important. Mainly I see this issue when I stops code execution by debugger (reason is described bellow). My recovery mechanism (in case of communication issue/timeout with I2C peripheral):
    - set punumx at SCL to GPIO and output
    - generate some pulses on SCL (directly set hi and low level, it is not used pull-up in this case to driven high state)
    - set punmux back to I2C SCL
    - re-initialise I2C peripheral

    Issue with CC3200 I2C peripheral is that it is very smart. When state of bus (SDA, SCL) is changed, is physical state of bus read and when bus level is wrong, error code I2C_MASTER_ERR_ARB_LOST is returned. Reason for this behaviour are some "transitional states" inside I2C chip(s). I2C chip(s) internal logic can "stuck" in bad state when not receive all clock pulses, etc.

    Few reasons of potential issue:
    - problem with power supply of I2C chips (in your case it make sense)
    - not enough strong I2C pull-ups (please try use at least 3K3 pull-ups)
    - high capacitance of IC bus due to long cables (according images it not looks to your case)

    Jan