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.

INA233: I2C Data and Clock Lines Held

Part Number: INA233

Hello, 

We are having issues with the i2c communication on our i2c bus and it seems like one of the INAs on the bus is causing the issue. We are using the INAs as current and power monitors. We use command 89h to read the 2 data bytes that give us a current measurement. This seems to work fine. We also use 97h to give us the input power measurement reading. We also expect a 2-byte read from this. For most of the time these two commands work as intended. Once we engage a brake motor it seems like the INA233 that is reading that power measurement tends to hold the clock line high and the data line is held low. The bus is held in this state after this point. The only way to fix the issue is to power cycle the board. I am using a beagle to read the i2c communication on the bus and seems like the read I get back from the 97h command reads: FF 3B 00. We are receiving what the beagle says is 3 bytes back. This may be a different issue that is causing this problem, but thought I would post on here to see if anyone had an idea of what might be going on. Any thoughts would help. 

  • Hello Shaun,

    Thank you for using the TI forum. If the clock line is being held high, then it is likely that the problem is with the MCU. The INA233 does not control the clock, just data when the MCU is reading. If the clock line continues to operate, then the INA233 would be able to finish sending it's data. 

    Regards,

    Mitch

  • Hello Mitch, 

    Thanks for the reply! I am still very new to working with I2C, what might cause the MCU to hold that clock line and not continue to send signals? We are using a TM4C1294NCPDTI3 MCU. Is there some test that we could do that would help narrow down the issue?

  • Hello Shaun,

    It's hard to say specifically what could cause the MCU to hang up, based on how things are coded. You could try removing the INA233 to confirm/validate that it is not hanging up the communication, just in case. Also, you could take a scope shot of the communication and compare it to the timing diagram in the INA233 datasheet (section 7.5.6.3.2).

    Regards,

    Mitch