• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 80 subscribers
  • Views 6216 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.

I2C Clock Stretching Issue

A. Kirchhoff
Intellectual 535 points

Other Parts Discussed in Thread: MSP430G2452, MSP430F5419A

I am communicating via I2C between a MSP430F5419A (master using USCI) and a MSP430G2452 (slave using USI).  The clock rate is about 100 kHz.

Under normal conditions, the communication works fine with the 2452 performing clock stretching as necessary to ACK the data.  However, I have the occasional error occur.  The error has several forms, but I was able to reproduce one with some test code.

On the 5419A (master), I added 100 us delays between sending the start condition and the first data byte and between each of the following data bytes.  This is to simulate an interrupt firing in the middle of an I2C transaction.  When talking to another I2C device on the bus, these delays cause no problems.  The 5419A stretches the clock until the next byte is loaded into TXBUF.

However, when talking to the 2452, the 5419A does not stretch the clock as expected.  The slave address is sent and ACKed with no problems.  After receiving the first data byte, the 2452 stretches the clock before sending the ACK.  Once the 2452 lowers SDA, the clock is released even though no byte is loaded into TXBUF and the 5419A should be holding the clock low.  The 5419A then goes on to continuously clock out data until the micro is reset.

Any thoughts on what is going on?  I didn't find any errata describing this issue.

Attached is a Word document with screen shots.

Thanks for your help,
Austin

3175.ABK I2C Testing.docx

  • 0
    Guru 227245 points

    A. Kirchhoff said:
    Once the 2452 lowers SDA, the clock is released even though no byte is loaded into TXBUF and the 5419A should be holding the clock low.

    Well, not necessarily. It is no violation to release the clock. When the clock is released, data won't be output anyway (except for a stop condition). But I agree that this could be an indicator of the problem if under othe rconditions the USCI will hold the clock low.

    A. Kirchhoff said:
    The 5419A then goes on to continuously clock out data until the micro is reset.

    This, however, isn't as it should.

    A. Kirchhoff said:
    Any thoughts on what is going on? 

    Well, from your description alone, no. Maybe a look at your code could be enlighting. It's possible that due to a racing condition or unexpected event, your code slips off the track.

  • 0 in reply to Jens-Michael Gross
    Intellectual 535 points

    Jens-Michael Gross said:

    Once the 2452 lowers SDA, the clock is released even though no byte is loaded into TXBUF and the 5419A should be holding the clock low.

    Well, not necessarily. It is no violation to release the clock. When the clock is released, data won't be output anyway (except for a stop condition). But I agree that this could be an indicator of the problem if under othe rconditions the USCI will hold the clock low.

    [/quote]

    My description of the issue is not quite right.  I agree it is not a violation for the 2452 to release the clock.  However, the 5419A should continue to hold the clock low because TXBUF is empty.

    The 5419A no longer continuously clocks out data after the error, but I get a weird stop condition and a least one byte is still clocked out.

    Here are some logic traces that are marked and better described:
    7723.MSP430F5419A I2C Issue.doc

    Here is a zip file with my test code:
    4466.I2C Issue Test Code.zip

    Austin

  • 0 in reply to A. Kirchhoff
    Guru 227245 points

    A. Kirchhoff said:
    However, the 5419A should continue to hold the clock low

    Yes, that's the documented behaviour. However, this is not required by teh I2C specs. The master may stall the bus on the previous high cycle as well. Since there was no stop condition, the bus isn't free for anyone else and the master is the only one who can continue with the clock.

    It may well be an issue with the I2C code you use.
    E.g. in I2C_TransmitStart, there's a while that waits for transmit buffer free. The comment states that this will happen when the start condition is sent and acked. However, this happens immediately on the USCI, the following while block is completely useless unless the bus is currently active. And if it is, then this can be checked directly (busy bit). Also, the code doesn't check for a NACK from the slave when transmitting.

    The continuous data output may be because teh TX interrupt doesn't get notified that the transfer has ended, and will continue to send 64k of data until it notices again. Or something like that. I don't have the time to analyze all the library code and check for problems.

    I noticed that the code contains tons of GPIO test points. I can imagine that your problems arise because one of the test point signals is send on a GPIO pin that is used for the I2C signals. You should re-check these TEST_POINT_xx_PORT and TEST_POINT_xx_PIN defines. The 'weird stop condition' looks like one of these test point toggles.

    Also, when I look at the short blip generated on start, and the rather long 'high' time  on first TXBUF write, I don't udnerstand what keeps the code so long in the transmit_byte code.

    Due to the delay you added before sendign the first byte, both, output shift register and TXBUF are clear. So when you send a byte, the TX function sould stuff the byte to TXBUF and then TXBUF is almost instanly clear again when the output begins. I wonder why it takes so long to clear TP12. The function should release TP12 after a few MCLK cycles. It almost looks like there is an ISR interfering.

    How do you initialize the USCI?

  • 0 in reply to Jens-Michael Gross
    Intellectual 535 points

    While the clock being released by the 5419A may not violate the I2C specs, the documented behavior is important because TXBUF is empty.  By not holding the clock low, the 5419A goes on to clock out whatever is left in the shift register, which results in random data being written to the 2452.  This is a problem.

    I believe this may be a problem in the USCI module itself, though I can't explain what is going on in the module.

    I have verified that the test points are not defined as the SDA or SCL pins.

    USCI initialization:
    UCB3CTL0 = UCMST | UCMODE_3 | UCSYNC;
    UCB3CTL1 = UCSSEL__ACLK | UCSWRST;
    UCB3BRW = 64u;  /* ACLK = 6.4 MHz, so clock = 100 kHz */
    /* Configure SCL and SDA pins a peripherals */
    UCB3CTL1 &= ~UCSWRST;

    Test code walk through for an I2C write.  Let me know if you see any potential issues.

    1. Call I2c_TransmitStart:  Set UCTR and UCTXSTT to send start condition.  Then wait for TXIFG to be set, which happens immediately (like you said).  This function returns quickly resulting in the short pulse on TP12.
    2. Wait 100 us.
    3. Call I2c_TransmitByte:  Write data to TXBUF.  Then wait for TXIFG or NACKIFG to be set.  If NACK occurs, indicate error.  The USCI holds SCL low before the Ack/Nack until TXBUF is written.  After TXBUF is written, the USCI receives the Ack/Nack before moving the data in TXBUF to the shift register and making TXBUF empty.  Thus, this function does not immediately return.
    4. Wait 100 us.
    5. Call I2c_TransmitByte as many times as needed with 100 us waits inbetween.
    6. Call I2c_TransmitByteEnd:  Write data TXBUF.  Then wait for TXIFG or NACKIFG to be set.  If NACK occurs, indicate error.  Then, set UCTXSTP to send the stop condition.  Wait for stop condition to be sent, then check for a NACK one last time.  If NACK occurs, indicate error.

    Thanks for your time in looking at this.

    Austin

  • 0 in reply to A. Kirchhoff
    Intellectual 535 points

    I found another clue.  The MSP430G2452’s current code does not pull the SDA line low until it decides if it should ACK or NACK the received byte.  This takes several microseconds.  I thought I would see what happened if SDA went low sooner.  I found that if SDA goes low right away after receiving the last bit, the issue does not occur.  However, if SDA is delayed in going low, the issue occurs.

    I have screen shots of this occurring in the following document.  I’ve also attached new 2452 I2C code that shows what I changed.
    7217.MSP430F5419A I2C Issue (SDA delay).doc

    While this fixes the problem in my test code, in the final product the 2452 uses interrupts to handle the I2C communication.  If the 2452 is delayed in handling the I2C interrupt (e.g. because another interrupt routine is in progress), the SDA line will be delayed in going low and would cause this issue to occur.  So this issue still needs to be resolved.

    I continue to believe that this is a problem in the USCI hardware.

  • 0 in reply to A. Kirchhoff
    Intellectual 535 points

    Based on what I found yesterday about the need to lower SDA right away, I have implemented a workaround on the 2452.  When waiting to receive a byte, the 2452 stays in its ISR so that when the byte has been received it can lower SDA right away.  By staying in the ISR, no other interrupt can delay the lowering of SDA.  With this new code, I am able to prevent this issue from happening and have not found any other problems with this workaround (other than having to wait in the ISR for ~100 us).

    I believe the root cause is still a problem in the USCI hardware.

  • 0 in reply to A. Kirchhoff
    Guru 227245 points

    A. Kirchhoff said:
    The MSP430G2452’s current code does not pull the SDA line low until it decides if it should ACK or NACK the received byte. 

    Well, the 2452 has an USI. The USI I2C implementation is plain software controlled, except for the input/ouput data shift. If it needs to stretch the clock, this must be done by the software, and it needs to be done while the master is still holding the clock low.

    With the USI, the reaction time between the shift finished interrupt and settign it up for the next data byte, is critical.
    Using interrupts for the USI in slave mode isn't a good idea. Interrupt latency, or other interrupts may take more time than available.

    An SPI or I2C slave with the USI is a very tricky thing.

    After a close look at the screenshots, it seems that somehow the ACK on SDA is released too early, which the logic analyzer (erroneously) interprets as stop condition (SDA 0-> while SCL=1).
    The 'bad' transmission is the only one on which the first data bit is '1'. In all 'good' transmissions, the first data bit is low, and SDA doesn't make a 0->1 transition here at all.

    To be honest, I don't have the time to make a deep analysis of your code for possible racing conditions or such.

  • 0 in reply to Jens-Michael Gross
    Intellectual 535 points

    Jens-Michael Gross said:
    If it needs to stretch the clock, this must be done by the software,

    This is incorrect.  Per the 2xx User's Guide and from my testing, the USI module will hold the clock low if either USIIFG = 1 or USISTTIFG = 1 (i.e. if either interrupt flag is set).  Thus, when the USI has completed a shift, it will stretch the clock until the software can get around to handling the interrupt.  I have found this to work correctly in my testing.

    However, because of a problem in the 5419A's USCI module (I believe), the SDA line must go low immediately after the USCI module has transmitted a byte.  When a byte is received, the 2452 will hold SCL low, but does nothing to SDA.  To pull SDA low immediately on the 2452, I needed to prevent interrupt latency from being an issue when responding to a received byte.  Thus, I now wait in the ISR while receiving a byte.

    Thanks for taking a look at this, Jens-Michael.  It has been a tricky issue to resolve.

  • 0 in reply to A. Kirchhoff
    Guru 227245 points

    A. Kirchhoff said:
    Per the 2xx User's Guide and from my testing, the USI module will hold the clock low if either USIIFG = 1 or USISTTIFG = 1

    After re-reading the users guide chapter, I agree. As long as the IFG bit is set, SCL is held low on next low phase of the clock.
    This means you must not manually clear USIIFG unless you want to release SCL.

    A. Kirchhoff said:
    However, because of a problem in the 5419A's USCI module (I believe), the SDA line must go low immediately after the USCI module has transmitted a byte.

    That's strange. The master should only check SDA when the clock actually goes high. Not when the master releases it.

    If your observation is correct, this might be a silicon erratum.

    A. Kirchhoff said:
    Thus, I now wait in the ISR while receiving a byte.

    Which definitely isn't the way it should work. Waiting in an ISR is 666. It shouldn't be necessary. However, if one needs the project done and it is the only workaround that works, what else could be done?

**Attention** This is a public forum