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.

MSP430F5419A: MSP430F5419A I2C glitch / spike issue

Part Number: MSP430F5419A
Other Parts Discussed in Thread: MSP-EXP430F5529LP,

Hello,

Could you please advise about the following glitch?

Q1. Is it a known phenomenon for the part?

Q2. Do you think this glitch will be harmful under any conditions to induce a communication error ?  My customer is afraid of that the glitch form or timing changes.

 

My customer uses one of the USCI as I2C master at 380kHz.

They found a glitch on the SDA when the SCL falls as a start condition.

An oscilloscope screen was provided as below. Ch1(upper) = SCL, Ch2(Lower) = SDA.

Please find the glitch on the Ch2 = SDA right after the first falling edge of the SCL.

I found a thread which looks close to this phenomenon:

https://e2e.ti.com/support/microcontrollers/msp430/f/166/t/237128

  • Hi,

    1. The known bugs for this part are listed on the MSP430F5419A Device Erratasheet (Rev. AB). There seems no related to your issue.

    2. Please refer to the timing parameters, especailly for tSP on section 5.35 USCI (I2C Mode) of the MSP430F543xA, MSP430F541xA Mixed-Signal Microcontrollers datasheet (Rev. F)

  • Wei,

    Thank you for your response.

    I could duplicate on MSP-EXP430F5529LP without slave devices.

     

    Can I ask you to agree that the phenomenon comes from the MSP430F5xx and give your advise if it could be harmful for communication results ?

     

    Let me share my procedure:

    • Build the attached C code. MSP430F55xx_UCS_10 was combined to MSP430F55xx_uscib0_i2c_6 to do 390kHz I2C.
    • Program it to MSP-EXP430F5529LP.
    • Put I2C pull-ups, 1kohms, to P3.0 and P3.1 and observe them.

     

    C source and oscilloscope plots: 

    /cfs-file/__key/communityserver-discussions-components-files/166/For_5F00_E2E.zip

  • Wei,

    I'm sorry, I have not respond to your post. Please let me respond.

     

    >>>>>

    1. The known bugs for this part are listed on the MSP430F5419A Device Erratasheet (Rev. AB). There seems no related to your issue.

    <<<<<

    Thank you for comparing the phenomenon to the errata.

    I understand that it would be a new phenomenon for us.

    My customer questions are, the source device of the glitch and its risk to induce problems.

    My test suggested that the source device is the MSP part but I would like you to agree this.

    And I would like to ask you its risk to induce communication errors.

    As long as the captured plots the glitch would be not harmful because the SCK is held low. I would ask you to check if the SCL/SDA signals could change a lot to induce communication errors?

     

    >>>>>

    2. Please refer to the timing parameters, especailly for tSP on section 5.35 USCI (I2C Mode) of the MSP430F543xA, MSP430F541xA Mixed-Signal Microcontrollers datasheet (Rev. F)

    <<<<<

    It was difficult for me to understand what is meant by the tSP. I would think tSP is for inputs. My test suggested that the glitch is an output from the MSP part.

    Please tell us if still now tSP helps to explain the phenomenon.

      

    =====

    Q3.

    Is it possible for you to share an example code or a register setting,

    if the phenomenon is not duplicated in your labo?

    It would be good if the glitch goes away by a good code.

     

  • Wei,

    We would look forward to your response.

    Thank for reading.

  • I'll just mention here that the I2C Spec allows the Master (or the Slave, for that matter) to do pretty much anything it wants with SDA as long as SCL is low. [Ref Spec (UM10204-r6) Sec 3.1.3.]

    It does look odd. It may be a handoff thing (as Jens-Michael suggests). But it doesn't violate the Spec. If it affects the Slave, then the Slave is non-compliant.

**Attention** This is a public forum