Dead Teensy 4.1, Don't Know Why or How

Not open for further replies.


I'm using Teensy 4.1s for a university project. I have had 2 die for seemingly no reason in 2 completely different circuits. Both don't power on at all and the onboard 3.3V converters get really hot. The most recent one has a short between the 3.3V and GND pins that does not seem to be from any external wires or parts. I can't recall if the first one had this short as well. Both circuits were working fine for a while and then suddenly broke. The most recent board has produced a very quiet high pitched sound since I got it, so maybe that is associated with the issue.

Is there any known issue that would cause this on the Teensy 4.1? I saw one other forum post with a similar issue but in that case there were "symptoms" leading up to the failure. In my case the boards were working perfectly fine and then randomly died. I have a couple 4.1s left to continue testing with, but I'm concerned that the same thing will happen and I won't be able to finish the project.

Some components connected:
- BNO-055 STEMMA from Adafruit
- 2 Servos, powered directly form battery
- 5V buck converter
- BMP388 from Adafruit
- INA260 from Adafruit
- SPI SD Card from Adafruit
- 2 MOSFETS, IRL88721
- TPS61023 MiniBoost from Adafruit
- Piezo buzzer
- 2 LEDs
- 2 Buttons
- Several resistors: for pull-down, LEDs, and for the MOSFET signal wires
Avionics Bay Circuit Diagram.jpg

Here is the circuit diagram. Please let me know if anything on it is confusing or looks incorrect.
I also found the first Teensy that stopped working and it also is shorted between 3.3V and GND.
T_4.1 has a faster SDIO card holder on board - maybe not handy as installed? But running from 5V instead of 3.3V input?

Are the servos still functional and not sending over 3.3V out on signal line - seems I saw a note about ability to have that happen.

Anything (but barely) over 3.3V - except VIN and VUSB - is expected to end the 3.3V Teensy 4.1.
We are using the separate SD card board to avoid the possibility of the SD card popping out due to vibration.

The servos still work fine. I've never heard of a servo sending voltage through signal the other way, but I could add resistors on that wire to avoid that possibility.
That is one weird way to drive MOSFET gate, I have never seen such example in any reference/datasheet/application note. Especially for a FET with somewhat usable Id even at Vgs 3.0V. That boost-converter will boost the gate drive voltage, but it has probably quite slow up/down ramping, compared to the I/O-pin itself. Considering that energy from the IO-pin used as the Vin for the booster needs to charge the booster's capacitors, inductor, and finally the FET's gate. FETs don't like to stay at high currents with the channel being (relatively) sluggish and at high resistance for a moment. Then again, if those "igniters" work as I think they do, it is short burden occasionally, so should be ok in that sense.

Depending on how much current those igniters need/are allowed to draw from the battery, I think those FETs might work just fine (maybe even better) even with just I/Opin-resistor-gate (though not necessarily at cold temperatures). Hmm... somewhat high gate capacitance to be driven, so it might still be a bit sluggish turn-on, though should still be much faster than the voltage booster. But then again, if current design has 10k-ohm passive leak turn-off, and it actually has to leak the booster's output filter capacitor, too, and it isn't a problem.. Or is it?

The "proper" way to drive a bigger FET gate to higher gate voltage is another (smaller) transistor (with smaller and easily driven gate/base, controlling a steady higher voltage) or beefy opamp/comparator (with higher supply), etc. And often with a resistor between driver and the gate to limit the peak drive current (so the driver is not overloaded and/or to limit EMI).

Another thing that sticks to my eye is the "Igniter" which has not been specified. "vibrations" have been mentioned, so I'm guessing an engine controller of some sort, and thus... what kind of igniters? I wonder how they behave on their Vcc/GND connections, e.g. high voltage spikes that would blast through the FET in various directions and/or spike the ground?

Edit: oh wait.. that type of FET controlling high-side voltage with ground-based gate drive... uuuh... maybe it works with igniter-stuff, but otherwise, very weird. I'd double-check that part of the design. In any case, driving directly with the IO-pin wouldn't be working quite as well, if at all.
Last edited:
My thoughts: no fuse on the +ve from the battery is bad news - these batteries can source vast currents on a fault condition.

You try to power a boost converter (which contains an inductor) from a Teensy pin? That's quite enough to explain frying
the chip - inductor circuits can generate high voltage spikes, and the Teensy pin cannot handle large currents such as a
boost converter inrush spike.

2S LiPo may be too much for a servo, which are usually rated for 7.2V (2S Lipo can be upto 8.5V fully charged) - this again
could conceivable lead to a failure that propogates back to the Teensy pin - it might be OK though, but the servos are going
to be much hotter than designed for if loaded - increases risk of them cooking.

Secondly its not guaranteed that some random hobby servo is able to be driven reliably from 3.3V logic - best
to level-convert the servo signals to 5V if any doubt.
We haven't had much of an issue with the MOSFETs, they weren't even being used in the code that was being run when the board failed. In tests the MOSFETs don't seem sluggish at all and when the I/O output is boosted to 5V it opens more than on 3.3V. This board is going to be used for avionics on a model rocket, and the igniters are the same as those used as Estes rocket motors.
The inductors may be a problem and I'll look into it, but it definitely didn't cause this failure. The MOSFETs and thus the boost converters were not in use at the time.

The servos we are using are designed to run on a 2S LiPo. We have had no issues running it from the I/O pins in testing.

The code being run at the time of the failure was only actively using the BNO055, the servos, the buzzer, and both buttons.
My comments on the FETs were mainly a reply for the "Please let me know if anything on it is confusing or looks incorrect."

"Sluggish" is of course relative, but consider the difference of running possibly amperes (just guessing on the basis of the chosen FET) of current over a non-insignificant channel resistance for 1 millisecond vs. perhaps 100 nanoseconds. Order of magnitude 10000x more power turned into heating the FET rather than getting to the load. It depends on the exact numbers and use cases whether that matters or not; there are cases where the FETs are deliberately used in that region of operation, with appropriate cooling. But typically in power switching use, the switching time is desired to be short (in the scale where milliseconds are considered very very slow).

The booster certainly makes the driving voltage (relative to "ground") higher, but so would a proper gate drive circuit, and it would do it faster, causing less expected load on the IO-pin, separate it better from unexpected loads, would be cheaper (well, those booster parts have already been bought, so no savings until they break for reason or another), and would actually work much better than the 5V drive in driving the gate. And weight less (well, grams, milligrams, but still).

With the last part of my reply, the "edit"-part, I was referring to the use of that N-channel FET, which, with its gate driven with 5V relative to "ground", has its actual gate voltage relative to its source. As the FET opens a bit, the igniter's Vcc may start going up (though I have no idea how quickly), which in turn makes the gate-to-source voltage smaller, so it doesn't necessarily ever see the 5V over gate-to-source as expected. I wonder, have you actually used oscilloscope to measure the gate to source voltage when turning the FET on in that circuit? (Note, not gate-to-ground voltage. And note, if trying to do that, if there are voltage spikes, the scope/probes will need to be able to handle them...)

A proper way to do high-side supply switching is to either drive the gate higher than supply voltage (charge pumps or such) with that FET type, or use a FET type and arrangement where the gate sits at the supply voltage (not at ground level) while closed, and another transistor is used to pull that gate down to ground to open the FET. The latter will give the full supply voltage for the gate, and does not depend on how the voltage changes on the igniter side.

Alternately, one could switch the low-side of the igniter instead, with that FET already used, but that may have its own design quirks to consider.

We have had no issues running it from the I/O pins in testing.
This is just hypothetical example, but...
Note, some issues do not show up immediately, causing problems that can combine with another event later. For example, a random occasional high-energy spike from a servo could at first break a protection diode for a IO-pin inside the SoC. The pin still works, no immediately detectable problems appeared. Some time later, since the protection diode isn't in proper shape any more, e.g. a random tiny ESD-spike from wherever could finish the job. Seemingly leading to explanation "No servos in use at the time, so that is not the problem", when in fact the servo was the main cause...

Or some kind of failure cascade. A real life example: a PC PSU had its standby 5V supply rail's first filter capacitor fail (slowly over time, the famous case of bad caps from far east). This caused its primary side components having to work harder, which they had definitely not been designed for (cheap design, working at near max even when everything is good), which in turn led to a current measurement resistor to fail (burn via overheating), which in turn caused currents to get too high for a zener, which thus broke, which in turn let the controller/switch chip see too high voltages... (I may recall some details wrong, been years.) The thing that looked to be the obvious "issue" was the severely burned resistor, but if one only looked at that, it would have lead to thinking of wrong original cause...

All that said, the reason may very well be something/anything else than so far considered here, too. I did spot a thread here about how a specific arrangement of code can lead to the user's Teensies breaking randomly later, but adding couple extra lines of code (merely adding a bit of delay in there) makes all good...
Both don't power on at all and the onboard 3.3V converters get really hot. The most recent one has a short between the 3.3V and GND pins that does not seem to be from any external wires or parts.

Yup, that sure sounds like something is shorting out the 3.3V power. I'd start by measuring the actual voltage on 3.3V to GND.

Usually a very low voltage, like under 0.1 volt, means the short is due to metal. If you can find & remove the metal (solder, wire, etc) odds are pretty good Teensy will work again. It usually survives this type of short.

But if you see a voltage like 0.6 volt, that's usually a pretty bad sign the main chip has been destroyed. The most common cause for this sort of failure inside the chip is higher voltage accidentally touching the 3.3V power line. Of course it's theoretically possible with any pin, since none of the pins are 5V tolerant. But driving the 3.3V power up to 5V or more for even a brief moment is the usual way to end up with a short-inside-the-chip result that measures approx 0.6 volts.
Not open for further replies.