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.

I2C bus clock stall recovery

Other Parts Discussed in Thread: MSP430F5324

Hi all,

I am working on a project where we use the USCI_B1 controller of a MSP430F5324 in I2C master mode to control a temperature sensor IC. The temperature sensor is at the end of a wired probe, and occasionally the probe can pick up noise on the bus that can cause the temperature IC to indefinitely stretch the final clock of the ACK following the clocking of the sensor's address. In this case, we take the following actions:

  1. Set UCSWRST
  2. Configure the pins to IO function
  3. Reset the sensor IC
  4. Configure the pins to primary function
  5. Clear UCSWRST

Following this, the next I2C transaction start condition is much shorter than typical. Also, it seems following the sensor IC successfully ACKing it's address, UCTXIFG is never set, and the SDA line goes high a half clock period following the rising edge of the ACK clock. I've looked through the register settings pretty carefully, and the controller appears to be configured correctly.

My question is, could resetting the controller while the bus is in a stalled state cause problems? Does anyone see any issues with my approach?

Thanks in advance.

  • Ok, it's a bit of a guesswork without seeing the actual code so I might be totally wrong for your case but here's my 2 cents:

    Tyler Olmstead said:
    My question is, could resetting the controller while the bus is in a stalled state cause problems?

    Do you mean resetting whole MSP430 device or just the USCI_B1? Because if you reset whole MSP430 then by default at startup all IO pins become high-impedance and that will be ok however if you meant the actions that you listed then that's a bit trickier. Here's why:

    Tyler Olmstead said:
    Configure the pins to IO function

    What pins do you configure to IO function? The SDA and ACK? When you configure them to IO function, do you set them as inputs or outputs? Remember that outputs are low-impedance and if your I2C sensor has stalled then it may sink or source current from or to your digital outputs which may adversely affect your MSP430 (maybe?).

    Care to post some code? Otherwise it's mostly a speculation.

  • Tyler Olmstead said:
    My question is, could resetting the controller while the bus is in a stalled state cause problems?

    If it's not the controller itself that is causing the stall, then there are three possible outcomes:

    1) resetting the controller does nothing. The slave that was stalling the bus si still holding SCL low. Nothing the master can do.
    2) resetting the controller does nothing at first, but eventually the slave will release SCL and expect the stalled transfer to be finished. then there are two possibilities:
    2a) when the master issues a new start condition, the slave will detect this as end of the current transfer and reset its own communication loop. All is fine then.
    2b) the slave insist on finishing the incomplete transfer, Which causes more or less permanent trouble on the bus. However, this is an unlikely case as and slave should copy with incompleted transfers. I not, there's nothing you can do.
    So the main quesiton is not how to recover from a stalled bus, but rather why is there such a thing as a stalled bus. There must be something seriously wrong. And chopping off the head won't be a proper cure for a headache, even though it might work.

    So in your case the question is why the probe is picking up noise on a digital line (maybe your pullups aren't strong enough or your pullup supply voltage is unstable) and why does it lock-up when this happens (or is it just crashing because during the transfer it enables some circuitry that drains VCC down to a critical value for a short time?).
    Add some deblocking capacitors on the probe, or mabe even a bigger stabilizing capacitor for VCC near the probe.

    However, if this is a known erratum for the probe, I suggest moving onwards to a part that works.

  • Thanks everyone for the help, the cause of the issue has been determined.

    Jens-Michael Gross said:
    1) resetting the controller does nothing. The slave that was stalling the bus si still holding SCL low. Nothing the master can do.

    Yes, this is what is happening. The slave is getting in to a state due to noise where it held SCL low following the final address bit. However, we are able to reset the slave IC and clear the stall, but the transaction must be terminated and restarted at this point. The issue was that setting UCSWRST doesn't clear UCTXSTT. Because the transaction failed before the MSP received the ACK from the slave following the address bits, UCTXSTT remains set through reset and this causes misbehavior after UCSWRST is cleared. The solution was to clear UCTXSTT while the controller is held in reset.

    Jens-Michael Gross said:
    So in your case the question is why the probe is picking up noise on a digital line (maybe your pullups aren't strong enough or your pullup supply voltage is unstable) and why does it lock-up when this happens (or is it just crashing because during the transfer it enables some circuitry that drains VCC down to a critical value for a short time?).
    Add some deblocking capacitors on the probe, or mabe even a bigger stabilizing capacitor for VCC near the probe.

    Agreed, all of these things would be appropriate solutions. Using differential signaling across the probe cable would also be appropriate, but unfortunately the device is already well into production, and so this will be an over-the-air firmware update.

  • Tyler Olmstead said:
    unfortunately the device is already well into production

    THis is why many manufacturers (a tleast in the past when devices were still large) put a lot of resistors and capacitors into the layout. It's easy during production to leave out the placement of parts that are already planned-in. Addign parts that were not in the layout for mass-production is way more difficult and costly.

    Tyler Olmstead said:
    The solution was to clear UCTXSTT while the controller is held in reset.

    It works? Well, you're lucky. My suggestion would have been to switch from I2C to SPI mode and back while in SWRST. This will for sure set everything back to start.

  • Jens-Michael Gross said:
    THis is why many manufacturers (a tleast in the past when devices were still large) put a lot of resistors and capacitors into the layout. It's easy during production to leave out the placement of parts that are already planned-in. Addign parts that were not in the layout for mass-production is way more difficult and costly.

    Agreed. I think we will at least look at adjusting the bus pullup values, if not reving the board to add some filter caps. The real issue is for the devices that have already been deployed, and for these we require a software solution.

    Jens-Michael Gross said:
    Well, you're lucky.

    I guess it's better to be lucky than good. ;) Thanks again for your help.

**Attention** This is a public forum