Hello,
I've been working on a framework for several devices and am using the TI-RTOS to split different tasks and make the overall operation simple to understand. My devices use the I2C interface and sometimes my framework would operate seemlessly and other time it would just freeze for no apparent reason.
After further investigation I found that the MSP430 creates a glitch on the first bit of the slave address for I2C transaction and some devices do not respond properly when that occurs. Here is a link to the E2E thread the details this glitch: MSP430 I2C glitch pulses causing trouble for I2C peripheral chip
I have confirmed this is the problem with a scope and fixed the problem by increasing the capacitance on my I2C lines which decreases the glitch enough that my part no longer has any issues. While I can increase the capacitance on the lines, this increases the rise times which isn't good either.
After digging through the TI-RTOSv2.12 I2C driver source code, I found that the reason my firmware would stall is the Hwi used an I2C function that doesn't use a timeout: (I2CUSCIB.c - I2CUSCIB_hwiIntFxn). This function calls USCI_B_I2C_masterReceiveMultiByteFinish() rather than USCI_B_I2C_masterReceiveMultiByteFinishWithTimeout().
I believe the Hwi routine should be updated to use the timeout function so that the firmware doesn't stall in the Hwi. Since it stalls in the Hwi the rest of the firmware dies because of the Hwi priority over everything else. Without the timeout in the Hwi it is impossible for the firmware to recover via software.
This behavior should count as a failed I2C transaction and shouldn't get stuck in the Hwi. In the mean time I'll add capacitance to my lines, which solves the glitch problem but this is non ideal because of the rise times as I mentioned earlier. Really the Hwi should be updated to use the timeout and return a failed I2C transaction so that the firmware can recover.
Best regards,
Blair
