teensy 3.1 died

Status
Not open for further replies.
New 3.1 died within minutes

Paul,

Thanks for your candid reply on the status of the boot loader. I just got my first teensy today and am sad it is already dead. I emailed you and have been reading the forums for any hints. In my case I had just started using it with teensyduino and had only loaded a few example sketches when my computer crashed (my Mac does that sometimes during arduino compiles). Bummed because I'm looking to design the 3.1 into a project where RAM and the octo driver are key

I hope you find those bugs that are causing these reliability issues. It's a great little board!
 
3.1 Teensy Issue

Which Mac model and which versions of OS-X was this?

Mac 2.8GHz Intel Core 2 Duo with 8GB RAM (17" model circa 2010)
OS 10.9.5
Arduino 1.05
Teensyduino 1.20

I tried the Teensy 3.1 on my Windows 7 machine today with no luck -- simply does not come up. I would send you a more detailed USB report but I do not know how to generate that.
 
i had exactlly the problem with teensy3.1, and the double click on reset button was really magic.

there is also the solution to launch the upload of blink to the teensy, it will fail, but then, you just have to close the teensy loader, unplug the teensy, replug the teensy, and relauch the upload.
i think you should try a lot of combinaison of "hardware" tricks, using only the computer user interface would not be enough. ;)
 
I have the similar behaviour. When powered by USB, Teensy(3.1) start processing last successfully uploaded sketch. This sketch changing onboard LED status(On and Off) every 500ms and playing 2 MIDI notes on every LED status change(Teensy is configured as USB_MIDI). I see blinking LED and I hear that sounds when connected to GarageBand(both on Mac and iPad). Also I can connect MFRC522 RFID reader to SPI and it will work too(last uploaded sketch includes this code).

But I cannot upload anything else, Teensy Loader don't recognize the board anymore("HID/macos: no devices found" in "Verbose Info" window).
Nothing happens on Prog button press(even doubleclick or hold or any other "button massage"), the LED still blinking(and notes still sending) without any visible reaction.
Shortening Reset pad to ground causes the sketch reset.
Sometimes(actually often, but not every time) the only noticeable reaction is sketch freezing on upload attempt(the LED stops blinking and remains in it's "catched" state - on or off).
It seems like the Loader attempting to change something in USB or trying to "pinging" Teensy on upload... and sketch freezing is the only reaction that MINI54 can doing.
 
Hi

... all sorts of abuse without breaking it.

Despite I wrote the word "robusteness" in my post, I assure you that this problem did not resulted from any abuse!
In fact, the problem occurred during a board programming attempt. One minute the board was recognized by Windows 8.1, a few seconds later the message "USB not recognized (Device Descriptor Request Failed)" started!

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.

In my case the problem is not outside the board since I get the same connection problem in other operating systems (OS X and Linux), with other cables, in other computers as well.

There is any way to reprogram the bootloader without using the USB port?

Regards

Hélio Mendonça
 
Hélio, I wasn't trying to suggest that you were abusing the Teensy, I was merely trying to suggest something more rugged, if that attribute was necessary. I wouldn't be surprised if a percentage of these boards (Teensy, Arduino, etc.) die every year just being handled in a non-static safe environment. The diodes built into them are limited in scope and capacity. Older 5V platforms also likely could handle more abuse than newer 3.3V or 1.8V platforms.

For example, some of my older Apple laptops could 'float' at 50V and your fingers would tingle if you touched them as a few mA would bleed off. Perfectly normal and this 'feature' would only go away if you used a grounded plug for the power supply. Consider the possibility that your CPU was floating at a higher than GND potential but that the Teensy was resting on a grounded surface. The resultant current flow could damage the Teensy.

Similarly, if the Teensy was handled by someone or in an environment where there is a significant static charge, components can get damaged (and I'm not suggesting you did). But FWIW, I am designing my boards to use TVS diodes on every external connection, including the SD card. Perhaps it's overkill but I don't know where these boards will be installed and a few cents of components is easily accommodated. I got this hint from the folk at SIMCOM, whose reference SIM900 design includes TVS' on all lines coming from the SIM card connector (which is externally accessible).
 
I'm currently investigating a few different "stability" issues.

...
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.

This seems promising. It's early, but I now have the program button reprogramming quite well - it's worked the past 10 times ive tried without needing to remove the USB cable, etc. My project uses pretty much _all_ i/o (http://labs.domipheus.com/blog/category/projects/teensyz80/) so I made pin33 a rarely-low output instead of input (it used to be the MREQ pin of the Z80, it's now INT).

I'll keep you posted, but thank you for the explaination! It still doesnt boot into a sketch, but i'll continue tinkering with that one - it does start the sketch if I manually reset the mk20 by pulling the reset pad low.

edit: After a manual reset after first plugging into the PC, I now no longer need to press the program button, auto upload is working!

Cheers,
Colin
 
Last edited:
Hardware tricks didn't work

i had exactlly the problem with teensy3.1, and the double click on reset button was really magic.

there is also the solution to launch the upload of blink to the teensy, it will fail, but then, you just have to close the teensy loader, unplug the teensy, replug the teensy, and relauch the upload.
i think you should try a lot of combinaison of "hardware" tricks, using only the computer user interface would not be enough. ;)

Yeah...tried all those. First place I came to was this forum and I did whatever I could to raise the Teensy3.1. Double, triple and backflips. Anything to get it to come back to life. Relaunches of the Arduino and TeensyLoader have no effect, nor does plugging it into a different computer, etc.
 
So, a few days later, we are still working well. From my list in a previous post of the things broken, we are simply left with:

* Sketches don't start on their own (but reset pad works, so this is of minimal disruption)
* Serial - a major issue. I can communicate every time with raw hid using the serial monitor/telnet but 'real' serial mode doesn't work. Shows up in device manager as COM4, but teensyduino has the com port menu greyed out and putty can't connect either. Same with the Serial + keyboard/joystick mode.

But, given the situation a few weeks ago, this is major progress :)

Colin
 
I seem to have found myself with a bricked teensy 3.1 too.. Im so annoyed too since it's soldered into a costly teensy 3 breakout board from tindie...

Started with having issues loading sketches where I had to time exactly when I pressed the reset button to get it to be recognised.. Slowed down my work flow like a bitch! And now it won't do anything... I did notice that if I removed a PIR sensor from pin 33 (which was holding pin 33 low) then it was a bit more reliable.. But after a normal reboot it just sits there with no led nothing.. I've pulled it out the breadboard and tried minimal / no inputs outputs and tried just loading basic sketch... Another trick is to apply power while you're holding the reset button down, then remove button after several seconds and that will sometimes reset it / un brick it but even that's not working.. I've got 4 other teensys here on my desk, all of which working fine and been using them since original KickStarter release so I would say I'm pretty good about knowing the difference between a brick and something that's fried... Or other noob issue (with all due respect lol)

I've checked the 3.3v and that all seems good.. Just something has happened during an unreliable load and now it is dead..

And what's even more annoying, is I had to buy YET ANOTHER teensy just to keep my project going, bought a whole new breakout board (which takes forever to solder up neatly) and THIS teensy is only stable at 120Mhz whereas the others run fine at 144Mhz (I'm running 3 x oled displays with animation so need max speed)..

Any suggestions would be super cool..

For the record, defo seems to not like having any I/O held low while programming, especially pin 33 :)

Thanks guys.

Andy
 
sometimes, this kind of MCU board can stop to respond due to the code.

For example, if your code uses a lot the serial communication, your routine is bypassing the usb serial communication of the bootstrap, then you cannot longer flash the device.
 
Andy, you do know that at 120MHz, you are operating at almost 2x the rated speed of the chip, right?

Paul has made no guarantees re chip stability at these speeds, AFAIK. For instance, the 96MHz speed option is clearly labeled in the IDE as a over clocked speed. If it's stability you're after, stay below 72MHz, that's what the chip is rated for.

Lastly, for projects where fast turnaround a must, a breakout board with pin headers is the way to go. Soldering up all the headers on the teensy is a pain but the benefit is being able to isolate the issue quickly. Or, have multiple breakout boards ready that you know to be good. All comes down to how much your time is worth.
 
I believe I may be in the same boat as several others here. After flashing new code several times with no issues via the Teensy loader, the board stopped auto rebooting. After pressing the reset button as requested by the software, the board no longer runs my code and I can no longer upload any changes. I still get 3.3v out and 0.1v across the reset pin and ground (not sure if that is helpful, but I did see it mentioned elsewhere here).
 
I just wanted to add my name to the list of people who've had a flaky programming experience. Fortunately, the trick of either double-clicking the programming button or holding it while connecting USB worked for me (I'm not quite sure which).

For background, my Teensy is soldered into a SmartMatrix shield that I bought pre-assembled from PixelMatix (http://docs.pixelmatix.com/SmartMatrix/). The Teensy has the VUSB trace cut and VIN is connected to the 5V power supply through a diode.

When I hit program on the Arduino UI, as I have done dozens of times before (including a couple of times tonight), it encountered a program error, and went completely unresponsive. The attached LED matrix wouldn't light up, Windows said I had connected a USB device that had malfunctioned, and the COM port no longer showed up. The only sign of life was that power LED on the RTC breakout board that was connected to the GND and 3V3 pins off the Teensyduino lit up. I tried disconnecting the power and USB, reconnecting it, reconnecting only the power without USB, hitting the program button multiple times, switching to a different USB port and nothing worked.

After futzing with the reprogram button several times, Windows no longer showed the "one of your USB devices has malfunctioned and is not recognized" error, but I still didn't see it show up as a COM port. However, I noticed that device manager was refreshing when it loaded so I dug around elsewhere and found it was showing up as an extra "HID-compliant device" under the "Human Interface Devices" tree, but Windows showed no apparent way to distinguish the 3 identically named devices.

I rebooted my computer into Linux and ran lsusb and was relieved to see that Teensyduino was listed as one of the devices. I installed Arduino and Teensyduino and successfully programmed the blink sketch and confirmed the light on the back of the Teensy was blinking. I'm not sure if booting into Linux was really necessary--maybe it would have worked if I had tried to program in Windows immediately after the Teensy showed up as a HID device.

At this point, I didn't really want to go through the trouble of installing all the dependencies for my sketch, so I booted back into Windows. The Teensy showed up again as a COM port, so I went into Arduino and re-flashed Aurora. Long story short, my LED matrix is now happily running the game of life again. :)
 
Last edited:
Have a similar story here,

Recieved my Teensy 3.1 yesterday, together with the audio board. Soldered them together and attached a sonar sensor (analog) and an accelerometer (software SPI) to the board. Once every 30 times i uploaded something to the board my macbook air (OS X 10.9.5) would hang completely. Is this a known bug? I figured it had to do with the USB drivers that mess up the kernel: annoying but the board seemed to work well doing all sorts of things at once: audio, sd-card reading/writing while reading sensors until the Teensy did not respond any more. Probably due to a faulty upload of firmware while my mac crashed (the teensy did not respond any more after my OS crashed). Similar issues as above: the USB device is not recognised any more by MAC OS X or Linux (lsusb and dmesg do not show anything). Doing the reset, double reset, reset while plugging in the usb port does not change anything. The voltage regulator does work (3.27V) the reset at the back measures 0.1V.

I have just removed the audio board from the Teensy in the hopes this would change anything but alas. The Teensy looks bricked.
 
Hi Paul,
This is my first tread. I have a brand teensy 3.1. It arrived to me last saturday so i'm new to it.
It happens to me just 1 hour ago.
While loading a sketch something went wrong (using win 7 pro). After that Teensy 3.1 seems to be dead. No response at all, program not running, no recognition as usb valid device. I have tried to change cable, reinstall usb drivers, reinstall teensyduino , try to change from win7 to ubuntu ecc but nothing! At last i found the Loader and the blink sketch. I launced the loader and tried to load the blink sketch. The serial port (12 for my teensy)was not recognized at the moment, but the the message of the compiler was that it was trying to write to my port 5 which is the one recognized for my arduino. I pressed the button to activate and the sketch was loaded, the led was blinking and windows reinstall the right port(12). After that now i'm able to run all my programs like before. (strange things happens sometimes!)
(sorry for my english)
By
Ezio
 
10.9.5 Kernel Panics

Have a similar story here,
Once every 30 times i uploaded something to the board my macbook air (OS X 10.9.5) would hang completely. Is this a known bug? I figured it had to do with the USB drivers that mess up the kerne

0110,
What version of IDE are you using (Arduino 1.x?) I will say that this is not a Teensy issue -- I've had Arduino's do this to me for a long time now. It seems that frequent restarts of the IDE help. It also looks like 1.5.8 kernel panics less frequently and/or an upgrade to Yosemite might be in order. Just a few thoughts.

_Red
 
Here is a dead 3.0

It was entirely my fault.

IMG_3910.JPG

After a week or so of humidification, I started to tuck away tubing and clean the install. Naturally, water flew everywhere. It appears that I shorted something sufficiently that the only use for this teensy now is as a USB-powered coffee cup warmer. I have a couple of spares, so I was back in business within an hour. It's a pity about the Teensy though!
 
Teensy 3.1 auto-load issues

Not a n00b, just new to Teensy, adding my experience after seeing auto-reboot issues and finding this thread:

Teensy 3.1 purchased 1/20/15, initial tests ran fine, loved the auto-boot feature.
Second day of use, one confusing programming attempt (not sure what happened) but from then on Teesy loader window popped up and I've had to press program button every time.
No need to mess with reset pad (yet). One time Teensy loader window stayed behind other windows so I didn't know it was ready and thought I had more issues. (PC only Windoze problem?)
I recall looking at the details of the session (Are logs saved somewhere that I can send them to Paul?) and noted that it seemed odd that it programmed so many blocks (8) when I had such a short (7%) program.

Win7 Pro SP!; Arduino 1.0.5; only connections to Teensy are those shown in OctoWS2811 library support page <http://www.pjrc.com/teensy/td_libs_OctoWS2811.html>. Separate power supply for LEDs strips running at 4.4V so I don't need buffer chips.

I also have 1.5.6 installed which I use for Adafruit & Pololu boards

2ndary issue:
With other 'duinos, pressing Verify just compiles (verifies) the code, no load is attempted.
With Teensy, [Verify] starts a load, I don't think it should, it should wait until I press [Upload]
I'm wondering if there are avrdude issues here since the problem seems to occur with other OS's

Hoping not to be bricked out before I complete project, let me know if I can further help in anyway with this loader issue.

BTW Paul, I love your OctoWS2811 library, it's why I bought your boards. Saved me from having to write one from scratch, though it has several compatibility issues with NeoPixel library to be addressed in another thread.
 
i maybe have a reason of the disfunction of the teensy 3
recentlly, i played a lot with the iron on a teensy 3.1, and when soldering/desoldering wires on pins 0 to 3, it occured a problem, the usb bootloader no longer works.

Maybe this component is too close to the pins, and is then very exposed to temperature and molten stain.

since this day, this teensy is no longer recognised or seen by the PC. i don't have anything to test the pins of the MINI54T AN, but i am pretty sure i've burned/short circuited something on this component.

maybe a teensy 3.2 would need a better gap between pins and components. in order to avoid this kind of problem.

i think the problem would not occur as easy on the teensyLC due to a longer distance with the usb loader.
 
Me being stupid

I wanna add my todays goal where i managed to burn and melt the chip plastic body and destroying teensy.

I am working on a CAN bus project where teensy will be connected in my Peugeot 508 car and just "listening" to CAN messages.

Based on those message i am comunicating via two HC05 modules with little ATTiny85 in my trunk.
This ATTiny reads the 12V to 15V in my car and if the engine is running, it powers up HC05 which as a master will connect to teensy's HC05 as a slave:)

So today i did not have 12V power supply so i wanted to use 5V instead and "teach" ATTiny85 the AD value of stopped engine and running engine.
Since it did not work due to AD value was in range of pressed button value, i did not succeed and i left it as it was and went to do something else leaving
the junction between 5V and 12V line.

Then i went to my car, plugged the DB9 CAN connector to my box and weird things started to happen on my car which was saying that there is comm error
between ECU and so on so i unplugged the box from my car. Put it back again and suddenly a pile of smoke went up from teensy :(

Nothing code related, but i felt i can share it with You

Attached you can see destroyed teensy, note the two melted parts, and my proto box with CAN-BUS analyzer from Microchip and other stuff :)

Have nice programming
Dusan
 

Attachments

  • IMG_7399.JPG
    IMG_7399.JPG
    86.3 KB · Views: 204
  • IMG_7402.JPG
    IMG_7402.JPG
    161.3 KB · Views: 192
Status
Not open for further replies.
Back
Top