• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 34 subscribers
  • Views 818 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.

PCA9557: Please, help to reproduce a chip getting stuck on Power-on-Reset (errata 10.1 from the datasheet)

Mikhail Zakharov2
Prodigy 70 points
Part Number: PCA9557

We have PCA9557 stuck mysteriously in one of our designs. Now we are aware that there is a PoR errata, that the chip may get "stuck". In order to decide if this is the issue that affects our customers, we need to reproduce it first.

The datasheet specifies that if Trise for the power > 10 ms, then the chip may get stuck.

We applied the power with the rise time of 80ms but we are unable to make it "stuck" in 10000 powercycles. We varied the Trise all the way up to ~1s but we were unable to get it stuck in 10000 powercycles

Can TI customer support, please, suggest how exactly can we make it stuck and reproduce the errata from the datasheet (10.1)?

  • 0
    TI__Guru 72751 points

    Hey Mikhail,

    I'll see if I can find scopeshots of our testing on a device which uses the same IP as this one and get back to you on what I find. (Tomorrow)

    -Bobby

  • 0 in reply to BOBBY
    Prodigy 70 points

    Hey, Bobby, thank you. Waiting with great anticipation.

  • 0 in reply to Mikhail Zakharov2
    TI__Guru 72751 points

    A quick snip it from the debug session where we sent our engineer to the site to debug and resolve the customer's problem.

    "We were able to get SDA to latch low after a few minutes of power cycling. The TRISE time of the Vcc was ~4ms.

    We tested this with various off times and noted that sometime the register values were reset to default and at other times they were random register values."

    o-scope channels are denoted at the right hand corner. Note that the GPIOs sometimes powered up in a random state like output LOW or output HIGH when it should have been an INPUT (seen in ch 1)

    We were able to resolve the problem was resolved by placing a pull down resistor on Vcc to ensure that the power signal could fully dissipate it's charge (giving our device a chance to discharge fully) before powering back up.

    -Bobby

  • 0 in reply to BOBBY
    Prodigy 70 points

    Bobby, thanks for the reply,

    I have some questions:

    1. I assume that after the powerup measured in scopeshot above the IC was locked for I2C communication. Is this correct?

    2. The IC was holding the SDA line low, thus preventing all communication on this I2C bus. Is this correct?

    3. The failure described here does not match the errata from section 10.1 of the PCA9557 datasheet. In the section 10.1 it mentions specifically that Trise has to be > 10ms. In this a different failure mode of the IC with the same I2C/PoR IP as PCA9557?

    4. You quote "We were able to get SDA to latch low after a few minutes of power cycling". How many powercycles did it take? Were they all identical with ~4ms Trise?

    PS.
    I am the firmware person, our EE (Ken Huynh) may join the discussion.

  • 0 in reply to Mikhail Zakharov2
    TI__Guru 72751 points

    "1. I assume that after the powerup measured in scopeshot above the IC was locked for I2C communication. Is this correct?"

    The set up had external pull up resistors, but during that particular case the IC's SDA got locked so I2C communication was locked as a result.

    "2. The IC was holding the SDA line low, thus preventing all communication on this I2C bus. Is this correct?"

    Yes, but toggling the SCL line was never tested. I believe doing 8 to 16 clock pulses during this occurrence may have resolved the I2C lock up condition.

    "3. The failure described here does not match the errata from section 10.1 of the PCA9557 datasheet. In the section 10.1 it mentions specifically that Trise has to be > 10ms. In this a different failure mode of the IC with the same I2C/PoR IP as PCA9557?"

    This should be a similar case, the PoR for most of the PCA devices are shared. The scopeshot doesn't show the full T_low time so this may have an affect on the issue seeing as this was also spec'd in the errata.

    "4. You quote "We were able to get SDA to latch low after a few minutes of power cycling". How many powercycles did it take? Were they all identical with ~4ms Trise?"

    I wasn't the engineer who tested this but the engineer who did, knew how to use automated testing and likely ran hundreds of test sequences within a few minutes to be able to capture this occurrence where SDA locked low. The document of this event didn't specify how many power cycles he went through to grab it nor if he varied the rise time during the test sequences (i suspect he didn't).

    -Bobby