Bricked Teensy LC with Blinky?

Status
Not open for further replies.
A

albertwc

New member
So I wanted to simply try reprogramming the Teensy LC with something I thought would work -- the example program blinky. I downloaded, unzipped it, and tried to run make, but ran into compilation issues:

Code: 
$ make

-------- begin --------
avr-gcc (GCC) 7.1.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Compiling C: blinky.c
avr-gcc -c -mmcu=atmega32u4         -I. -gdwarf-2 -DF_CPU=16000000UL -Os -funsigned-char -funsigned-bitfields -ffunction-sections -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=./blinky.lst  -std=gnu99 -MMD -MP -MF .dep/blinky.o.d blinky.c -o blinky.o

Compiling C: usb_debug_only.c
avr-gcc -c -mmcu=atmega32u4         -I. -gdwarf-2 -DF_CPU=16000000UL -Os -funsigned-char -funsigned-bitfields -ffunction-sections -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=./usb_debug_only.lst  -std=gnu99 -MMD -MP -MF .dep/usb_debug_only.o.d usb_debug_only.c -o usb_debug_only.o
usb_debug_only.c:96:24: error: variable 'device_descriptor' must be const in order to be put into read-only section by means of '__attribute__((progmem))'
 static uint8_t PROGMEM device_descriptor[] = {
                        ^~~~~~~~~~~~~~~~~
usb_debug_only.c:113:24: error: variable 'hid_report_descriptor' must be const in order to be put into read-only section by means of '__attribute__((progmem))'
 static uint8_t PROGMEM hid_report_descriptor[] = {
                        ^~~~~~~~~~~~~~~~~~~~~
usb_debug_only.c:128:24: error: variable 'config1_descriptor' must be const in order to be put into read-only section by means of '__attribute__((progmem))'
 static uint8_t PROGMEM config1_descriptor[CONFIG1_DESC_SIZE] = {
                        ^~~~~~~~~~~~~~~~~~
usb_debug_only.c:175:52: error: variable 'string0' must be const in order to be put into read-only section by means of '__attribute__((progmem))'
 static struct usb_string_descriptor_struct PROGMEM string0 = {
                                                    ^~~~~~~
usb_debug_only.c:180:52: error: variable 'string1' must be const in order to be put into read-only section by means of '__attribute__((progmem))'
 static struct usb_string_descriptor_struct PROGMEM string1 = {
                                                    ^~~~~~~
usb_debug_only.c:185:52: error: variable 'string2' must be const in order to be put into read-only section by means of '__attribute__((progmem))'
 static struct usb_string_descriptor_struct PROGMEM string2 = {
                                                    ^~~~~~~
usb_debug_only.c:198:11: error: variable 'descriptor_list' must be const in order to be put into read-only section by means of '__attribute__((progmem))'
 } PROGMEM descriptor_list[] = {
           ^~~~~~~~~~~~~~~
make: *** [Makefile:550: usb_debug_only.o] Error 1

I fixed the errors by making the aforementioned structs consts and recompiled. I then inserted the Teensy LC into the USB port, and saw the default blinking program run (LED on 1s, LED off 1s). I flashed the Teensy LC using the teensy_loader_cli command, and it stopped. From there, I could do nothing. I held the button down, and plugged the Teensy back into the usb port, and waited 15s. Nothing again. I tailed dmesg and journalctl while unplugging and plugging the Teensy back into the USB port, and nothing. I had another Teensy LC on hand, and tried that one out. Found the normal dmesg message:

Code: 
[  596.002966] usb 1-3: new full-speed USB device number 4 using xhci_hcd
[  596.135269] hid-generic 0003:16C0:0486.0005: hiddev0,hidraw4: USB HID v1.11 Device [Teensyduino Teensyduino RawHID] on usb-0000:00:14.0-3/input0
[  596.136037] hid-generic 0003:16C0:0486.0006: hidraw5: USB HID v1.11 Device [Teensyduino Teensyduino RawHID] on usb-0000:00:14.0-3/input1
[  622.571246] usb 1-3: USB disconnect, device number 4
[  623.040245] usb 1-3: new full-speed USB device number 5 using xhci_hcd
[  623.171677] hid-generic 0003:16C0:0478.0007: hidraw4: USB HID v1.11 Device [HID 16c0:0478] on usb-0000:00:14.0-3/input0
[  623.341697] usb 1-3: USB disconnect, device number 5

For some reason, I decided I'd reprogram that one with the same blinky.hex that caused an issue, except had the teensy_loader_cli output verbosely:

Code: 
$ teensy_loader_cli -mmcu=mkl26z64 -v -w blinky.hex
Teensy Loader, Command Line, Version 2.1
Read "blinky.hex": 1826 bytes, 2.9% usage
Waiting for Teensy device...
 (hint: press the reset button)
Found HalfKay Bootloader
Read "blinky.hex": 1826 bytes, 2.9% usage
Programming....
Booting

Same exact thing happened. I've, unfortunately, burned through both of the Teensy LCs.

The teensy_loader_cli program I used was made from the git repo: https://github.com/PaulStoffregen/teensy_loader_cli

I'm using avr-gcc 7.1.0:

Code: 
$ avr-gcc --version
avr-gcc (GCC) 7.1.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I'm using avr-libc 2.0.0, if that matters. Help would be appreciated, thanks!

----
Digging deeper it looks like the Makefile passes the atmega32u4 as the MCU (Teensy 2.0). Don't yet know the compatibility between the Teensy LC and the Teensy 2.0. From the code though, it looks like the only difference could be LED_ON and LED_OFF are swapped.
 
Last edited:
albertwc said:
So I wanted to simply try reprogramming the Teensy LC with something I thought would work -- the example program blinky. I downloaded, unzipped it, and tried to run make, but ran into compilation issues:

Code: 
avr-gcc (GCC) 7.1.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Compiling C: blinky.c
avr-gcc -c -mmcu=atmega32u4         -I. -gdwarf-2 -DF_CPU=16000000UL -Os -funsigned-char -funsigned-bitfields -ffunction-sections -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=./blinky.lst  -std=gnu99 -MMD -MP -MF .dep/blinky.o.d blinky.c -o blinky.o

I'm using avr-libc 2.0.0, if that matters. Help would be appreciated, thanks!

----
Digging deeper it looks like the Makefile passes the atmega32u4 as the MCU (Teensy 2.0). Don't yet know the compatibility between the Teensy LC and the Teensy 2.0. From the code though, it looks like the only difference could be LED_ON and LED_OFF are swapped.
Click to expand...


Teensy LC is NOT an atmega32u4
change your makefile accordingly
 
Yes;
as a beginner, you *really* should use Teensyduino - not makefiles.
And the CPU is ARM, not ATMEL.
 
I tried Paul's steps, and the loader just kept waiting for the device to present itself. Neither dmesg, udevadm, or journalctl had any relevant output related to a USB device being plugged in.
 
albertwc said:
I tried Paul's steps, and the loader just kept waiting for the device to present itself. Neither dmesg, udevadm, or journalctl had any relevant output related to a USB device being plugged in.
Click to expand...

did you press the upload button? (must be done the first time you use a teensy)
on Linux do you have 'udev??' installed? (I'm using windows)
do you use a data usb cable and not a charge-only one?
 
To add a missing piece here, the second IC on a Teensy 3.x/LC is a CPU that holds the bootloader code. If you press the program button you are telling that CPU to reset the main CPU (the only one running your code) and load the bootloader into RAM. If that bootloader can reach the Teensy loader via USB then it will get the ordered hex file, wipe the old flash contents and load it in. So pressing the button should get a USB device showing up at least briefly on the PC

So that not working suggests either the USB cable/plugs are damaged/charge only, your PC USB process has taken a dislike to the device (Assuming it got reset somewhere in this?) or the LC itself didn't work (unlikely to start with, very much so for two of them). If your code is doing something really strange to USB you may need tounplug the LC cold start your PC, start Teensyduino, hold the button in, plug in and release (preventing your code from ever running).

To brick a Teensy by code you need to have set one of the flash bits that puts them into write protect. Teensy loader prevents those locations being hit, but if you bypassed those protections then it is possible you managed to hit that space.
 
WMXZ said:
did you press the upload button? (must be done the first time you use a teensy)
Click to expand...
Yes. I pressed the upload button, and it just waited. I pressed the button and waited a few seconds. I unplugged, held the button down, and plugged it back in.

WMXZ said:
on Linux do you have 'udev??' installed? (I'm using windows)
Click to expand...
Yes. Udev on newer Linux systems is required to be up and running for the init system to work (systemd).

WMXZ said:
do you use a data usb cable and not a charge-only one?
Click to expand...
Yes. It's the same USB cable I used to reprogram the Teensy LC.

GremlinWrangler said:
To add a missing piece here, the second IC on a Teensy 3.x/LC is a CPU that holds the bootloader code. If you press the program button you are telling that CPU to reset the main CPU (the only one running your code) and load the bootloader into RAM. If that bootloader can reach the Teensy loader via USB then it will get the ordered hex file, wipe the old flash contents and load it in. So pressing the button should get a USB device showing up at least briefly on the PC

So that not working suggests either the USB cable/plugs are damaged/charge only, your PC USB process has taken a dislike to the device (Assuming it got reset somewhere in this?) or the LC itself didn't work (unlikely to start with, very much so for two of them). If your code is doing something really strange to USB you may need tounplug the LC cold start your PC, start Teensyduino, hold the button in, plug in and release (preventing your code from ever running).

To brick a Teensy by code you need to have set one of the flash bits that puts them into write protect. Teensy loader prevents those locations being hit, but if you bypassed those protections then it is possible you managed to hit that space.
Click to expand...

The USB cable/plugs and PC are not the issue. Could still use the cable/plugs/PC to reprogram/brick the other Teensy.
 
Status
Not open for further replies.
Back
Top