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.

MSP430F5234: MSP430 I2C bus hang problem

Part Number: MSP430F5234
Other Parts Discussed in Thread: TPS23881

Hi team

When customer PoE is running for a long time, the MSP430 I2C will not respond. If the Mainboard shown in Figure 3 is powered off and then powered on, the I2C bus will still be in a dead state, that is, both SCL and SDA are blocked. The MSP430 is pulled low and the fault can only be recovered by re-powering the PSE Daughter Card shown in Figure 3.
Figures 1 and 2 use the logic analyzer to acquire data 77 seconds before the fault occurs. Figure 2 is an enlarged view of the red box in Figure 1. See Section 4 for detailed data.

figure.1 I2C bus dead 77s

figure.1 I2C bus dead

2. The hardware system block diagram is shown in Figure 3, and the schematic diagram is shown in Section 4.

 Figure 3 system block diagram

3 Software Design


The microcontroller MSP430 runs FirmPSE firmware, BSL version: V03, APP firmware: 00.01.36.00, SRAM version: V07.
The Linux operating system runs on the motherboard CPU, and the MSP430 is queried through the I2C1 bus every 3 seconds.

The detailed data captured by the logic analyzer is as follows, which can be opened with Logic 2 software, the software download address: https://www.saleae.com/downloads/

PSE-MSP430-TPS23881.pdfhttps://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/166/WriteFailed.sal

  • So which I2C link is this? Between the main board and a MSP430 slave? Or between the MSP430 and one of theTPS23881s? Or perhaps it is just one big I2C bus.

  • Hello,

    Please see the following resource for debugging I2C issues:

    Solutions to Common eUSCI and USCI Serial Communication Issues on MSP430 MCUs

    Typically, if SCL line is being held low, that's an indication of a peripheral device not working properly; however, that error tends to clear up if your reset the I2C connection with a  repeated START. You show both the SCL and SDA connection being help low, and that usually is a more serious error with peripheral (if you are a controller). 

    Some additional things you could check to give you clues as to what is going on. 

    • What is the register state of the (e)USCI being used on the bus that is stalled?  Does it look correct? Same for GPIO registers, are they still properly set to I2C functionality? (This isn't really a concern unless you are changing the state of pins/(e)USCI in your program. 
    • Can you reset just the MSP430, and not the whole daughter card? If so, is the issue resolved? (Unlikely to resolve, as issue indicates an issue with peripheral device.)
    • Similar to above, can you reset the peripheral TPS devices one at a time to see if any of them are hanging the bus?
  • Jace,

    Appreciate your reply, could you please help to check customer's SCH? 4530.PSE-MSP430-TPS23881.pdf

    I will let customer to check what you suggest.

    Thank you

  • So which I2C link is this? Between the main board and a MSP430 slave? Or between the MSP430 and one of theTPS23881s? Or perhaps it is just one big I2C bus.

    the issue happened between the main board and MSP430, if re-start the Daughter card, this issue could recover.

    Thank you

  • Then the problem is most likely within the MSP430 I2C code.

  • Hi David,

    thanks for your reply.

    In customer side,
    The microcontroller MSP430 runs FirmPSE firmware, BSL version: V03, APP firmware: 00.01.36.00, SRAM version: V07.
    The Linux operating system runs on the motherboard CPU, and the MSP430 is queried through the I2C1 bus every 3 seconds.

    could you please give more comments about this issue? thank you

  • I have never even heard of FirmPSE till now. But your problem looks like the MSP430 is holding the bus because RXBUF hasn't been read.

    So you need to figure out why. Since you say it runs for a long time before failing, the problem is probably from an interaction with some other code. Since you almost certainly have an I2C interrupt service routine, another ISR could keep it from running if it never returns. Or maybe global interrupts are disabled but never enabled again.

    Too many possibilities. The simple approach would be to connect the board via JTAG so you could use a debugger to see what it is doing when the failure occurs.

  • Hello Chen,

    David has the right approach here for general debugging of I2C on MSP430. That being said, I'll take this thread offline and connect you to the team that owns this firmware. 

**Attention** This is a public forum