• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 80 subscribers
  • Views 2137 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.

MSP430G2553: I2C SDA held low on ~2% of power-ups

George Weickhardt25
Prodigy 100 points
Part Number: MSP430G2553

My MSP430 is working as the single master communicating to a single slave device the RT9528 charger. Usually, about 98% of the time it powers on and I2C works flawlessly. The other 2% gets stuck in a fault state with no communication and seems to be cleared only by power cycle (so far). On the faulty power-up, it seems that SDA/P1.7 never leaves logic low. I think the MSP is the one responsible because when I disconnect series resistor, MSP side is low (albeit it also removes pull-up) and the slave side is high (w/ pull-up). I try to detect when it happens in code and convert P1.7 to GPIO to attempt a toggle, but when I try this it only goes to 1V instead of 3.3V.

  • 0
    Prodigy 100 points

    SDA/SCL lines with 800mV GPIO toggles on SDA

  • 0 in reply to George Weickhardt25
    Guru 295730 points
    Show the schematic of your circuit.

    If you try to set the output high, but measure only 1 V, then some other device is pulling the line low.
  • 0 in reply to Clemens Ladisch
    Prodigy 100 points

    Hello,

    Siby James said he would share the schematic separately.

    Your explanation makes sense but can you offer any insight as to why disconnecting the slave causes the slave side logic to go to high?

    Do you have any tips for how to secure transmission to slave? I'm going give pulsing SCL 9 times another shot

  • 0 in reply to George Weickhardt25
    TI__Expert 5140 points

    Clemens,

    Thank you for your replies to our forums. I will be sharing the schematic internally as this is a public forum. 

    Thanks,

    Siby 

  • 0 in reply to George Weickhardt25
    TI__Intellectual 1370 points
    Hi George,

    It doesn't look like there is anything out of place on your schematic on the I2C lines between the MSP and RT9528. When the series resistor is removed, the voltage on the MSP side of the SDA line should remain low during I2C communication without the pull-up resistor because the MSP only drives the SDA line low and puts the pin in a high impedance mode to allow the pull-up resistor to drive the line high. Are you able to remove the series resistor and add a separate pull-up resistor between the MSP side of the SDA line to VCC and measure the SDA signal from the MSP when the RT9528 is separated? When you switched P1.7 to GPIO and toggled it high, was the series resistor on the SDA line removed when you measured it at 1V?

    Are you able to reset the RT9528 separately to see if I2C communication resumes correctly afterward? Can you measure the voltages on the other pins of the RT9528 to see if they are as expected?

    Thanks,
    Ryan
  • 0 in reply to Ryan Meredith
    Prodigy 100 points

    Hi Ryan,

    Thanks for your review. Ah-ha, you are absolutely right about why the MSP is low without series resistor.

    I've had big improvements by pulsing SCL P1.6 as a GPIO to clock out extra bits. It seems that the slave is in the middle of a transmission. Regardless of state of SDA on power-up, initialization now uses 8 clock pulses followed by a STOP condition, here is a case when SDA was held low on power-up:

    I think this confirms that SDA was held low by the RT9528. I am still running tests to see if any faults persist. Do you have any recommendation for using more or less than 8 pulses?

    When P1.7 was used as GPIO it was with the series resistor shorted. 

    No way to way reset RT9528 without resetting MSP because SoC_VCC is able to backpower VUSB to 3V

  • 0 in reply to George Weickhardt25
    Guru 295730 points

    Eight data bits plus one ACK/NACK bit add up to nine pulses in the worst case.

    The I²C specification says:

    3.1.16 Bus clear

    In the unlikely event where the clock (SCL) is stuck LOW, the preferential procedure is to reset the bus using the HW reset signal if your I²C devices have HW reset inputs. If the I²C devices do not have HW reset inputs, cycle power to the devices to activate the mandatory internal Power-On Reset (POR) circuit.

    If the data line (SDA) is stuck LOW, the master should send nine clock pulses. The device that held the bus LOW should release it sometime within those nine clocks. If not, then use the HW reset or cycle power to clear the bus.

  • 0 in reply to George Weickhardt25
    TI__Intellectual 1370 points
    I agree with Clemens that SCL should be pulsed nine times as the I2C specification states.

    Regards,
    Ryan
  • 0 in reply to Ryan Meredith
    Prodigy 100 points

    Thanks for the feedback Clemens and Ryan.

    I will leave it unchanged from scope picture since my STOP condition sends an additional falling edge for 9 total.

**Attention** This is a public forum