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.

MSP430FR59941: scl stuck low

Part Number: MSP430FR59941

We have a custom platform that utilizes an MSP430 chip that interfaces with another controller via I2C. After a period of high activity between the MSP430 and the controller, we have a situation where SCL is stuck low. When this happens, the rest of the platform is unresponsive. It is unclear if the issue is on the controller side or the MSP430 side. When we get into this state, we have tried the following:

1) After the SCL hang, attach JTAG and perform soft and hard resets
2) After the SCL hang, attach JTAG and restart the MSP430 firmware
3) Used the JTAG debugger to include break points at critical code locations in the I2C logic. This testing added breakpoints at each stage of the SCL low failure: before, during and after. At each stage, the MSP430 state was investigated and verified to be good.

SCL is still stuck low after attempting these steps. The only method we could find that would fix it is to power the entire platform off.  

Any information you could provide on what may be causing this state to occur (or how we can further investigate) as well as any insight into how we can get out of this state (since the resets did not appear to fix it).

Any help would be greatly appreciated!

  • Hi,

    Can you physically detach the MSP430 from the other controller to determine who is hanging the bus? In other words, when the bus hangs remove the MSP430 from the bus and inspect the state of the bus.

    Thanks,

    Evan

  • Hi Evan,

    The parts are both soldered to a pcb but we should be able to find a way to detach it.
    What is the correct way to disconnect the MSP430 from the I2C bus?
    Will pull-up resistors be an issue?
    Should we ensure all pull-up resistors are removed from each side?
    Should we add an extra pull-up resistor to the other side?
    If the issue is the MSP430, any thoughts as to a possible solution?

    Thanks,
    Tony
  • Tony,

    Shouldn't matter where the pull ups are. If the pull ups are connected to the MSP430 and you disconnect the controller and the bus is still hung then the MSP430 is to blame. If the pull ups are connect to the controller and you disconnect the MSP430 and the bus is still hung then the controller is to blame. 

    Alternatively you can use an accurate multimeter to determine where the current is flowing out of the pull-up by probing the output of the pullup and the SCL pin of the MSP430. You will see a couple of millivolts (maybe) due to the trace resistance. If the current appears to flow towards the MSP430 than that would indicate that the MSP430 is hanging the bus. 

    Is the MSP430 the "controller" or "peripheral" in this circuit? Sorry for the overloaded terms, I'm trying to use inclusive terminology.

    Regards,

    Evan

  • Hi Evan,

    The MSP430 is configured in multi-controller mode. The SCL issue occurs when the MSP430 is acting as the controller. We observe the destination byte address get ACKed on the I2C, the TX IFG is triggered and the MSP430 loads the TX register with the next byte. The MSP430 uses a timer and after ~3s times out and the MSP430 resets the eUSCI using the UCSWRST. We observe the SDA go high, and the SCL remains low. Next we used JTAG to reset the MSP430, the SCL still remained low.

    In your examples, I believe you may be assuming the MSP430 is the peripheral. In our failure case, the MSP430 is the controller.

    Thanks,
    Tony

  • If a reset of the MSP430 (or just the serial port using UCSWRST) fails, then it is the other end of the line that is holding the I2C clock low.

  • Tony,

    My experiment was just trying to determine which device is hanging the bus so we know where to debug. Once we know that then we can go further.

    Regards,

    Evan

  • Understood. Thanks Evan. We are going to run the experiment tomorrow. Thanks for the help

  • We have performed your recommended test and confirmed that it is not the msp430 that is hanging. 

  • Tony,

    Thanks for the update. I will close this thread for now. If you need additional support you can reply here and it will automatically reopen and notify me.

    Regards,

    Evan

  • Tony,

    Thanks for the update. I will close the thread now, if you need additional support you can reply to this thread and it will automatically reopen and notify me.

    Regards,

    Evan

  • You didn't mention what your I2C slave is, but I have encountered some that deal ungracefully with extra-ordinary events, often stretching the clock forever.

    The I2C spec [UM10204 Sec 3.1.16] suggests having an out-of-band Slave reset mechanism to deal with this case. 

    If it's possible (check the Slave datasheet) consider powering it with a GPIO, and power-cycling it at MCU startup (or in case of a bus hang). A GPIO can pretty reliably source 2mA, and many Slaves can run comfortably on quite a bit less than that.

**Attention** This is a public forum