• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 79 subscribers
  • Views 2048 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

MSP430F5438A: I2C SCL Stuck Low

Lee Weber
Prodigy 30 points

Part Number: MSP430F5438A

We have a SoC device as the master writing to the MSP430F5438A I2C bus.  The  MSP430F5438A is the slave.  We occasionally see SCL get stuck low until a timeout occurs.

We have seen the Errata, USCI30 at the following:
We tried implementing both the DMA approach and the wait 3 clocks approach and the problem still occasionally occurs.
When the problem occurs: 
The master write of the first 2 bytes to the MSP430 slave look good.
At the 7th SCL Clock of the 3rd byte: SCL stays low for 15.54 mS (byte being 8 bits plus acknowledge bit) 
Then the 8th SCL pulse occurs 
Then the 9th pulse occurs with SDA low (this is an ACK, not a NACK like USCI30 "2)" states.  (so are we really experiencing the USCI30 condition?)
Then the 4th byte looks good.
Then the 5th byte behaves like the 3rd byte with SCL getting stuck low at the 7th bit.
We believe we are following the Users Guide, SLAU208Q, section 38.3.4.1.2 I2C Slave Receiver Mode correctly.
USCI30 states the following:
If the receive buffer has not been cleared of its contents by reading the UCBxRXBUF
register while the 7th bit of the following data byte is being received, an error condition
may occur on the I2C bus. Depending on the USCI configuration the following may
occur:

1) If the USCI is configured as an I2C master receiver, an unintentional repeated start
condition can be triggered or the master switches into an idle state (I2C communication
aborted). The reception of the current data byte is not successful in this case.

2) If the USCI is configured as I2C slave receiver, the slave can switch to an idle state
stalling I2C communication. The reception of the current data byte is not successful in
this case. The USCI I2C state machine will notify the master of the aborted reception
with a NACK.

Note that the error condition described above occurs only within a limited window of the
7th bit of the current byte being received. If the receive buffer is read outside of this
window (before or after), then the error condition will not occur.

Questions: 
1. The first and last paragraph seem to conflict somewhat.  Can you provide clarification?
2. Since we see an ACK and not a NACK does that mean we are not experiencing an errata USCI30 condition?
3. Is "idle state stalling I2C communication" our SCL stuck low condition?
4.  What ideas and or questions do you have to help us determine why and prevent SCL from getting stuck low?
Your quick support will be greatly appreciated.
Lee
  • 0
    TI__Mastermind 40195 points

    1. I also don't quite understand about it. But I think the thing it can describe is that you need to ensure when e receive shift register receives 7 bit data. You need to make sure Receive Buffer UC1RXBUF is empty.

    2. I don't know much about what it will happens when meet USCI30. It key point is that the MCU frequency can't handle with a high speed I2C communication. My advice is that:

    • Decrease the communication speed to see if it can help. What the I2C communication speed now? If you use DMA successfully. I don't think you will meet USCI30.
    • Can you post the wave. If the I2C drive strength is not strong, it may also meet some problem.

    Eason

  • 0 in reply to Eason Zhou
    Prodigy 30 points

    Eason, thank you for your timely response.

    We believe we are doing DMA correctly. 

    Question 1: If we are not meeting USCI30, then what else could be causing SCL to be stuck low?

    We are running the SCL at a frequency near the slow end of I2C fast Mode.  

    Question 2: You mentioned " that the MCU frequency can't handle with a high speed I2C communication". At what speeds do you start to see problems?

    Question 3: my original question 3: When USCI30 states "idle state stalling I2C communication" - Is the result of that a SCL stuck low condition?

    You mentioned I2C drive strength: Our SCL and SDA rise and fall times are < 300 nS (~ 0 to 100%).

    Below are the waveforms I described in my first post.  This is when SCL gets stuck low

    SCL is stuck low for 15.54 mS, then the following occurs:

    Lee

  • 0 in reply to Lee Weber
    TI__Mastermind 40195 points

    1. Question1: I don't quite now about the reason. Normally as a slave it should not stretch the SCL because the SCL on slave is set as input. The condition I meet only happens when after master send the address. 

    2. Question 2: The highest speed of I2C is 400kHz. 

    3. Question 3: I can't answer this question the reason is that as you has applied the work around method. USCI30 should not happen. There is no meaning to  check what doesn't the sentence mean.

    Let us come back to this problem. There are four possibilities:

    1. Master: Does master using hardware or software I2C? What about the transmit speed? 

    2. Connection: I think it is OK.

    3. Software in F5438: I advice you using an I2C slave example code and run at the same speed to check whether this problem will happen.

    4. Hardware in F5438: If software still happens, please use a MSP430 to communicate with F5438.

    I can't see the picture. Sorry.

    Eason

**Attention** This is a public forum