Teensy 4.0 DOA - No 3.3 v


I purchased three teensy 4.0's a while back, and just opened the packets to find two of them not recognized by windows/usb.

Seems to be the same timefram as this person, who observed the same issue:

I know they are way out of warranty...and I should have tested them on arrival (lesson learned)...but was there a solution to resurrect those effected in this batch back in 2019?

0.2v on the 3v pin
Not recognized when plugging into windows 10 via known good usb cable.
No unusual heat issues observed on plugin (no shorts suspected)
Suspecting F1 might be the issue.
3v pin has zero volts (using a fluke multi-meter)

Last edited:
F1 continuity is ok.

Powering via USB, I don't see any power presented to the + side of F1.

I ran a wire between the pads and F1, and can now see 5v on both sides of F1.


I can see 5v power on the output of Q1, and now I see 3.3v on the 3v pin.
Last edited:
the "Blink" program is now running.

But the LED on PIN 13 is dull, measuring 1.7v, and still no USB comms.
Last edited:
With the IDE open give the Button a Press - it should appear then in the Teensy PORTS list as bootloader?

Attempt to upload a Blink example with USB: Serial selected and if all is well it will then appear.
With the IDE open give the Button a Press - it should appear then in the Teensy PORTS list as bootloader?

Attempt to upload a Blink example with USB: Serial selected and if all is well it will then appear.
IDE 2.2.1
No reaction to when it is powered up and blinking, and the IDE is open. No changes. No recognition in windows.
Inspecting the second DOA 4.0 in the same batch:

Plugged into USB, there is 2.2v on the positive side of F1.
There is 5v on VIN.

I am wondering if this batch had some malformed traces.
If the code isn't running any USB stack that can be the case - though the factory blink does appear as a RawHID device.

Attempting the 15 second Restore might get it back to that state:
> Power the Teensy by USB and hold the Button for an expected 15 seconds
> The RED LED by toward the USB connector will FLASH at about 13 seconds
> Release the Button when you see that FLASH {there is a window of that 13-17 seconds for the Flash and Release of the Button}
> The RED LED should then glow for some 30 seconds perhaps and then resume a Blink sketch, and appear as RawHID above.

If that fails there are other issues that PJRC can consider perhaps as they track the history of such issues.

Upload a clear Top and Bottom photo - hopefully showing focus on the PCB toward the PIN 0 GND side of the USB connector on the top.
There is something of a batch indicator there on the USB corner in silkscreen you can see one with a blank and the other with some bars here above pin 0:
Thanks defragster, I appreciate your time.

The 15 second reset responded with the red LED, and then reverted to Blink.
No Teensy USB port appearing after that.

The fact that there are peculiar voltages around the circuits to me suggests mechanical fault.

The Blink LED is pretty dim too, (1.7v on pin 13 High) so I think there are more hardware issues with these two boards.
Last edited:
Some fault indeed it seems - to have a working 15 sec Restore says the BIG part is working - with the added power wire. But not having USB then indicates problems outside that.

2.8v found on F1, and on the output of Q1.

I added a wire jumper between the 5v pads and F1, and Teensy number two is now up and running!

Blink has a strong bright LED, with 3.3v on pin 13.
Glad you got those boards running.

As for the cause of problems, difficult to say. This looks very old, probably the very first batch of Teensy 4.0 from September 2019. I don't have great info that far back. It was a crazy time where we had been beta testing since January, including the RT1052 to RT1062 change, and people were really wanting it to release, but still a huge backlog of library porting and other software issues remained. I do recall one of the common problems (probably the most common issue) on those old boards was damage to the D1 and D2 diodes in the lower right corner (near pins 11-12), which affects the board's ability to power up. Those 3 pin diodes are physically weak. The contract manufacturer who solders all Teensy boards made at least 3 revisions to the stencil in those early days to adjust the amount of solder paste on those diodes (and probably other issues... like most CMs they're not so forthcoming about such problems). In early 2020, before the pandemic hit, I do remember we looked at the cause of Teensy 4.0 boards that had failed testing and almost all were due to the diodes. We later switched to a single 6 pin diode array which is physically much stronger and solders more reliably. Symmetry really helps during reflow soldering! Since 2020, we had to switch sources for several parts due to the 2021-2023 component shortages, but the diode was the only change motivated by a known quality problem.

From your measurements, seems like a problem in the PCB or soldering would be the only explanation. Difficult to imagine, but getting 5 volts at the VIN-VUSB pads and then only 2 volts at the PTC fuse which ought to be directly connected really can't be explained any other way.

Also hard to understand how it could have passed testing here on PJRC with a faulty PCB trace. Every board goes through bed-of-nails test that checks every power, ground and signal pin. The bootloader and restore image are written during that test. The bed of nails test powers the board up many times (and uses 100 resistors to discharge all the capacitors... part of the reason Teensy 4.0 has so many special test points on the bottom side), using all GND pins and only 1 of the power pins, and then with the VIN power pin and only 1 of the GND pins. Then every board goes through a 2nd test where the USB cable is plugged in and the pushbutton is pressed. The LED blink program is loaded into flash during that 2nd test. If your board has the bootloader and it came up with the orange LED blinking once repaired, that's a sure sign it passed both tests back in late-2019. Maybe it somehow failed later? I'm having a hard time imaginging how that could be possible. Maybe there really is a problem with the trace inside the PCB but it somehow conducted well enough during both tests? Maybe the way the board was pressed onto the pogo pin in the first test, and the way it was physically held in the 2nd test could have caused the faulty wire or solder to make temporary contact? Or perhaps the solder to the fuse was marginal and adding that wire also reflowed the solder? Must admit, I'm really guessing at possible (even if unlikely) explanations that could fit the known facts.

Wish I could know more about this situation, but this speculation is really the best I can do.
Last edited:
Thanks for the response @Paul!

I feel quite empowered resurrecting the one that has come good. The third one should be fun to fix also! :)

Agreed, I couldn't see how the program could have been loaded unless it was good back then.

The power of the 4.0 is awesome. I have been able to do away with fragile setups with SD cards and wires playing pre-rendered LED animations...as they can now be computed in real time!