teensy 3.1 died

Status
Not open for further replies.

mc200x

New member
Hi,
I've played with Teensy 3.1 for some days, but this afternoon it stops running. My computer (and other) doesn't recognize the teensy board anymore.
I've tried to change USB cable, shutdown PC, change USB port. If I search in my Windows Device Manager I can't find Teensy as USB HID (yesterday I seen it)
I was uploading some new sketch while teensy bootloader stopped without uploading it completly. After, I was able to upload new sketches only by pressing Reset button but sometimes Teensy bootloader stops and freeze with progress bar indicating Programming...
Now Teensy is died, so I can't see it connected on the PC and I can't upload anything to it.
If I connect teensy to usb I can measure 3.3 V with voltmeter on the pin 3.3.

What can I do? Maybe I need to reflash something on the board?

Help me

Thank you
 
I know this is an old thread, but I've had a similar experience as mc200x.

I've got 2x Teensy 3.1's and while downloading to #1, the downloader gave me an error.
I tried to download again and nothing happened.
I've check the voltages, tried #1 on 3 different PC's, tried different cables, etc.
Tried holding down the program button while powering-up, still nothing happens.
The LED never blinks.
#1 doesn't show up in the device list.

All this time, #2 is running the same sketch that was being downloaded to #1.
#2 is working just fine.

Any ideas or suggestions on how to bring #1 back to life?
Do I need to re-flash a low level bootloader? If so, how do I do this?

Thanks in advance for your assistance.
 
Try using the reset button on the Teensy 3 to initiate that side of the bootloader.

As I recall, a crashy program in the Teensy's memory (like your incomplete download) requires use of the reset button.

When doing so, download a known good program like blinky in the examples.
 
Thanks for the reply.

After reading thru other posts in this forum, I've concluded that the MINI54 chip on #1 has quit working.
All the voltages are good.

I checked the button by checking the PROG test pin... 3.3v Button up, 0v Button down
Checked the reset test point (R)... 0.1v Button up, 0.1v Button down
This pin should measure ~3.2v Button up, 0v Button down

The MIN54 controls the reset for the uController. If reset never goes high, the uController will never start.
That's how I've reached my conclusion.

Now there are other things that could be going on, like the crystal not running. But I don't have a means to check that right now.

In the meantime, #2 is still chugging along in development.

I may just have to write-off #1. If I find out anything more, I'll post the info here.
 
@drjack, how old is that Teensy 3.1? If it's recently purchased, email me directly (paul at pjrc dot com) and we'll arrange to get you a replacement.
 
Paul

Hey, you just helped me on another issue, but, I also had a Teesny 3.1 die last week. I sent email about this to your web site, never got a reply, didn't think about the Forum - anyway, i ordered and received 2 more teensy 3.1's to keep development, but, i had asked some Q's and never got any reply, so i will re-ask them here:

I was powering the Teensy board via the USB port at 5 vdc. The on board v-reg on the Teensy 3.1 is still good, it still puts out 3.295 vdc. The mcu itself felt normal - just warm to touch, not hot.
I was working on a sketch and noticed it started behaving oddly the last time i uploaded. Parts of the program that had been working rock solid started glitching. I re uploaded and it got worse, then the led went off and the board stopped. The reset button didn't do anything, so i concluded the board / mcu died.

However, the board is soldered to a teensy Audio Sheild board, and i never desoldered them yet, so it 'could' be the audio sheild has shorted out, i doubt it, but it is possible. The LED on the Teensy no longer works.

Is there a problem running the board for extended periods on 5 vdc via usb port? Also, I am using Rx1 and Tx1 to communicate with an Arduino UNO board which is also being powered by a separate USB connection at 5 vdc. The digital i/o pins on Teensy 3.1 says it can take 5 vdc inputs, but, would that be a problem to have it connected full time to the Arduino with the Arduino Uno tx putting out 5 vdc and the Teensy 3.1 Rx1 receiving 5 vdc all the time? Other then the Arduino connections, I had it soldered to an Audio Sheild board, that was all external connections to the Teensy, so nothing should have over loaded it, and nothing shorted out the board. It just stopped working.

And, another question while i'm at it - I am running the baud rate at 250,000 between the UNO and Teensy, the Uno board is connected to 240x400 TFT LCD that has a (slow) UNO interface. I am using the UNO as a serial interface to the LCD, so i need fairly fast communication rate so i can update the screen with some level of response. I do get communication errors now and then (fewer at 250,000 baud then at 38.4k), and haven't been using error detection, i am going to add CkSum to the protocol and if the ck sum is bad to ask Teensy to resend the last command/data (I am running the UNO with 256 byte of serial buffer - modified from the 64 byte default, and have to send packets of data to the screen at a time, wait for the controller to tell the UNO it is done updating those pixels, and then telling the Teensy it's ok to send another packet)

I was wondering though, should i use a transistor to translate the TX on the Teensy to 5vdc for a better signal on the UNO's rx line? The Teensy is just giving a 3.3 volt output, right? Or does it just output to ground and the high is a pull up? Could i just add a few resistors to pull up to 5 vdc on the UNO side, or do i need a voltage level conversion? Would that help on bad data? I am going to up the data rate to 500,000 baud once i add in the cksum so i can keep the update to the screen reasonable.

Thanks, Jim
 
I'm sorry to report that Teensy #2 has met the same fate as #1. It's died last Tuesday (11/25).

Here's a recap of the circumstances leading up to the failure....
Downloads started getting flakey. Sometimes the downloaded sketch would automatically start, sometimes the program button needed to be pressed.
The final downloader reported a download failure. The download progress bar was a little over half way.
After that failure, I can't download, the Teensy does not appear in the device manager. It appears dead.

I looked #2 over with a magnifier and notice a white powery looking substance around the inside pins of the Mini54.
Washed it away with isopropyl alcohol . Dried it thoroughly.
It looks pretty (no more residue), but still does not work.

I've checked all the voltages. They are OK.
The program button is working.

Testing the Mini54 operation.... (With a VOM)
On power-up, pressing the program button, causes the reset test point go low (0 volts)
Upon releasing the program button, the reset test point only rises to between .1-.2 volts.
When I press the program button again, the reset test point stays at it's .1-.2 volt level. It never goes to 0 volts again.

The only common thing is that both Teensy's failed on the same PC. It's running Win7.
The other two PC's that the Teensy's have been connected to were Linux machines. But I don't see how the OS could cause this problem.
Is it possible that the Win7 PC has some kind of USB problems that is affecting the download process?

The circuit I've got connected to the Teensy is an image sensor. The sensor runs on 3.2 volts being supplied by the Teensy. There are not any external power supplies nor any test equipment connected to the circuit.
The sensor has been working from the very beginning. We're in the software development stage working to get the data we need for our application.

I'd like to hear any suggestions if there is anything I've missed in troubleshooting this pair of Teensy's.

Has anyone else had this problem where the Teensy stops working after a download failure?

Till my next order comes in, I'm dead in the water.
 
Seems I've had the exact same problem as you. Have 2x teensy 3.1 boards. Got them at the start of December, and have been doing something (I think) fairly simple with them: it's hooked up to a Z80 cpu and a 2.2" SPI TFT. So it uses quite a lot of the pins, but there isn't much else happening, I was building it to write an educational blog post on the z80 and cpu timing, so there are lots of delays in the code so you can visually see what's happening and it is not running flat out. The binaries I flash are around 43K and use ~5K ram. I'm running the Z80 at 3.3v, btw.

The first board I started with was going great, then I got:
Please press the RESET BUTTON on your Teensy to upload your sketch. Auto-reboot only works if the Teensy is running a previous sketch.

Now, I thought this very odd, as it _was_ running a sketch. The sketch only stopped when it attempted an upload which seems to have failed in some way - but I never got an error. Pressing the button made it flash, but after about 5 flashes, this didn't work. At this point I switched to my other teensy, and within about the same time the exact same thing occurred. With this second device, I tried various things to flash it and eventually found the "unplug from the PC, press the button and connect it before releasing the button" trick. This worked for quite some time - however, I noticed that the sketch would not run without being rebooted from teensyloader. Just plugging the teensy into USB power didn't do anything, nothing ran. About 20-25 code updates later using the method, the device seemed to die, teensyloader does not find it. The reset pad measures 0.1v.

I tried the first device again, and it flashed automatically first time without the trick being required. However, measuring the voltage of the reset pad on this one returns a curious 2.8v. 'loader button' ressed it's 0v as expected. I can't try the first device in my z80 circuit just now, as I'll need to solder on some more back-side headers. But it's running blink fine, without needed a reboot like my first device did.

I really don't know what is going on here :) I'm using the latest v1.20 on windows 7 64bit. If the issue occurs with my first one again I'll try to capture as many logs as possible, as I missed all of the verbose output from the first device as sadly I didn't know any better.
 
You know what, I've realised whilst writing that i'm powering the z80, the tft, backlight and some other LEDS all off the 3v pin of the teensy. Would an overload of the onboard regulator give this failure result? The first teensy ran without the screen/backlight draw.
 
Pulling too much current could cause the problems where it can't automatically reboot.

In theory, the internal voltage regulator is supposed to shut down if too much current is drawn. In practice, when you connect a lot of stuff, things can be pretty complicated and hard to predict. Especially if logic conflicts are present (both Teensy and something else driving a pin at the same moment), all sorts of things can go wrong.
 
Pulling too much current could cause the problems where it can't automatically reboot.

In theory, the internal voltage regulator is supposed to shut down if too much current is drawn. In practice, when you connect a lot of stuff, things can be pretty complicated and hard to predict. Especially if logic conflicts are present (both Teensy and something else driving a pin at the same moment), all sorts of things can go wrong.

Hi Paul, thanks for the very quick reply. I'll fix up the other teensy up with the headers I need and power off of an additional regulator. The first unit I had seems to have come back to life so will monitor it for the same issues.

Cheers!
 
Ok, same thing!
My Teensy 3.1 just died while loading a program. Was working fine a long time and now nothing.
Is there a way to load the Teensy with a JLink Segger (I have one) or something without using the MIN54 (which seams to be broken)?

I guess this is the Verbose Information of the crash:

11:09:54: Teensy Loader 1.20, begin program
11:09:54: File "name.cpp.hex". 36628 bytes, 14% used
11:09:54: Listening for remote control on port 3149
11:09:54: initialized, showing main window
11:09:55: remote connection opened
11:09:55: remote cmd: "comment: Teensyduino 1.20 - MACOSX"
11:09:55: remote cmd: "dir:/var/folders/3p/52d4t63n3gn0t9n5b0mw6ffh0000gn/T/build6333816423843210145.tmp/"
11:09:55: remote cmd: "file:name.cpp.hex"
11:09:55: File "name.cpp.hex". 36628 bytes, 14% used
11:09:55: remote cmd: "status"
11:09:55: status data sent
11:09:55: remote cmd: "auto:eek:n"
11:09:55: remote connection closed
11:09:55: HID/macos: no devices found
11:10:12: Verbose Info event

It would be very nice to get the Teensy up and running again, cause it is soldered on a prototype which is needed.
 
Last edited:
So I've been using my other teensy 3.1 as mentioned in the other post, and some interesting things have happened. I've managed to grab some logs, too.

My larger z80 project was working well, autouploading a few flashes. then the same thing happened again, download error, and had to press the button while plugging the usb in for it to flash. I reflashed blink, then the z80 sketch autouploaded a few times after that before the same behavior began again. This log is attached View attachment log_good_blink_then_bad_z80.txt.

[I cant seem to upload other attachments to this post, will post them after.]
there are two failures I experienced again. Intertestingly, flashing the serialecho sketch then flashing my own one seems to give me several attempts at automatic uploads before failing.

Something I was wondering about, is whether a sketch with long delay(n) calls can interfere with the bootloader launching? It's just a hunch but I seem to get more failed autoupload attempts when i'm running my debug code which has a long delay call in it. On the order of 500ms

this unit still cannot boot straight into a sketch. It needs to be manually rebooted from a PC, which is obviously an issue itself!
 
Still thinking about flashing the Teensy 3.1 with the JLink from Segger...

Can I solder a cable to PTA0 and PTA3 and connect them as follows:
PTA0 --> SWD_CLK (JLink)
PTA3 --> SWD_DIO (JLink)
GND --> GND (JLink)
VIN --> VCC (JLink)

Then I would use the .hex generated by Teensyduino and flash it.

Is this possible? Am I getting any advantage?
 
It might be possible. You might also need to connect the reset signal. This all assumes the MK20 chip is still alive.

Is the board hard-soldered in, so you can't replace it with another one?
 
Thanks for the quick replay Paul!
Yes the board is hard soldered and the PCB is self-made, so the vias are connected with thin wires... Id would take a lot of work to replace the Teensy and may damage the PCB.

Is it possible to damage the MK20 when something goes wrong while flashing? Is there an easy way of testing the MK20 is still alive?
Soldering the 3 wires to the MK20 chip is also pretty challenging and only done as last chance...
 
I connected the JLink without success. The MK20 chip is not recognised by the J Link Segger software.
It seams like the MK20 is dead too, or just the MK20...
I have the same behaviour like drjack pointed out:
Checked the reset test point (R)... 0.1v Button up, 0.1v Button down
This pin should measure ~3.2v Button up, 0v Button down
Maybe this is the sign for the MK20 being damaged.

This the second Teensy damaged in the process of flashing a new program. I'm a litte bit worried of using it in the next prototypes...
 
I realize you probably can't publicly share info about this prototype.

If you'd like to send me info privately, please email me directly, paul at pjrc dot com. I can try to help, and I'd really like to get to the bottom of what went wrong.
 
maybe just double clicking the reset button can solve your problem.

I ones had the problem, thinking my teensy's were dead (not recognized by my pc, not able to load new code, not able to start conveniently), and in fact, they just need to be waked up with a double click on the reset button ;)

maybe a professional project need a clean mcu without bootloader, icsp is good to load programs inside the memory.

teensy is cool for fast prototyping and easy coding, but ones your project reaches the commercial production scale, you should consider a raw MCU usage. ;)
 
Just so you know, double tapping the switch doesn't work.

Any other ideas? Surely this isn't expected behavior, and it seems a great many people have the same issue.
Edit: Here are the symptoms:

1) Sketches never start on their own. Must be flashed & rebooted from teensyloader to do anything.
2) Serial 90% of the time never works. Shows in device manager, can't connect to it.
3) Automatic teensy loader mode rarely works at all.
4) The Teensy will sometimes appear completely dead, until a tiny program like Blink is loaded, upon which point you can then attempt to load a real program (after several USB + button inserts, etc).

This is the second board to have the exact same behavior. The first one died after a few days of this, and it's now at the point where I need to load blink _every time_ to get the loader flashing anything of use.
 
Last edited:
Dear Paul

Just to say that today I also had problems with my Teensy 3.1!
The device is not longer recognized by the operating system (the problem started when I was programming it in Windows, but in Linux and in OS X I get the same behavior).
(Un)fortunately I found this thread that means that I am not the only one!
It was a wonderful little device when compared with the Arduino but it seems it lacks some robustness that I need for the classes I teach at my University.
If there is a magic solution, please let me know!

Regards,

Hélio Mendonça
https://sigarra.up.pt/feup/en/FUNC_GERAL.FORMVIEW?p_codigo=231072
 
Helio,

If supreme ruggedness is something you're after, I would use the Ruggeduino instead of the Teensy 3 series. The Ruggeduino was designed form the ground up to take all sorts of abuse without breaking it. I have no affiliation with its maker but was impressed by the lengthy discussion re: all the failure modes that they have considered and guarded against. Unfortunately, such guarding has some impact on device versatility and cost as well.

The biggest downside to the Ruggeduino is that it still uses the 328 Atmel processor. However, I suppose you could embark on designing a shield that the Teensy plugs into that provides the same level of protection as the inputs /outputs on the Ruggeduino. The schematics are available online.
 
I'm currently investigating a few different "stability" issues.

The simplest is the fact that the Mini54 bootloader doesn't properly handle some cases where the flash settings byte at 0x40C gets erased and reprogrammed. Normally, this can't happen with USB-based programming, because no matter what you try to write to 0x40C, the Mini54 bootloader ignores the incoming data and always programs that byte with a valid setting. But if you write code which erases that sector in the flash, all bets are off. The next bootloader version will be designed to recover from all cases, except of course a locked chip with erase permanently disabled. If you lock the chip and permanently disable erase, the MK20 becomes forever bricked. Nothing can ever recover from that condition (unless you code still running on the chip can erase and change 0x40C again), so I do not recommend messing with flash writing to the 0x400 sector!

The Mini54 & MK20 also aren't handling a logic low applied to pin 33. This problem is extremely tough. I've been working on a fix. So far, I've got all the normal cases covered. But when combined with code that erases the 0x40C byte, recovery in all cases with pin 33 becomes extremely difficult. I'm reluctant to release a bootloader upgrade until I've throughly tested it, so please understand this take some time.

Those are the known issues.... unknown issues are the really hard part.

For example, this:

4) The Teensy will sometimes appear completely dead, until a tiny program like Blink is loaded, upon which point you can then attempt to load a real program (after several USB + button inserts, etc).

I just don't understand what's happening here. If Teensy appears completely dead, how are you managing to load the LED blink program?

I looked at this verbose info log, and it's clear some sort of USB communication error is happening. The first 7 blocks are transferred into the Teensy. The "waiting for device" message is normal for the short periods, when the receive buffer on Teensy is full and it can't accept any more incoming data until it finishes writing blocks to the flash. But the write times are on the scale of a dozen milliseconds.

In that case, something is going very wrong with the Teensy. It's stops responding. Teensy Loader will show "write error" and give up. This is likely a hardware issue. It's possible your Teensy is damaged or defective. It's also possible it might be connected to other circuitry that's somehow causing problems, maybe power related? I just can't tell from only the info here. It's also possible Teensy is working perfectly, but something else between Teensy and Teensy Loader, like the USB cable, a USB hub, the USB host controller, or the USB host chip driver, or the Windows HID layer, is having some sort of trouble that's disrupting communication. All Teensy Loader can tell is it's not getting a response from the Teensy anymore.

I wish I could know what's wrong in this case, but it's indeed very mysterious. Hopefully this lengthy guesswork helps a bit?
 
Status
Not open for further replies.
Back
Top