• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 79 subscribers
  • Views 4960 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.

msp430 I2C glitch / spike issue

Ho-Jun Song
Prodigy 120 points
Other Parts Discussed in Thread: MSP430F1611, MSP430F2132, TMP102

Hi i'm keep seeing glitch or spike on i2c data.

Settings are:

- Pull up Resistor: 10k / Series Resistor: 250 Ohm

- Master Tx and Rx : MSP430F1611 USART I2C , I2CCLK = SMCLK =  XT2 Crystal 7.3728MHz, I2CPSC = 0, I2CSCLH = 0x20  / I2CSCLL = 0x20 to generate ~100kbps SCL

- Slave Rx and TX: MSP430F2132 USCI I2C, I2CCLK = SMCLK = DCO ( does slave clk setting matter?) but set to generate ~100kbps SCL as well.

- SW: Master writes 8 bytes to slave and read the same data to verify. If the data is different 1611 board LED toggles.Master and Slave code only does I2C handling via ISR.

And these are images of spikes:

from the saleae logic analyzer:

from the oscilloscope:

It looks like the spike is not affecting the data value as the spike is not on valid SDA timing.

but i'm worried that spike might induce wrong data format in more noisy situation.

Anyone knows why the spike are generated ? and how to get rid of them?

I've communicated to TMP102 temp sensor but still seeing the spike.

I wonder whether this is some intrinsic issue on shift-out or shift-in of msp430 i2c modules?

 

  • 0
    Genius 4090 points

    Ho-Jun Song said:
    ( does slave clk setting matter?)

    Since the I2C slave's clock is sourced by master it does not matter at all.

    From first picture it appears that its not a valid I2C communication signal.

    For second picture, try to capture both SDA and SCL together, and what is the data/address being transmitted in the second picture?

  • 0
    Guru 227245 points

    Ho-Jun Song said:
    Anyone knows why the spike are generated ? and how to get rid of them?

    Likely, those spikes appear when the control of hte data loine changes. When the master has output low and then rleases the line so the slave can ACK, then there might be a short moment where the master has already released SDA and the slave hasn't pulled it down yet and therefore the pullup is pulling the line high. If you take a closer look, thos spikes always appear at a fallign edge of SCL.

    This is normal and depends on the internal delays between clock generation, clock detection, input and output driver switching. In the opposite case the two (master/slave) will overlap and you don't see a spike (a double-pull doesn't show up different than a single pull).

    The spike on SCL and SDA right before the stop/start condition looks way more suspicious. A scope shot of this point (with both, SCAL and SDA) would be interesting. You possibly hit the timing erratum where the clock timing is wrong between stop and start.

  • 0 in reply to chethu gowda
    Prodigy 120 points

    thank you, chethu gowda

    chethu gowda said:
    Since the I2C slave's clock is sourced by master it does not matter at all.

    I learned, for USART I2C, I2C Slave still needs to set up the clock source, which is in my case SMCLK.

    chethu gowda said:
    From first picture it appears that its not a valid I2C communication signal.

    It's valid I2C signal and i'm still having no issues getting correct data. :)

    I was sending sequences of 6 and read the sequence from the slave buffer.

  • 0 in reply to Jens-Michael Gross
    Prodigy 120 points

    Thank you, Jens-Michael Gross

    Jens-Michael Gross said:
    The spike on SCL and SDA right before the stop/start condition looks way more suspicious.

    For this, i keep seeing them but still had no problem communicating.

    For now i just concluded that this is for some reason USART I2C master is releasing the SDA line before it's shifting out another bit from its shfit-out buffer.

    (still strange though as I2C should not allow any Master to interrupt when Data is transferring even in Multi Master I2C system)

**Attention** This is a public forum