minor disaster with T3.5 board

Yeah, as stated. It appears I have blown up part of the v.reg circuit on my T3.5 board. Robot turned over, and something shorted out, duh.

I can supply 3.3V to the Teensy module from an external v.reg, but not sure how to do it properly. If I simply backfeed 3.3V into the module, the T3.5 boots up and appears to function ok, but the external regulator overheats, so I'm assuming the LP38691 doesn't like being backfed, or else it's toasted.

Is there an "easy" way to cut the trace from the LP38691 output to the rest of the ckt? Top side of the module, as the bottom side is inaccessible. Or can I desolder the LP38691? FWIW, I can't even figure out which chip is the LP38691, as none of the labelling on the chips seems to be obvious.

Maybe your external regulator simply needs a heatsink?

This chip is the LP38691:

Thanks for the quick response Paul. Unfortunately, I think it's more than just v.reg now. The existing external 5V and 3.3V v.regs on my pcb are 1A D-Pak, and have been working fine with multiple Teensy 3.1 and T3.6 boards previously. I always power the T3.x Vin pin from the 5V reg on my pcb, and run all loads from the external 3.3V reg too, so the Teensy 3.3V reg is pushing very little current off the module.

I just rigged a 0.5R resistor to measure current draw to the board, and it's 720-mA with nothing at all connected to the T3.5 module, and the T3.5 chip is getting too hot to touch in just 10-15 sec. Head explodes!

I also just reprogrammed the T3.5 with the basic blink sketch to eliminate my original program from setting any I/O pins to output which might be shorting the module, and the T3.5 chip is still cooking. Despite all this, the programs are still running fine, but looks like the T3.5 module is done.

EDIT: I did measure all of the buss voltages on and off the Teensy module, and they are all right at 3.3V or 5v, even though the chip is overheating, so I'm pretty sure the v.regs are all ok. And I don't see any obvious bridges or physical damage. I also slowed the clock down to 24-MHz and still burning hot.

One last thing. The underside USB power trace on the module is definitely cut, so I can jumper Vin power externally from the 5V reg or the USB connector.

Must be missing something here because the PTC hold current rating should force it to hi Z state if 0.72A going into power input pin and fold back input current. Look at the schematic and determine what to cut/remove to isolate to bad component. If there were no severe voltage spikes, the processor will be ok, but whatever stuff is in the circuit node that is shunting the fault current is probably dead.

Have not subjected my personal T3.5s to much stress, so no problems to date. But for my employer's stuff, have four T3.1s and T3.2s that stopped working upon severe electrical stress. Paul, we need to talk - have two Teensys that blew a hole in the processor after contact with only 1500Vdc. Oh, ever mind...

Must be missing something here because the PTC hold current rating should force it to hi Z state if 0.72A going into power input pin

Click to expand...

Ah, very astute. PTC is "gone", I pulled it off the board first thing. Along the way, I discovered the board came back to life when I shorted across the PTC with a screwdriver, so I tried to solder a wire across it, and [of course] it fell off the board. I hadn't realized the cpu was sucking 720 mA at that time. Then I soldered a piece of wire across the PTC pads in order to conduct all of the other tests mentioned above.

whatever stuff is in the circuit node that is shunting the fault current is probably dead.

Click to expand...

As mentioned above, I've disconnected everything else from the module, and also ran the Blink sketch which should cause all the header I/O pins to be hi-Z, to make sure my original program was not connecting any I/O pins to a possible short on my pcb. And the T3.5 chip is still hotter than hell. Oh BTW, my pcbs use series-Rs on all the I/O pins specifically to prevent simple short and overvoltage
disasters.

blew a hole in the processor after contact with only 1500Vdc

Click to expand...

Ummm, normally you do ESD tests using a 15pF cap to apply the 1500V, rather than a dead-short and 1A, but I'm guessing you know that, .

[Foghorn Leghorn voice] "That is a joke, son..."

Actually the 1500V was from where an electrician touched a PV string sense lead to my box with the cover off. For ESD immunity verification, did IEC61000-4-2 tests to box at 8kV (HBM) with no problems, but OT.

Paul Stoffregen has probably seen most of the microcontroller failure modes - so he should advise. But do know that after several days of OV and ESD immunity tests for the IEC61000-x-y series, micros can get intermittent and display many forms of weirdness, yet still 'generally' function and try to run whatever code you throw in it. if the micro is the only thing in current path, then damnit, it is dead, Jim.. But there could be diodes or passives in a parallel path, or in series with the micro pins that have failed in a low-Z state.

Truth is, I have no idea whatsoever how all the buss voltages can be reading ok, the module can be drawing 720 mA, and the cpu chip being hot enough to burn your fingers, and it's still running the program. No clue.

oric_dan said:

...
I can supply 3.3V to the Teensy module from an external v.reg, but not sure how to do it properly. If I simply backfeed 3.3V into the module, the T3.5 boots up and appears to function ok, but the external regulator overheats, so I'm assuming the LP38691 doesn't like being backfed, or else it's toasted.

Click to expand...

Does the Teensy MCU get hot when you feed it 3.3V - or just the external regulator? How much current does the 3.3V supply provide in this case?

If the Teensy 3.5 isn't given 3.3V - does it make it itself like I thought the T_3.2 did?

No matter how it's being powered, the MCU gets hot enough to burn your fingers. The 720 mA is all drawn by the Teensy module. The 3.3v buss pins on the module headers all read proper 3.3v. Even so, the program runs apparently correctly.

Another guy I talked to hypothesized that maybe all of the CMOS output gates on the MCU are being half turned on, which would give a through path straight to ground from Vcc through the CMOS channels.

Bummer - probably no help but there is a 15 second restore that can be done on the T_3.5. Start a 15 second timer on pressing the Program Button ( after powering ) and release at 15 seconds. Unplug and if that worked there will be no code left running when replugged.

That might hold the MCU in a state where it isn't running and maybe not get hot? Probably will be toasty in 15 seconds - but if not it might say something and the factory restore might clear up cobwebs if related to processor state that PJRC restores.

Thanks, I had not heard of that trick, and tried several times to no effect.

If it wiped the 'blink' or other code it did what it could and that much works - and the issue is external or beyond that restored state.

defragster said:

If it wiped the 'blink' or other code it did what it could and that much works - and the issue is external or beyond that restored state.

Click to expand...

Actually, holding down Prog [and also Reset] for 20+ sec did NOT wipe the program, and also did not fix the overheating problem. You apparently need input from the IDE before the program is wiped. ???

I did try one more test. I setup a loop so the program cycled repeatedly every couple of seconds to configure all of the I/O pins [except 13] to INPUT, then output HIGH and LOW, just to see if this might properly configure I/O gates that are putatively locked into half-on mode. Didn't fix the problem. So I'm out of guesses, unless maybe Paul has some idea.

My next step is to drill a hole in the bottom of my pcb so I can inspect the area around the USB connector on the module for any obvious damage, then that's about it for this board.

Actually time must be 15 secs +/- 1 { edit> yes it is actually +/-2 but:: aim small miss small } - only the Program button - no other reset or action. That way short over press won't wipe and if you held too long - holding even longer will bypass. In the process of doing that all flash is wiped and no sketch is left when powered up again, and some key settings are restored as Paul discovered during Beta. That may not work and that would be a sign there is something really wrong with your Teensy or the board feeding it.

With your physical/voltage attack it probably won't relate - but is harmless and easy enough to try just in case some issue like noted in p#9 has something internally confused.

oric_dan said:

Actually, holding down Prog [and also Reset] for 20+ sec did NOT wipe the program

Click to expand...

The program wipe feature is not 20+ seconds. It's *exactly* 15 seconds. The bootloader actually looks for a press that lasts between 13 to 17 seconds, so you're allowed +/- 2 seconds. If you hold for 20 seconds or more, you'll miss that window.

Whether or not this program wipe will help is anyone's guess. Seems very likely the hardware may just be damaged. But to even try the program wipe, you really need to look at a stopwatch or clock with seconds when pressing the button, so you can hit that 13 to 17 second window.

Aha, ok I held Prog for "exactly" 15-sec, and it did wipe the program this time, but did not fix the finger-blistering problem. So I guess it's T3.5 = RIP.