Teensy 4.1 dying

Status
Not open for further replies.
D

David_B

Active member
Hi there,

I'm trying out migrating a project to Teensy 4.1. I'm using it to drive pixels in conjunction with an Octo board. I'm not using the Octo library, just using the board as a convenient interface for the pixel strip. I'm additionally using pins 23, 18 and 13 to control indicator LEDs although right at the moment, only 13 is active and using the on board LED.

This works great on Teensy 3.2 and 4.0.

However I keep loosing 4.1s. It seems that outputs keep stopping and a bank will stop working while the others operate OK. I've swapped datafeeds etc. to verify that I'm not missing something obvious and I'm happy that it's not a wiring fault.

This morning, I powered up a board that was working last night to find that it's completely dead having not touched or moved it overnight. The red indicator sometimes flashes when its powered but nothing else. I can't see it when I connect over USB to my PC.

Is anyone able to point me in a direction to troubleshoot this?

Thanks in advance for any help.

David
 
If a T_4.0 works then T_4.1 using only prior pins should work.

With RED led flash - should only happen with Program Button push, or GND on PGM pin {2nd in from pin #38} - it seems like the PGM pin is getting shorted - is there any possible connection on any of those pins beyond where shorter Teensy's stopped? In that row moved out half an inch as the T_4.1 grew?
 
Thanks for your really quick reply.

If a T_4.0 works then T_4.1 using only prior pins should work.
Click to expand...

I'd thought the same.

With RED led flash - should only happen with Program Button push, or GND on PGM pin {2nd in from pin #38} - it seems like the PGM pin is getting shorted - is there any possible connection on any of those pins beyond where shorter Teensy's stopped? In that row moved out half an inch as the T_4.1 grew?
Click to expand...

I don't think so. The board is mounted on long pins and that section hangs out over the RJ45 sockets on the Octo board.

When reporting over USB this comes up as:


===>Device Descriptor<===
bLength: 0x12
bDescriptorType: 0x01
bcdUSB: 0x0200
bDeviceClass: 0x00 -> This is an Interface Class Defined Device
bDeviceSubClass: 0x00
bDeviceProtocol: 0x00
bMaxPacketSize0: 0x40 = (64) Bytes
idVendor: 0x1FC9 = NXP Semiconductors
idProduct: 0x0135
bcdDevice: 0x0101
iManufacturer: 0x01
English (United States) "NXP SemiConductors Inc "
iProduct: 0x02
English (United States) "SE Blank RT Family "
iSerialNumber: 0x00
bNumConfigurations: 0x01

Whereas a board that works is:

===>Device Descriptor<===
bLength: 0x12
bDescriptorType: 0x01
bcdUSB: 0x0200
bDeviceClass: 0x02 -> This is a Communication Device
bDeviceSubClass: 0x00
bDeviceProtocol: 0x00
bMaxPacketSize0: 0x40 = (64) Bytes
idVendor: 0x16C0 = Van Ooijen Technische Informatica
idProduct: 0x0483
bcdDevice: 0x0280
iManufacturer: 0x01
English (United States) "Teensyduino"
iProduct: 0x02
English (United States) "USB Serial"
iSerialNumber: 0x03
English (United States) "7660190"
bNumConfigurations: 0x01

Had this just been one board, I would have put it down to something silly or carelessness my end, but I've got three with faults now while the 3.2s and 4.0s carry on happily which is why I'm wondering whether there's somewhere else I need to look...
 
Any chance you could share the code, so I can try to reproduce the problem here on a Teensy 4.1?

Does holding the button give you the quick flash on the red LED after ~15 seconds? Does releasing the button then do the full erase and restore to a known-good LED blink with USB as RawHID?
 
Hi Paul,

Thanks for taking the time to reply and look into this.

Holding the power button has revived two of the boards which seemed completely dead. One board doesn't. This doesn't register as any type of USB device on my PC whereas the others did. I'm powering through the USB port and am getting 5v and 3v3 on the pins so the regulators appear to be running OK.

It doesn't seem to have revived the outputs that aren't working which are 2 & 7 in case this sheds any light.

At the moment I'm running 10 sets of pixels on different boards. 1 on 4.1, 3 on 4.0 and 6 on 3.2. I've had no issues with the tests on 4.0 and 3.2.

Out of 4 4.1s I've seen the error on 3 of them (one unrevivable, 2 with missing outputs). Perfectly prepared to accept that I've done something silly and initially assumed that might be the case although it seems odd that the issue seems limited to the 4.1s.

Very happy to share code but rather not post publicly. Can I email it to you?

Cheers
David
 
My teensy 4.1 just died too.... with the message from linux kernel similar to the opening post:

kern :info : [ +0.230286] usb 1-2.1: new high-speed USB device number 58 using xhci_hcd
kern :info : [ +0.100776] usb 1-2.1: New USB device found, idVendor=1fc9, idProduct=0135, bcdDevice= 1.01
kern :info : [ +0.000013] usb 1-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
kern :info : [ +0.000006] usb 1-2.1: Product: SE Blank RT Family
kern :info : [ +0.000005] usb 1-2.1: Manufacturer: NXP SemiConductors Inc
kern :info : [ +0.003383] hid-generic 0003:1FC9:0135.0085: hiddev2,hidraw5: USB HID v1.00 Device [NXP SemiConductors Inc SE Blank RT Family ] on usb-0000:00:14.0-2.1/input0
Click to expand...

pressing the button for 15-17 sec will give a short flash of red LED, but didn't revive the teensy with the blink sketch. :(

It happened after I tried to solder PSRAM onto the board, so may be I messed up somehow.
 
I should add that a night before this happened, I made a mistake and connect +Vbat of my coin battery to On/Off pin instead of VBAT pin.

and FWIW, here is the "Verbose Information from Teensy Loader"
21:28:29.416 (ports 5): add device: subsys=usb, type=usb_device, location=/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.1
21:28:29.416 (ports 5): devnode=/dev/bus/usb/001/057, subsystem=usb, ifacenum=-1
21:28:29.416 (ports 5): usb_add: /dev/bus/usb/001/057 (Teensy) Bootloader
21:28:29.418 (ports 5): add child: subsys=usb, type=usb_interface, location=/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.1/1-2.1:1.0
21:28:29.418 (ports 5): parent location=/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.1
21:28:29.418 (ports 5): usb_add: /dev/bus/usb/001/057 (Teensy) Bootloader
21:28:29.419 (ports 5): add child: subsys=hid, type=(null), location=/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.1/1-2.1:1.0/0003:16C0:0478.0084
21:28:29.419 (ports 5): parent location=/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.1
21:28:29.419 (ports 5): model=37 (Teensy 4.1)
21:28:29.419 (ports 5): usb_add: /dev/bus/usb/001/057 (Teensy 4.1) Bootloader
21:28:29.423 (ports 5): add child: subsys=hidraw, type=(null), location=/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.1/1-2.1:1.0/0003:16C0:0478.0084/hidraw/hidraw5
21:28:29.423 (ports 5): parent location=/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.1
21:28:29.423 (ports 5): usb_add: /dev/bus/usb/001/057 (Teensy 4.1) Bootloader
21:28:29.423 (ports 5): unknown action: bind
21:28:29.424 (ports 5): unknown action: bind
21:28:29.427 (ports 5): unknown action: bind
21:28:29.646 (loader): Device came online, code_size = 8126464
21:28:29.646 (loader): Board is: Teensy 4.1 (IMXRT1062), version 1.05
21:28:29.649 (ports 5): del child: location=/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.1/1-2.1:1.0/0003:16C0:0478.0084/hidraw/hidraw5
21:28:29.653 (ports 5): unknown action: unbind
21:28:29.656 (ports 5): del child: location=/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.1/1-2.1:1.0/0003:16C0:0478.0084
21:28:29.658 (ports 5): unknown action: unbind
21:28:29.671 (loader): File "Blink.ino.hex". 11236 bytes, 0% used
21:28:29.672 (loader): set background IMG_ONLINE
21:28:29.684 (loader): File "Blink.ino.hex". 11236 bytes, 0% used
21:28:29.684 (loader): elf file is for Unknown Board
21:28:29.684 (loader): begin operation
21:28:29.714 (loader): flash, block=8, bs=1024, auto=1
21:28:29.714 (loader): gauge old value = 0
21:28:29.715 (loader): flash, block=9, bs=1024, auto=1
21:28:29.901 (loader): gauge old value = 1
21:28:29.910 (loader): flash, block=10, bs=1024, auto=1
21:28:29.910 (loader): gauge old value = 2
21:28:29.911 (loader): flash, block=11, bs=1024, auto=1
21:28:29.911 (loader): gauge old value = 3
21:28:29.912 (loader): flash, block=12, bs=1024, auto=1
21:28:29.913 (loader): gauge old value = 4
21:28:29.914 (loader): flash, block=13, bs=1024, auto=1
21:28:29.915 (loader): gauge old value = 5
21:28:29.915 (loader): flash, block=14, bs=1024, auto=1
21:28:29.916 (loader): gauge old value = 6
21:28:29.917 (loader): flash, block=15, bs=1024, auto=1
21:28:29.918 (loader): gauge old value = 7
21:28:29.918 (loader): flash, block=16, bs=1024, auto=1
21:28:29.919 (loader): gauge old value = 8
21:28:29.920 (loader): flash, block=17, bs=1024, auto=1
21:28:29.921 (loader): gauge old value = 9
21:28:29.921 (loader): flash, block=18, bs=1024, auto=1
21:28:29.923 (loader): gauge old value = 10
21:28:29.932 (loader): sending reboot
21:28:29.932 (loader): begin wait_until_offline
21:28:30.113 (ports 5): unknown action: unbind
21:28:30.116 (ports 5): del child: location=/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.1/1-2.1:1.0
21:28:30.120 (ports 5): unknown action: unbind
21:28:30.123 (ports 5): del device: location=/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.1
21:28:30.133 (loader): HID/linux: something changed, try reading a descriptor
21:28:30.133 (loader): HID/linux: Device was just disconnected
21:28:30.133 (loader): offline, waited 4
21:28:30.134 (loader): end operation, total time = 0.449 seconds
21:28:30.134 (loader): set background IMG_REBOOT_OK
21:28:30.138 (loader): redraw timer set, image 14 to show for 1200 ms
21:28:30.482 (ports 5): unknown action: bind
21:28:30.483 (ports 5): unknown action: bind
21:28:30.489 (ports 5): unknown action: bind
21:28:30.991 (ports 5): purge, name=/dev/bus/usb/001/057 (Teensy 4.1) Bootloader, loc=/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.1, age=0.868
21:28:31.339 (loader): redraw, image 9
21:42:18.805 (ports 5): unknown action: unbind
21:42:18.806 (ports 5): unknown action: unbind
21:42:18.807 (ports 5): unknown action: unbind
Click to expand...
 
boat said:
I should add that a night before this happened, I made a mistake and connect +Vbat of my coin battery to On/Off pin instead of VBAT pin.

and FWIW, here is the "Verbose Information from Teensy Loader"
Click to expand...

21:28:29.646 (loader): Board is: Teensy 4.1 (IMXRT1062), version 1.05
21:28:29.649 (ports 5): del child: location=/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.1/1-2.1:1.0/0003:16C0:0478.0084/hidraw/hidraw5
21:28:29.653 (ports 5): unknown action: unbind
21:28:29.656 (ports 5): del child: location=/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.1/1-2.1:1.0/0003:16C0:0478.0084
21:28:29.658 (ports 5): unknown action: unbind
21:28:29.671 (loader): File "Blink.ino.hex". 11236 bytes, 0% used
21:28:29.672 (loader): set background IMG_ONLINE
21:28:29.684 (loader): File "Blink.ino.hex". 11236 bytes, 0% used
21:28:29.684 (loader): elf file is for Unknown Board
Click to expand...

The board is recognized correctly, i.e. the Teensy works. It's alive.
But "elf for unnown board" looks quite suspicious.
Where did you get the file you are uploading?

My log looks like this:
17:10:58.680 (loader): Board is: Teensy 4.1 (IMXRT1062), version 1.05
17:10:58.700 (loader): File "Blink.ino.hex". 20480 bytes, 0% used
17:10:58.705 (loader): set background IMG_ONLINE
17:10:58.730 (loader): File "Blink.ino.hex". 20480 bytes, 0% used
17:10:58.735 (loader): elf appears to be for Teensy 4.1 (IMXRT1062) (8126464 bytes)
17:10:58.735 (loader): elf binary data matches hex file
17:10:58.740 (loader): elf file is for Teensy 4.1 (IMXRT1062)
17:10:58.745 (loader): begin operation
17:10:58.765 (loader): remote cmd from 1580: "status"
Click to expand...

I think you are trying to flash a wrong file.... for a different CPU.
Use examples - > basic -> blink
Before, select your Teensy model...
 
boat said:
...
pressing the button for 15-17 sec will give a short flash of red LED, but didn't revive the teensy with the blink sketch. :(
...
Click to expand...

Was the Button released when that 'short flash' was seen? If not released after the flash and held beyond the ~17 second point before release, the Restore is aborted.

If released in that window the RED LED will then go ON during the Restore process for some many seconds it takes to format the flash and restore the factory blink code.
 
Last summer had a similar situation with a T4.0 screwed into a box with 8x8 NeoTrellis and no accesss to the Prog button. All leds are lit but I've capped the max brightness to about 15% however the box does get a little warm.
Crashed it with an "out of array bounds" scenario so atttempted revert to last working sketch - no go, then then tried uploading Blink, still no go. Only took ~ 15 seconds to unscrew the box. The MCU seemed slightly warm to the finger.
Attempted the 15 second Prog button rescue procedure, still more no go. After a bit more headscratching had more or less accepted that I'd killed my first Teensy so powered down and unplugged its Usb, turned on the soldering iron and trusty coffee machine.
About 15 minutes later gave it one last chance, uploaded Blink and waited for the IDE to complain about not finding the T4, then plugged it in and pressed the Prog button. Success!
Can only assume that whatever the MCU did to itself when it crashed caused it to heat up enough to trigger an over temperature shutdown before it was able to either accept a fresh upload or complete the 15 second restore process .
 
Something is very wrong with the software install if you're getting "elf file is for Unknown Board". Arduino is supposed to create the .elf file first. Then it extracts the binary data from the .elf file to create the .hex file.

When Teensy Loader opens the .hex file, it also opens the .elf file. Normally it should always print the 3 lines Frank showed. First, it does a very quick check for the type of .elf file. Then it does a full compare of the binary data from both .hex and .elf. You should see the message "elf binary data matches hex file". Then it prints a 3rd message confirming which board the .elf file is meant to use, after parsing all the data.

The main reason Teensy Loader looks at the .elf file is because the .hex file lacks clear info about which board it is meant to use. Long ago, in the days of Teensy 1.0 and the first months of Teensy 2.0, there was no check whether your code was built for the correct board. When we has 3 boards (Teensy 1.0, Teensy++ 1.0, and the brand new Teensy 2.0) the changes of getting it wrong became much higher. Each board had different USB hardware and clock settings, so if you uploaded code built for a different board it would just sit there doing nothing, until you pressed the button to recover.

The feature to read the .elf file and check it against the .hex file was added. I believe that was around 2009.


I would *really* like to understand how you're getting a .elf file which isn't a recognized board. Are you using Arduino & Teensyduino? This sort of problem is never supposed to be able to happen with the normal software!
 
While it doesn't help right now, for Teensyduino 1.55 as part of the work I'm doing to support encrypted code in flash, I'm adding more ability in Teensy Loader and other tools to parse the .hex files.

Before Teensy 4.0, every .hex file had essentially no metadata. While the first bytes in the interrupt tables can give some info, it quickly gets into reverse engineering the code and a lot of guesswork and hard coding assumptions that don't allow for programs to be built with changes to the linker scripts.

The IMXRT chips require headers in certain places in the flash memory. So far, all the tools have handled .hex files as binary data without any known meaning, as we've always done for prior boards, relying only on the .elf file for any info. While the .hex files still don't specify which board is meant to be used, there is quite a lot of info which can be checked. My hope is to make future Teensy Loader more aware of that structure. If you open a .hex file which is corrupt or obviously can't work, Teensy Loader really ought to give you an error rather than blindly writing it into Teensy's flash memory.
 
Thank you everyone for quick response! Actually, for most of the time nothing happened when I plugged this teensy in, no linux kernel message or whatever. What I posted is a rare case where "something" happened. @Frank B and @PaulStoffregen, I just had my Teensyduino 1.54 running on my linux box. Not sure which sketch or board I set at that time. Teensy loader somehow just started automatically and gave me that log message. @defragster I did release the button after ~15 sec when I saw the brief red flash... nothing happened next, no led are on after that. I guess I just have to accept that this teensy is gone.
 
It might have something to do with the fact that I tried to power the board using 3.3V pin... while at the same time plugging in usb cable to try to reprogram the board... I think I also just bricked my nano 33 iot this way :(
 
Status
Not open for further replies.
Back
Top