How'd I fry my Teensy?

Status
Not open for further replies.
N

Netzapper

Member
I'm trying to make a musical instrument from a Teensy 3.2. I had the Teensy's side pins plugged into a breadboard for structural support, with male headers rising from the Teensy for the end connectors. I had the A14 DAC output wired into the `+input` on a TI LM 386N-1 audio amp, which I was driving using the Teensy Audio library with `AudioOutputAnalog`--software is solid, not (directly) the problem. The amp was powered and grounded from the Teensy's Vin and GND lines, respectively (which seem to be USB voltage and ground). The rest of the pins on both the Teensy and the amp were open (but stuck in the breadboard). [Let me emphasize that I did not short all the end pins together in a row of breadboard; they were headered "up", not "down".]

I have one of the Seeed DSO Nano scopes--not very good, but good doesn't really fit my budget. I plugged the ground probe into the ground rail of the breadboard, and began probing various parts of this system. I definitely probed the output of the amp, as well as the DAC signal, multiple times. I did not probe random pins of the Teensy, only DAC. I never moved the ground probe, so the amp output was eventually shorted to ground through the scope probes... was this my mistake? If so, how (physically) did shorting across the scope harm the Teensy?

At some point, the Teensy stopped working. Removing the probe and cycling the power didn't help. I removed it from the breadboard. I've tried new USB ports, cables, and host. It now seems quite dead: not running my program (no proof of life), and doesn't connect to the loader when I press the button.

Since I'm a software guy, and frying hardware is most of my electronics hobby... I'm not so upset that the device is toast, but I'm confused what I did. What protection should I have added to the circuit before powering or probing it? I just want to know what probably happened. Or even what *might* have happened.
 
In the hope that your Teensy isn't fried (and just a software guy myself) I offer this link to some steps that may show it to be working. I've seen my Windows 10 system with IDE 1.6.6 "LOSE" devices for a time recently and steps like these get it back in the fold. The other thing is if you have a second Teensy ( one is nowhere near enough ) - plug that in and do some simple sample - perhaps the one in the following post - and then return to the Teensy in question as it may get the OS set right to repeat these steps:

Can-t-communicate-with-Teensy-3-2-through-Teensyduino
 
Normally scope probes are 1M to 10M impedance, so they're very safe to touch to most things. Shorting output pins to ground isn't good, but usually it doesn't kill a Teensy. Everything you described is pretty unlikely to cause damage.

Shorting 5V power to the 3.3V power will quickly kill a Teensy 3.2. Shorting any pin to a negative voltage can kill it. Those aren't described, but they can happen by accident if multiple separately powered things are connected together and a wrong wire touches something by mistake.
 
defragster said:
In the hope that your Teensy isn't fried (and just a software guy myself) I offer this link to some steps that may show it to be working. I've seen my Windows 10 system with IDE 1.6.6 "LOSE" devices for a time recently and steps like these get it back in the fold. The other thing is if you have a second Teensy ( one is nowhere near enough ) - plug that in and do some simple sample - perhaps the one in the following post - and then return to the Teensy in question as it may get the OS set right to repeat these steps:

Can-t-communicate-with-Teensy-3-2-through-Teensyduino
Click to expand...

Thanks for the response, but I'm pretty sure it's fried. I precisely followed the steps in the post you linked, but nothing changed.

I'm running linux... `dmesg` shows no connection event either on plugin or after the programming button is pressed (or released then pressed, if pressed on plugin). If it's somehow alive, it's definitely not speaking USB anymore. :)

Additionally, my program (sketch?) included a proof of life LED pulse--this went out before I started any of this debugging process. But, I suspect (based on how it's wired) that the program button press overwrites the user program contents with a program loader--I'm not sure; I can't find much HalfKay documentation.

PaulStoffregen said:
Shorting 5V power to the 3.3V power will quickly kill a Teensy 3.2.
Click to expand...

I bet this is it! I had male headers on all the end pins, and 3.3 and Vbat are right next to each other. I bet I shorted them with the probe!

I'm dropping by SparkFun tomorrow to pick up another couple Teensy's (actually LC's )... this time I won't put headers on the voltage supplies! A valuable lesson.
 
Netzapper - the program button just takes the Teensy offline and into program mode. It does not alter the user code - until after the programming exchange with TeensyLoader.

VBat wants 3.3v to power that part of the RTC system. Shorting to GND on the other to side is a question for Paul if the short would be fatal.

About your note, by the way, recently on my Win 10 system as noted this is now regular recurring behavior : "no connection event either on plugin or after the programming button is pressed (or released then pressed, if pressed on plugin)." as well as after freshly powering or connecting the device. Something is amiss but not yet able to pinpoint it. [ Caveat: My recent experience is using the ILI9341 Touch display in a header and it may be the system or the display flopping in the socket header as I pick it up, or other I haven't figured out yet. ]
 
defragster said:
Netzapper - the program button just takes the Teensy offline and into program mode. It does not alter the user code - until after the programming exchange with TeensyLoader.
Click to expand...

Are there docs on it?

The schematic doesn't show a connection between the M0 core and the USB. And I can't find evidence of a loader in the arduino-style infrastructure code (which is linked in at 0x0000). Only way I could figure it works is that the M0 writes a loader into the M4 on button press.

What cleverness am I missing?
 
VBAT is meant for connecting a 3V coin cell, to keep the RTC running while regular power is off. Details here:

http://www.pjrc.com/teensy/td_libs_Time.html

Do not connect more then 3.3V to VBAT.


Teensy 3.x & LC are designed to give your program all the flash memory. No portion of the main chip's flash is reserved for the bootloader. When the chip boots up, your program is the very first instruction to run. No bootloader starts up first, as happens on regular Arduino.

The idea is your code is running on the main chip as if it was preprogrammed, without any other code present. With a normal bootloader like Arduino uses, your .HEX file may or may not actually work when programmed onto a completely blank chip, because the bootloader starts first and does stuff before it allows your code to run. With Teensy 3.x & LC, I went to great lengths to avoid interference, so your code has all the memory and starts up directly from hardware reset or power-on reset as if it had been programmed onto the chip by a dedicated chip programmer.
 
Paul - would a short of the 3.3v pin to GND often survive? The PolyFuse is on the USB incoming?

About 3.3v onto VBAT - would the 3.3v while teensy powered cause any trouble? I was expecting not if he shorted those two pins.
 
defragster said:
would a short of the 3.3v pin to GND often survive? The PolyFuse is on the USB incoming?
Click to expand...

Usually the hardware survives shorting the 3.3V pin to GND. I have personally (and unintentionally) verified this on several occasions! ;)

On Teensy LC, 3.0 & 3.1, the regulator inside the chip has circuitry to limit the maximum current. Likewise, the LP39691 regulator on Teensy 3.2 has internal protection for over-current and over-temperature. The PTC resistor (aka "polyfuse") doesn't come into play in these scenarios. But it does limit current if you short VUSB or VIN directly to GND.

Neither of those regulators can do anything if the voltage is externally driven higher than 3.3V. They don't have a huge transistor which can route current to GND in a desperate attempt to keep the voltage from going too high. The MK20 is rated for 3.6V max, and somewhere around 4V is where damage can occur. Touching 5V to the 3.3V power does kill a Teensy.


About 3.3v onto VBAT - would the 3.3v while teensy powered cause any trouble? I was expecting not if he shorted those two pins.
Click to expand...

There's a pair of diodes. You can see them on the schematic.

As VBAT approaches 3.3V, it will begin contributing to the regular power supply current. VBAT is meant for a 3.0V coin cell. The diodes prevent reverse current into the battery and allow the 3.3V power to run the RTC normally, so the battery is only used when regular power is off.

Applying more than 3.8V to VBAT can also damage Teensy. The max is 3.6V, and the diode is a schottky, so it has lower forward drop than a regular silicon diode.
 
PaulStoffregen said:
Teensy 3.x & LC are designed to give your program all the flash memory. No portion of the main chip's flash is reserved for the bootloader. When the chip boots up, your program is the very first instruction to run. No bootloader starts up first, as happens on regular Arduino.

The idea is your code is running on the main chip as if it was preprogrammed, without any other code present. With a normal bootloader like Arduino uses, your .HEX file may or may not actually work when programmed onto a completely blank chip, because the bootloader starts first and does stuff before it allows your code to run. With Teensy 3.x & LC, I went to great lengths to avoid interference, so your code has all the memory and starts up directly from hardware reset or power-on reset as if it had been programmed onto the chip by a dedicated chip programmer.
Click to expand...

That's awesome. And it's pretty much what I thought. Except I just figured the programming button caused the M0 core to rewrite the M4 core using the EzPort (or similar), after which the M4 would reset and run the loader code.

Does all this mean Teensy is compatible with using an RTOS instead of the Arduino framework?
 
Last edited:
Yes, you can use an RTOS or any other code.

However, if you load code that doesn't listen for the auto-reboot request (and presumably you're using some other tool without the ability to ask Teensy to reboot), you'll have to press the button to initiate each upload.
 
Wow, Teensy really is awesome! I'm stoked that I can get real bare-metal access to an ARM chip while still having an onboard programmer/loader. I've wanted something like this for a while, and the price just makes it impossible to resist. Having to push the button is a tiny, tiny price to pay for that kind of freedom and value.

I'm picking up 2 LCs and another 3.2 today (Sparkfun is like 45 minutes away, otherwise I'd order direct). These are getting a *lot* fewer headers...

I do wish I better understood the lowlevel programming/loading process, but I'm getting the impression you consider that your secret sauce. Fair enough. :)
 
Status
Not open for further replies.
Back
Top