TM4C129x 3V3 short is back again

Hi Peter,

Ralph is on business travel now. I suspect he will check in on these posts when he can. 

What you describe in this post and the original post appears as a electrical overstress. We don't arrange for failure analysis work from the forum. That is something you can work our with your distributor and TI Field Application Engineer. Typically the first step is to do a diode check of each pin to see if the damage can be isolated to a particular pin. With the device unpowered, you can do a diode check between each pin and ground, and each pin and Vdd. Then check from Vdd to ground. You can use an undamaged part as a reference. I suggest it in that order because damage on an IO pin can create a short from Vdd to ground. If all the IO pins checkout, but the Vdd to Ground path is low resistance, the overstress happened on Vdd. There is an ESD protection circuit on the Vdd pins that is designed to handle high voltage low current spikes. If it receives a high current spike, the structure will be damaged and create a Vdd to ground short. If you want, send me a private message with your schematic and I will look to see if I can identify trouble spots to check. 

Thanks Bob.

Electrical over stress sounds plausible. I'm off on leave for the next two weeks so I'm handing follow up over to Clinton J. Over the next few days he'll do the diode check on the failed processors and we hope will come up with a smoking gun.

If it is as you suggest, an electrical over stress, then I doubt a FA will tell us much more than the diode check. With luck we will find a single I/O pin that has failed across processors from the prototype boards.

I've sent you a private message with the schematics.

Cheers,
Peter

While neither sought nor required - staff & I wish to applaud vendor Bob's detailed guidance.    (such is the first we've noted here - in which such 'MCU test detail' has been presented...)

That said - and 'Armed w/having past tech-managed at a similar semi 'giant' - might these 'added points'  warrant  consideration?

• during our past 'deliberately destructive testing' - we found it 'far more likely' for an I/O pin to become 'illegally bridged (metalized) to Vdd or to Vss' - but 'far less frequently' did the (abused) I/O pin, 'illegally bridge to both!'   (Vdd & Vss)
• the test procedure described suggests: "first diode checking I/O against ground - and then (maybe) repeating that check against Vdd.    It should be noted - perhaps more clearly - that BOTH checks must be performed - and each must prove 'positive' - for that 'I/O' to (reasonably) be deemed the, 'Vdd to Vss short agent!'    (such can easily be confirmed by realizing that (often) an I/O is 'tied to pcb ground' - and such does 'not' cause a Vdd to Vss 'short' - while the MCU is unpowered.)
• there's a  'quickly following' statement "Then check from Vdd to ground."    It is believed, 'far more efficient' to (most always) 'Start' the checking w/the 'Vdd to ground test!'    (i.e.  if 'Passed' - no other 'checking' (i.e. demanding 'multi-pin tests') are needed!)

The 'opening post' noted, "One of our engineers  ...  had a  unit fail immediately it was  plugged into one of our "front ends.".    Unknown is whether the 'other failed boards' had (ever) 'met' the 'front end!)

Any such 'board to board interconnect' - especially when the (front end, here) is 'hot' - must rise up in the 'suspect ranking.'    I don't believe that sufficient 'focused detail' has arrived to enable an insightful analysis of the (potential) 'ill effects' - which (too often) accompany such, 'board to board (likely Live) interconnects.'     

It is my  firm's (long) experience that such 'MCU Failures' - almost inevitably - are 'User Caused.'    (perhaps an earlier post revealed the 'Scope & Percent of Failures' noted - such data is (always) helpful - and 'regular presentation' saves 'wear & tear' upon (even)  'Alien diagnostic crües.')

Clinton J,

Any update on the diode check?

I am out of the office and will return on Wednesday October 16. I have asked a colleague to look into your issue while I am gone. 

Hello Peter and Clinton,

Are there any updates on the results of the tests that Bob requested?

Hi Ralph,

I've been on leave for two weeks so I'm still catching up somewhat. Clinton J performed the diode check on the failed dev kit that we still have and found that the VBUS pin (PB1) was shorted.

He hasn't had time to do much with the processors pulled off our failed prototype boards. On the prototype boards PB1 is used in its I2C 5 SDA role and is connected to a header pin which mates with a daughter board. The daughter board has a 10k pull up resistor on it and the single I2C device connected is a MCP23017 16 bit I/O expander.

Cheers, Peter

The PB1 pin has a different ESD protection from other pins as this pin is used for VBUS and is 5V tolerant. It has a 5V zener with the cathode on the pin and the annode at Vss. The 10K pullup should not be a problem under normal operation. What voltage is the pullup attached to? Have you been able to identify if the failure happens during power-on or during connecting of the daughter card? Is the daughter board powered from the same supply as the prototype card? What voltage is the pullup connected to? I would be suspicious of voltage spikes during power-on or when connecting the daughter card. The spikes may be "negative" or show up on the GND.

Hi Bob,

The 10k pull up is to 3V3.The line is connected to an I/O expander which is a 3V3 part.

The daughter board is permanently connected. It is only required to solve a form factor problem and is not a swapable system. Daughter board power comes from the host board. All power is derived from a single 5V supply. For test purposes this is a current limited bench supply. In normal use it will be VBus from a USB-C connection.

There is no clear correlation between power events and failure events. The "overnight" failures didn't involve power cycles - the units were powered continuously overnight.

OK, keep us updated. Ralf will be out next week and I will be out the next two weeks. I am going to mark your response as "TI Thinks Resolved" for bookkeeping purposes. Just respond to this thread when you have more information.

Bob Crosby said:

Ralf will be out next week

It is equally suspected that vendor agent 'Ralph' will be out - as well...     Ralf surely exploits the Autobahn's Left Lane...   (He's so tired of the 120MHz limit - imposed here)

Tag: (Almost) cannot tell the 'players' w/out the scorecard...