(Un)dead Teensy 3.1

Status
Not open for further replies.

romanchom

New member
I am building a quadcopter using Teensy 3.1, MPU-9150 sensors, NRF24L01 radio and Pololu voltage converter. After initial success Teensy has died or so I thought.
Teensy is powered through a 3.3v converter. I've cut the VUSB - VIN pads, but I've soldered a wire from VUSB to the converter input to be able to power it from both battery pack and USB and reprogam it using USB. 3.3v from is connected to Teensy VIN pin.
Having soldered everything together on an universal pcb, I've tested it, first by uploading standard blinky, then by testing the sensors. Both seemed to work. Bliny blinked and sensors read good values. The after a while it simply stopped. A tried plugging it off and on again. It blinked for a second or two then went off again. I repeated it for a few times, but then it simply wouldn't even start. PC detected no device connected either.
I've read quite a few topics about dead Teensys and tried measuring voltages and checking for shorts. VIN reads steady 3.31v, the 3.3v pin reads about 3v, but program pin reads 0v. I checked the resistance to ground an it was about 600ohm. I've read that there could be some residue from soldering so the next day I've thoroughly washed everything in denatured alcohol and dried it. There was more conduction between PROG and GND. I plugged the Teensy uploaded standard blinky and it worked... for about a minute, then it died again. Plugging it off and on again didn't help.
This time when I measured PROG pin it read anything from 0 to 3v, so I guess it switches between these two very rapidly. What bothers me most that one time it works, the next it doesn't. Sometimes when I plug it while I hold the reset button it connects to the PC, successfully uploads a program and stops working.
Yesterday I cleaned it again using more denatured alcohol and a toothbrush. After letting it dry for the night I plugged it in and miraculously it began working. I managed to work with it for well over 8 hours, after that it died on me again.
Since then I haven't managed to get it working. Normally I'd try desoldering everything and check if it's one of the other devices that might be causing problems but in this case it's so tightly soldered that it's beyond my abilities. If it simply didn't work at all I would assume I had made an error somewhere while soldering but in this case I have no idea what could be the cause of this weird behaviour.
 
Vin is the input to a low dropout voltage regulator. It expects to see 3.7 to 5.5V input and will provide 3.3V output. Supplying it with only 3.3V means it will fall out of regulation, the output voltage will be below what it should be and this explains your 3.0V finding. It also won't be well regulated.

If you have a 3V3 supply, connect that to the 3.3V pin and leave Vin unconnected.
http://www.pjrc.com/teensy/pinout.html
 
Many very different problems all manifest themselves as a "dead" Teensy. Obviously not all "dead" problems are created equal. Some are far more dead than others, especially the ones involving accidentally touching a 12 volt power line somewhere!

Almost everything in Teensy 3.1 can run with VCC lower than 3 volts, except the USB. The USB really needs good 3 volt power to communicate reliably. But if the power is weak, noisy or has other problems, of course it will still try. Some computers and some hubs are pretty good at dealing with not-so-great USB signals, but some others really aren't.

PC operating systems aren't very good about helping you figure out what's wrong. Microsoft Windows is the worst. Sometimes it will tell you a driver needs to be updated, even when the problem is USB communication errors. Apparently their drivers aren't smart enough to propagate low-level protocol CRC errors up to the user interface as anything more than a generic problem, which then triggers terribly unhelpful and even misleading on-screen messages.

If you do connect power directly to the 3.3V pin, be careful. You're wiring right up to the VCC power line for the chip. There's no protection against reverse polarity or over-voltage. But if you have good quality 3.3V power, that's definitely the way to use it to directly power your Teensy.

When/if the problem ultimately becomes clear, please try to post a quick followup here. That can be incredibly helpful for anyone else who later finds this thread by searching.
 
Last edited:
It's not only that usb stops working. Everything appears to stop working. LED that 5 minutes ago was blinking, suddenly stops, just as any USB connectivity. In all my sketches I include a piece of code that periodically blinks LED, just to see if it's still alive.

According to this thread Teensy should work with 3.3v on either VIN or 3.3v pins. Just to be on the safe side I'll try connecting 3.3v directly and see if that solves the issue. I'll update if anything changes.
 
Also, if you're running 3.3V directly into the Teensy 3.3V rails, remember to cut the Vin/Vusb connecting trace if you ever want to have a computer hooked up at the same time. Otherwise, the MK20 voltage regulator and your 3.3V supply will be battling each other.

Vin should be higher than 3.7V on account of the voltage regulator needing at least 0.4V voltage drop In order to produce a well regulated output at 3.3V. At 3.3V the internal regulator will be in dropout mode, ie not regulate at all.
 
Last edited:
It's not only that usb stops working. Everything appears to stop working. LED that 5 minutes ago was blinking, suddenly stops, just as any USB connectivity. In all my sketches I include a piece of code that periodically blinks LED, just to see if it's still alive.

According to this thread Teensy should work with 3.3v on either VIN or 3.3v pins. Just to be on the safe side I'll try connecting 3.3v directly and see if that solves the issue. I'll update if anything changes.


I'm new to teensy and only recently found out that you MUST have a good working program running in teensy 3.1 for the usb to be recognized. This is not very intuitive and will lead most to believe the teensy is dead. What you need to do when this happens is upload the blink program and press the program button on the teensy. Once the blink program is loaded, you can try to upload your program again. If again the teensy usb goes offline (or worse, keeps going on/off in a cycle), simply upload the blink program again. If usb goes off after you upload your program, it means there is something wrong with your program or I have seen at times, partial or incomplete upload can cause this as well.
 
I'm new to teensy and only recently found out that you MUST have a good working program running in teensy 3.1 for the usb to be recognized.
Very common point of confusion. A prominent brief explanation of that on the web site or in the user guide would save a lot of lost time.
 
I am more interested in why it is implemented this way, and think it is better to redesign so usb does not go offline and program can be uploaded without having a good program running on the arm processor.

looking at the schematic, I'm guessing it works this way because of usb pin 4? and pressing prog button will reset the arm processor (and go to bootloader mode)?
 
The teensy 3 ARM has no bootloader in ROM or flash. The reset causes the 2nd microprocessor (Mini-54) to reset/run and place a bootloader in the ARM's RAM. This process is detailed somewhere on this forum.
 
that's exactly what I am trying to say. if the bootloader is completely controlled outside of the arm processor, why does having a bad program on the arm processor affect the usb/bootloader? I think it should not, hence I'm curious to know why it was implemented this way.
 
that's exactly what I am trying to say. if the bootloader is completely controlled outside of the arm processor, why does having a bad program on the arm processor affect the usb/bootloader? I think it should not, hence I'm curious to know why it was implemented this way.

because, as I see it, the mini54tan is not directly connected to USB. USB goes into MK20. There is only 1 line going from the microAB to P0.0 and PTA1.

So option 1: pull 'prog' low to activate mini54tan, which could be 'sleeping' to save power,
or option 2: talk to running MK20, which then wakes up the bootstrap program.

I cannot see how you reset cpu to a good state if program is crashed without external intervention (here pulling 'prog' down). I consider the setup really a clever way to interact with a MCU.
 
so how does teensy loader wake up the mini54 to go to booloader mode when you upload a program if mk20 is not hung? by sending some signal on usb pin 4?

I understand that if mk20 is hung, pressing the prog button will wake up min54 which will reset the mk20, therefore allowing you to upload blink program, so mk20 can again function normally and make teensy accept new uploads without pressing the prog button.

since usb goes direct to mk20, and if mk20 is hung, usb goes offline and teensy loader cannot send usb pin4 signal?
 
That's how I understand it. If the MK20 ARM has a really faulty downloaded program that does a wild jump, honks the stack pointer, executed an illegal instruction and and traps, or disables interrupts forever or some such, the it cannot run its USB driver code.

Thus, the cure is to press reset and load a known-good program.

It's not like an Arduino type AVR board where an external FTDI USB to serial chip is dedicated.
 
The advantage of the Teensy setup is that we have control over USB (midi,HID etc), where the Uno FTDI configuration restricts us to USB serial only but gives as a hardware 'reset and revert to bootloader' path. So we win some and loose some.

In an ideal world we'd have a slave processor in the silicon running the USB port and giving us debug options to watch the stack and heap colliding or the array pointers running off but that remains in the propriety programer arena at the moment.
 
As I've stated before the problem is not limited to lack of USB connectivity. For all intents and purposes Teensy appears dead.

I've had a friend take a look at my Teensy with his oscilloscope and he found that on the reset pin there are brief periods of HIGH followed by longer period of LOW. Something similar to what is shown here. On his own working Teensy the signal is stable.

His guess is that there could be some problem related to the oscillator, perhaps some additional capacitance that prevents it from starting. I'll try cleaning Teensy one more time and see if it helps. Maybe there is some dirt that I've missed before.
 
I could not reach the program button anymore (teensy is sandwiched between two PCB's), shorting Prog and GND on my Teensy 3.1 also did the trick.
 
I now also have a dead teensy 3.1. My dog accidentally pulled the cable exactly at the moment I was uploading.
Now I do not see any response anymore. "lsusb" does not show anything. Also "dmesg" does not display any action.
The voltages are OK. (3.279V, < 10mV ripple).
What I do see is that all pins are still inputs, except 18 and 19 (SDA0, SCL0).
Any ideas?
 
Last edited:
As long as there was nothing physically damaged, like a ripped off usb port, it should be ok.

Try pressing the reset button or if that doesn't help press and hold the button, plug it in and then release. It should then be detected by the OS.
 
The hardware was not damaged. It was only unplugged from the PC. I secured the other side with some tie-wraps.
I already tried the all the reset stuff. No response.
 
The hardware was not damaged. It was only unplugged from the PC. I secured the other side with some tie-wraps.
I already tried the all the reset stuff. No response.

Hi kpc.
Did you found a solution at the end? I have exactly the same problem with my Teensy 3.2: It powered (I powered it) off when I was uploading the sketch.

Now it seems to be dead. No LED, no USB connection... nothing. If I press the program-button, Windows can detect something for 1/10 seconds, then it disconnects again.

I tried also to reset the Teensy while plugging in the USB. No luck with this workaround.

Hope you can save my teensy :p

Adriano
 
Status
Not open for further replies.
Back
Top