The Teensy 3.1 I have been using decided to quit working. It is no longer recognized by Windows as a USB device. I have 5V and 3.3V on the board. This is a Teensy purchased from Osh Park. They told me to contact you for support of the Teensy 3.1. I have been using CodeWarrior 10.6 and the Teensy loader. Everything was fine until it all went south. I was working on code to make a PWM output on FlexTimer1. I have two other versions of code that use FlexTimer1 for PWM without any issues. I do not believe the issue is code related. The only thing attached to the teensy at the time was a pushbutton switch and a Saleae logic analyser. How do I get the board repaired or replaced under warranty ?
Dead Teensy 3.1
- Thread starter BigJ
- Start date
- Status
Constantin
Well-known member
I would try using the Teensyloader and Arduino to upload the basic blink program after using the PGM button. Once blink works, the usual upload sequence will work also.
What you've discovered is how the boot loader cannot auto-recover from a bricked chip. You need to re-enable the MK20 for uploading via uploading a known good program first (otherwise, USB is blocked). Blink is handy because blink gives a visual clue whether the MK20 is happy again.
What you've discovered is how the boot loader cannot auto-recover from a bricked chip. You need to re-enable the MK20 for uploading via uploading a known good program first (otherwise, USB is blocked). Blink is handy because blink gives a visual clue whether the MK20 is happy again.
Teensy 3.1 is still dead
Perhaps I was not clear. Windows does not see the Teensy 3.1 board when plugged in. It does not matter if the reset button is held when the USB is attached or pressed after. Still dead. Having the Teensy Loader running when plugging in the board...still dead. How does one go about putting blink code into a dead board ? When you say Arduino I assume that you are referencing the Arduino IDE that is for AVR devices. Teensy 3.1 is based on a Freescale device. I use Freescale's Codewarrior for development. It is based on Eclipse and uses GCC for ARM micros or Freescale's proprietary 'C' compiler. I use the GCC option to avoid code limits.
Perhaps I was not clear. Windows does not see the Teensy 3.1 board when plugged in. It does not matter if the reset button is held when the USB is attached or pressed after. Still dead. Having the Teensy Loader running when plugging in the board...still dead. How does one go about putting blink code into a dead board ? When you say Arduino I assume that you are referencing the Arduino IDE that is for AVR devices. Teensy 3.1 is based on a Freescale device. I use Freescale's Codewarrior for development. It is based on Eclipse and uses GCC for ARM micros or Freescale's proprietary 'C' compiler. I use the GCC option to avoid code limits.
compile the blink code using the Arduino IDE with the target MCU being Teensy 3.1 (or as you have).
push the button on the Teensy to cause the Teensy loader to send the .hex. Teensy loader will use that .hex to download/flash via special mechanisms over USB.
The Teensy normally does not show up in the serial port list if that's what you are looking for - unless the already-flashed program is (a) running correctly and (b) does open the USB virtual serial using 'serial.begin(x)'
An arduino normally has an ever-present hardware-based serial port so it shows up when plugged into USB. Not so Teensy - the Teensy loader uses a special USB transport other than USB virtual serial.
Using the freescale code warrior compiler IDE tool puts you in a tiny minority becuase the Teensy is all about Arduino compatibility despite being an ARM. The usual Arduino IDE includes a choice of various Teensy boards.
I suggest not using Code Warrior - it's end of life, is crappy, and is counter to the premise of Teensy 3.
Other IDEs with Teensy compatibility, and FREE, include Visual Micro with MS Visual Studio (if you can run Windows). This gives you a real IDE for Teensy development, if you wish. But start with the Arduino IDE to learn.
push the button on the Teensy to cause the Teensy loader to send the .hex. Teensy loader will use that .hex to download/flash via special mechanisms over USB.
The Teensy normally does not show up in the serial port list if that's what you are looking for - unless the already-flashed program is (a) running correctly and (b) does open the USB virtual serial using 'serial.begin(x)'
An arduino normally has an ever-present hardware-based serial port so it shows up when plugged into USB. Not so Teensy - the Teensy loader uses a special USB transport other than USB virtual serial.
Using the freescale code warrior compiler IDE tool puts you in a tiny minority becuase the Teensy is all about Arduino compatibility despite being an ARM. The usual Arduino IDE includes a choice of various Teensy boards.
I suggest not using Code Warrior - it's end of life, is crappy, and is counter to the premise of Teensy 3.
Other IDEs with Teensy compatibility, and FREE, include Visual Micro with MS Visual Studio (if you can run Windows). This gives you a real IDE for Teensy development, if you wish. But start with the Arduino IDE to learn.
Last edited:
defragster
Senior Member+
I fought something like this for an hour once. Turned out the cable I had been using was no longer working. I swapped the cable and all was well.
Pushing the button and releasing still needs a good/functioning cable to have Windows connect to the device for the loader as HID .vs. USB - when my cable stopped acting right - this stopped too. [cable was not visibly or knowingly abused or old]
Have you tried other Teensy units on the same cable since this Teensy stopped working? Even so - the device may be more sensitive to whatever it is that happens to cables - or because of the state it is in. I was using an ATtiny with bitbanged USB support and it was super sensitive to cables - the Teensy seemed robust and I thought I'd never see this again.
Pushing the button and releasing still needs a good/functioning cable to have Windows connect to the device for the loader as HID .vs. USB - when my cable stopped acting right - this stopped too. [cable was not visibly or knowingly abused or old]
Have you tried other Teensy units on the same cable since this Teensy stopped working? Even so - the device may be more sensitive to whatever it is that happens to cables - or because of the state it is in. I was using an ATtiny with bitbanged USB support and it was super sensitive to cables - the Teensy seemed robust and I thought I'd never see this again.
Constantin
Well-known member
The MK20 is what is attached to the USB bus, not the boot loader chip. If you manage to brick the MK20 because of an overflow or similar memory issue then it becomes unresponsive. What the PGM button does is reset the MK20 via the bootloader and theoretically make it ready to receive a new program. However, it may not enumerate happily, which is where the Teensy loader program comes into play (which is part of the Teensyduino installer package for the Arduino IDE or EmbedXCode or VisualMicro, etc.).
I have found that installing the Arduino IDE and the Teensyduino package on top of that offers a good way to reset the chip by installing the blink program. The visual cue it provides is proof that the Teensy is once again receptive for a new upload.
The Arduino IDE has supported SAM and other ARM devices for years now. Teensyduino (offered for free by Paul here) adds Teensy support to the Arduino IDE. By installing both, you can code to your hearts content using the Arduino IDE on the three Freescale chips that Paul ships. Not sure about Edison, Samsungs gear, etc. but many non-AVR hardware platforms are also coming to the Arduino IDE.
Next time, it might be more helpful to follow the advice that people give you to help you with solving the exact problem you're describing rather than to argue that they're wrong before even trying!
defragster
Senior Member+
Also - as suggested installing the TeensyDuino program installs the drivers needed for Windows to recognize the device. If they are not installed - even with a good cable - Windows won't be able to talk to and acknowledge the device. So if you haven't followed Constantin's advice - that would probably help - then read the postings and follow up as needed - with updated details - if you are still stuck.
Still dead
First off, I am not here to argue the relative merits of one development environment over another.
I have downloaded and installed the Teensy extensions to the Arduino IDE. I compiled the Blink example. I attempted to use the Arduino IDE and the Teensy Loader to download the blink program. Guess what...the board is still dead. As I have said and nobody seems to be paying attention, the dead Teensy board does not register under Windows as a USB device of any kind. A working Teensy will register as an HID device. The Teensy loader uses the HID interface to download the code. If the board does not register as an HID device the downloader will not function.
Back to my original question, how do I get warranty service on a dead board, assuming that there is a warranty.
First off, I am not here to argue the relative merits of one development environment over another.
I have downloaded and installed the Teensy extensions to the Arduino IDE. I compiled the Blink example. I attempted to use the Arduino IDE and the Teensy Loader to download the blink program. Guess what...the board is still dead. As I have said and nobody seems to be paying attention, the dead Teensy board does not register under Windows as a USB device of any kind. A working Teensy will register as an HID device. The Teensy loader uses the HID interface to download the code. If the board does not register as an HID device the downloader will not function.
Back to my original question, how do I get warranty service on a dead board, assuming that there is a warranty.
PaulStoffregen
Well-known member
Your Teensy may indeed be dead. But before we jump to that conclusion, could you at least confirm a couple quick checks?
As a very first step, please disconnect everything from the Teensy, except the USB cable. Remove the logic analyzer too. Even though it should be fine, the point is to eliminate any possible interference. Plenty of "dead" Teensy boards have magically come back to life when seemingly harmless things (like extra capacitors across the power lines) were removed. Please do not make any assumption that anything connected to your Teensy, no matter how unlikely it might seem, isn't affecting it.
If you haven't already done so, please cold reboot your computer, especially if you're using Windows! A complete power off should be done, because many modern computers keep the USB stuff powered up even when the computer is "off".
If you're using Windows, please plug the Teensy into a different USB port. This isn't necessary with Linux or Mac, but Windows stores per-port USB stuff in its registry (a very poor design on Microsoft's part). I know this may sound strange or unnecessary, but believe me, it has made a difference sometimes if Windows got messed up. It's very quick and easy to do.
Obviously you're still using a USB cable that was previously working, so swapping the cable shouldn't be needed. Bad cables, especially ones for phone charging that don't have the data wires, are the most common cause of this sort of problem.
You've already seen the advice about holding the button while plugging the cable in, right? Please be aware Teensy may not appear as any device to your PC while running bad code. But it should always appear as a HID device after pressing the button, especially if you held the button down while plugging in the cable.
If these simple tests fail, let's assume the Teensy is bad. Robin will follow up with you regarding return and replacement.
As a very first step, please disconnect everything from the Teensy, except the USB cable. Remove the logic analyzer too. Even though it should be fine, the point is to eliminate any possible interference. Plenty of "dead" Teensy boards have magically come back to life when seemingly harmless things (like extra capacitors across the power lines) were removed. Please do not make any assumption that anything connected to your Teensy, no matter how unlikely it might seem, isn't affecting it.
If you haven't already done so, please cold reboot your computer, especially if you're using Windows! A complete power off should be done, because many modern computers keep the USB stuff powered up even when the computer is "off".
If you're using Windows, please plug the Teensy into a different USB port. This isn't necessary with Linux or Mac, but Windows stores per-port USB stuff in its registry (a very poor design on Microsoft's part). I know this may sound strange or unnecessary, but believe me, it has made a difference sometimes if Windows got messed up. It's very quick and easy to do.
Obviously you're still using a USB cable that was previously working, so swapping the cable shouldn't be needed. Bad cables, especially ones for phone charging that don't have the data wires, are the most common cause of this sort of problem.
You've already seen the advice about holding the button while plugging the cable in, right? Please be aware Teensy may not appear as any device to your PC while running bad code. But it should always appear as a HID device after pressing the button, especially if you held the button down while plugging in the cable.
If these simple tests fail, let's assume the Teensy is bad. Robin will follow up with you regarding return and replacement.
defragster
Senior Member+
Also - when doing the above per Paul - be sure to be patient 10-20 secs or longer for Windows to find and associate the right driver with the NEW USB device it found on another port. If you see the 'Device Driver' installer active by the clock - it is working and needs to complete before any unplugging or power cycling to have the HID driver made ready. I did that with a brand new OSH BOARD like yours just last week. I assumed it would be INSTANT connect, and I interrupted the driver install and it seemed dead. When I saw the installer trying and moved USB and waited and all was well getting to my working PURPLE board! Hopefully you will see the same.
Also - I did/do not see where you said you tried TeensyLoader - only the implication that you had not as you use another environment. I can only help you from the context of what I've tried - and based on my observations. You may indeed have a different issue - but from what you describe I have seen similar behavior twice in different ways that I was offering feedback on.
Also - I did/do not see where you said you tried TeensyLoader - only the implication that you had not as you use another environment. I can only help you from the context of what I've tried - and based on my observations. You may indeed have a different issue - but from what you describe I have seen similar behavior twice in different ways that I was offering feedback on.
I have tried everything that has been suggested. The Teensy is still dead. I held the reset button while attaching the USB cable. I held it down for several minutes to no avail. Still dead. First thing I did was remove everything attached to the Teensy board and try it alone. This is not my first rodeo. I have been developing embedded systems with various processors since the mid 1970s.
This is a question for Paul S. I see from the schematic that the Mini54 is connected to the MK20's JTAG and I2C0 pins. Is there a way to get the Mini54 to erase the program Flash in the MK20 and leave the bootloader Flash intact ?
I have an ST-Link V2 JTAG puck. If I connected it to the MK20's JTAG/SWD pins would the Mini54 interfere with using the MK20's JTAg or SWD interface ?
I also have several Freescale and TI development boards that can act as JTAG/SWD devices. Has anything like this been tried ? Any successes ?
I have an ST-Link V2 JTAG puck. If I connected it to the MK20's JTAG/SWD pins would the Mini54 interfere with using the MK20's JTAg or SWD interface ?
I also have several Freescale and TI development boards that can act as JTAG/SWD devices. Has anything like this been tried ? Any successes ?
PaulStoffregen
Well-known member
No part of the bootloader is stored in the MK20 flash. The whole point of the Mini54 chip is to allow your program to have 100% of the flash memory in the MK20 chip.
Ordinarily, yes, the Mini54 controls those pins and would conflict.
But on failed hardware, who could say what will happen? I believe we're working under the assumption your hardware has physically failed and needs to be replaced.
I am just trying to understand how the system as a whole works. Are the I2C pins connected to the Mini54 used to control the JTAG pins of the MK20 ? In other words is there an I2C protocol for the Mini54 to get it to act as a JTAG device ? If so, is it possible to get the protocol ?
@BigJ. There is a post here by someone who got an SWD pod connected to the T3. Essentially, he had to cut the traces for SWD data/clock to the Mini54.
I decided that for my own SWD-oriented (hardware debugger w/breakpoints) development (not using Teensyduino), on Freescale and others, it makes more sense to use other boards. Teensy isn't intended for other than Arduinoesque uses.
For SWD on M0/M4, there are 3 or so with similar board layouts/sizes, at similar prices.
I decided that for my own SWD-oriented (hardware debugger w/breakpoints) development (not using Teensyduino), on Freescale and others, it makes more sense to use other boards. Teensy isn't intended for other than Arduinoesque uses.
For SWD on M0/M4, there are 3 or so with similar board layouts/sizes, at similar prices.
Stevech,
Thanks for the info about the SWD interface. I will rule that out for now. I have other development platforms from TI and Freescale. I have two of the Freedom boards with the KL25Z and 2 TI Launchpads with Cortex M4 TM4C123GH6. Each of those has an integrated JTAG using USB. I have other boards as well, A bunch of older Stallaris boards, Freescale Kwickstick & Tower, Cypress 4200 boards, MSP430 and some Arduino 328P boards. I like the Teensy for the size and the Arm CPU. Cypress 4200 are interesting due to the price ($4.00) and onboard FGA capabilities, but are God awful slow for an Arm M0 core.
Thanks for the info about the SWD interface. I will rule that out for now. I have other development platforms from TI and Freescale. I have two of the Freedom boards with the KL25Z and 2 TI Launchpads with Cortex M4 TM4C123GH6. Each of those has an integrated JTAG using USB. I have other boards as well, A bunch of older Stallaris boards, Freescale Kwickstick & Tower, Cypress 4200 boards, MSP430 and some Arduino 328P boards. I like the Teensy for the size and the Arm CPU. Cypress 4200 are interesting due to the price ($4.00) and onboard FGA capabilities, but are God awful slow for an Arm M0 core.
BigJ, i have exactly the same problem - teensy 3.1 was working fine, uploaded sketches a few times, then it died. I have about 5 teensys and not had any problems like this where there is no life at all, even connecting to another computer. I have tested the usb cable as well.
Not sure if this has any bearing, but I was also working on PWM output! I had a pwm output connected to pin 4.
I have used pwm alot before and have it output on a number of pins.
Not sure if this has any bearing, but I was also working on PWM output! I had a pwm output connected to pin 4.
I have used pwm alot before and have it output on a number of pins.
- Status