• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 78 subscribers
  • Views 1955 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

MSP430F5529: UCB1 in 400kHz I2C master mode transmitting infinite SCL pulses

Michael O'Brien1
Prodigy 90 points
Part Number: MSP430F5529

I'm using UCB1 in 400kHz I2C master mode, and after a few bytes are read, the I2C engine appears to hang with the busy bit set. If you look at the SCL line on a scope, you can see 400kHz SCL pulses going on forever. If I remove the external device so that nothing is on the bus, the pulses continue, so the pulses are coming from the MSP430. 

This doesn't seem to happen with write transactions or with 100kHz I2C. I can't think of a reason why the bus would get stuck in this state. Any suggestions for debugging this issue? Any experiments I should run or data I should collect?

Thanks,

Michael

  • 0
    TI__Guru 56685 points

    Hello Michael,

    If the MSP430 is the master, then the SCL line is controlled by the MSP430. The slave device could hold it low aka clock stretching. when these clock pulses happen, are they in TX mode or RX on the MSP430? If its TX mode, then you are filling the TXbuf repeatably. If you are receiving then its possible that a STOP was not properly sent and you are still reading the RXbuf as the MSP430 will stall the I2C if the RXbuf is not read in time.  I can see a scenario if you are running the CPU really slow and your I2C fast, you could get in a loop (depending on external logic) of trying to always receive. without checking receive count in time and sending a STOP. Usually when I2C gets off track, the bus is stalled or idled (communication stop).

    I would also suggest looking at the following application note to debug further.

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

  • 0 in reply to Jace H
    TI__Prodigy 90 points
    Thanks, Jace. It is in RX mode at the time the bus gets stuck, and I see UCTXSTP set in UCB1CTL1. The documentation says this is automatically cleared when the STOP is generated, so I suspected it is still trying to send the stop. SCL is continuously pulsing, and SDA is high. If SDA was stuck low, I could see why the MSP430 would toggle SCL until the condition cleared so that it could generate the stop condition. But since SDA is high, nothing should be driving the bus, so it should be free to send the stop when it wanted.

    Are there any ways you know of to get into a condition where SCL is continually pulsed while SDA is high?
  • 0 in reply to Michael O'Brien1
    TI__Guru 56685 points
    Michael,

    The state of SDA doesn't matter. If either of the devices need to stall the bus, it will be done by keeping the SCL line low. What I suspect is that you are trying to use some sort fo interrupt to generate the STOP condition, but the RX interrupt has higher priority and keeps executing. Do you know what teh max number of receives you will always get? If so, I would place a count variable in your RX interrupt and manually generate a STOP condition within the RX interrupt, then turn off the RX interrupt. This should help.

    Also, make sure to check out that application note I mentioned before, as it describes work arounds for interrupt priority issues, I believe.
  • 0 in reply to Jace H
    TI__Prodigy 90 points

    Jace,

    To be clear, the bus isn't stalled with SCL held low- it is continuously pulsing at 400kHz.

    You are correct that I am using an interrupt to generate the stop condition. The number of receives is known ahead of time, so the RX ISR is decrementing a counter and setting TXSTP whenever the counter reaches 1 (which means the last byte is currently in progress). The RX interrupt flag is being cleared, but the RX interrupt is not being disabled. I can try that. I'll also check in the debugger if any UCB1IFG bits are set. I do know that TXSTP is set when I look at the control register in the debugger, so I've at least went through the code path to transmit a stop.

  • 0 in reply to Michael O'Brien1
    TI__Guru 56685 points
    Michael,

    Checking in here to see if your tests shed any light on the issue.

    Also, understood that your bus isn't stalled with SCL low. I was just clarifying that as per I2C standard, a stall is defined by SCL staying low. With it continuing to pulse, something is driving it.
  • 0 in reply to Jace H
    TI__Prodigy 90 points

    Unfortunately I have not yet had a chance to test it out as I have been busy with other things. I hope to get to it next week.

  • 0 in reply to Michael O'Brien1
    TI__Prodigy 90 points

    Checking this out again, I've tried adding an interrupt disable. However, the issue occurs before I finish receiving enough bytes, so it doesn't really make a difference. I'm doing a 2-byte read and the MSP430 (master) is NACKing the first byte back it's reading and then continuously pulsing SCL. No USB1IFG bits are set, and UCB1STAT is 0x10 (busy only). UCB1CTL0 = 0x2F and UCB1CTL1 = 0x80 (UCSSEL_2).

  • 0 in reply to Michael O'Brien1
    TI__Guru 56685 points
    Michael,

    I should of checked the errata for this part earlier. It just didn't click with me that this could be USCI30 Errata until now. I would suggest looking at the workarounds described for USCI 30 and implementing one of them. Sometimes you can get away with just reading the RXBUFF when immediately entering the ISR, but the errata document gives more bulletproof methods.

**Attention** This is a public forum