Teensy did not respond to a USB-based request to enter program mode.

Paul,
Still no luck getting this one to erase or reprogram. I've tried the 15 second press and hold of the button. No red light ever blinks. I do flash the orange LED as part of my program - it never does anything different - pressing the button or not - unless
If I hold the button on power-up, then the orange LED never comes on, but still no red LED.
The program running is using interrupts and is multi-threaded... It runs fine, but I need to make some minor fixes...
Any other way to bring this 4.1 back into a re-programmable status?
I have been able to reprogram a couple of other 4.0's and 4.1's I have here with the same several cables I've tried.
Thanks!
Andy
 
Alright... Since I can't get this one to enter reprogramming mode, and the Teensy is hard to pull from my current PCBA, can I pull the flash chip and replace it? Are there any suspicions as to why this thing won't enter reprogramming mode?
No problem programming other 4.1's and 3.6's...

TIA!
 
That looks like a nice program and assembly with the display!

Safe to assume since it was soldered to that PCB as pictured it has been programmed some number of times after that?

When USB is connected, and Teensy Loader program is open. And some sketch loaded in the IDE and ready to upload with a 'Verify' build.

Select the " Help / Verbose Info " on the "Teensy" Loader program.

Then press the button. Does anything appear in the 'Verbose Information' application window?

If the Teensy USB is unplugged then plugged in again while holding the program Button - and releasing it a second after plugging it in?

If anything shows up in, select that text and paste it here for Paul's review.
 
Defragster, Thanks! Yes, been updating software for weeks until it wouldn't let me.
Verify build yields:
Code:
22:12:45.238 (post_compile 19): Begin, version=1.56
22:12:45.238 (loader): remote connection 11 opened
22:12:45.238 (post_compile 19): Sending command: comment: Teensyduino 1.56 - LINUX64 (teensy_post_compile)
22:12:45.239 (loader): remote cmd from 11: "comment: Teensyduino 1.56 - LINUX64 (teensy_post_compile)"
22:12:45.239 (loader): remote cmd from 11: "status"
22:12:45.239 (loader): file changed
22:12:45.263 (loader): File "/tmp/arduino_build_970580/EngineMonitor-F1.ino.hex", 321536 bytes
22:12:45.263 (loader): File "EngineMonitor-F1.ino.hex". 321536 bytes
22:12:45.263 (post_compile 19): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_970580/, EngineMonitor-F1.ino.hex
22:12:45.263 (post_compile 19): Disconnect
22:12:45.274 (loader): remote connection 11 closed

Nothing additional happens when I press the button (or short the program pin to ground.)

When I try to program it, I get:
Code:
22:15:51.627 (post_compile 20): Begin, version=1.56
22:15:51.628 (loader): remote connection 11 opened
22:15:51.628 (post_compile 20): Sending command: comment: Teensyduino 1.56 - LINUX64 (teensy_post_compile)
22:15:51.628 (loader): remote cmd from 11: "comment: Teensyduino 1.56 - LINUX64 (teensy_post_compile)"
22:15:51.629 (loader): remote cmd from 11: "status"
22:15:51.629 (loader): file changed
22:15:51.654 (loader): File "/tmp/arduino_build_970580/EngineMonitor-F1.ino.hex", 321536 bytes
22:15:51.654 (loader): File "EngineMonitor-F1.ino.hex". 321536 bytes
22:15:51.654 (post_compile 20): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_970580/, EngineMonitor-F1.ino.hex
22:15:51.654 (post_compile 20): Disconnect
22:15:51.664 (loader): remote connection 11 closed
22:15:51.672 (post_compile 21): Begin, version=1.56
22:15:51.675 (loader): remote connection 11 opened
22:15:51.675 (post_compile 21): Sending command: comment: Teensyduino 1.56 - LINUX64 (teensy_post_compile)
22:15:51.675 (loader): remote cmd from 11: "comment: Teensyduino 1.56 - LINUX64 (teensy_post_compile)"
22:15:51.675 (loader): remote cmd from 11: "status"
22:15:51.675 (post_compile 21): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_970580/, EngineMonitor-F1.ino.hex
22:15:51.675 (post_compile 21): Disconnect
22:15:51.686 (post_compile 22): Running teensy_reboot: /home/ameyer/Downloads/arduino-1.8.19-linux64/arduino-1.8.19/hardware/teensy/../tools/teensy_reboot
22:15:51.686 (loader): remote connection 11 closed
22:15:51.686 (loader): remote connection 11 opened
22:15:51.686 (loader): remote connection 11 closed
22:15:51.686 (reboot 23): Begin, version=1.56
22:15:51.686 (reboot 23): location = /dev/ttyS0
22:15:51.686 (reboot 23): portlabel = /dev/ttyS0
22:15:51.686 (reboot 23): portprotocol = serial
22:15:51.686 (reboot 23): Serial device /dev/ttyS0 will be tried first
22:15:51.695 (loader): remote connection 11 opened
22:15:51.699 (reboot 23): add device: subsys=usb, type=usb_device, location=/sys/devices/pci0000:00/0000:00:1c.4/0000:06:00.0/usb3/3-2/3-2.4
22:15:51.699 (reboot 23):   devnode=/dev/bus/usb/003/122, subsystem=usb, ifacenum=-1
22:15:51.699 (reboot 23): add child:  subsys=usb, type=usb_interface, location=/sys/devices/pci0000:00/0000:00:1c.4/0000:06:00.0/usb3/3-2/3-2.4/3-2.4:1.0
22:15:51.699 (reboot 23):   parent location=/sys/devices/pci0000:00/0000:00:1c.4/0000:06:00.0/usb3/3-2/3-2.4
22:15:51.699 (reboot 23):   model=37 (Teensy 4.1)
22:15:51.700 (reboot 23): add child:  subsys=tty, type=(null), location=/sys/devices/pci0000:00/0000:00:1c.4/0000:06:00.0/usb3/3-2/3-2.4/3-2.4:1.0/tty/ttyACM0
22:15:51.700 (reboot 23):   parent location=/sys/devices/pci0000:00/0000:00:1c.4/0000:06:00.0/usb3/3-2/3-2.4
22:15:51.700 (reboot 23):   devnode=/dev/ttyACM0, subsystem=tty, ifacenum=0
22:15:51.700 (reboot 23): add child:  subsys=usb, type=usb_interface, location=/sys/devices/pci0000:00/0000:00:1c.4/0000:06:00.0/usb3/3-2/3-2.4/3-2.4:1.1
22:15:51.700 (reboot 23):   parent location=/sys/devices/pci0000:00/0000:00:1c.4/0000:06:00.0/usb3/3-2/3-2.4
22:15:51.707 (reboot 23): usb scan found 1 devices
22:15:51.707 (reboot 23): found Teensy Loader, version 1.56
22:15:51.707 (reboot 23): Sending command: show:arduino_attempt_reboot
22:15:51.741 (loader): remote cmd from 11: "show:arduino_attempt_reboot"
22:15:51.741 (loader): got request to show arduino rebooting message
22:15:51.742 (reboot 23): Sending command: comment: Teensyduino 1.56 - LINUX64 (teensy_reboot)
22:15:51.742 (loader): remote cmd from 11: "comment: Teensyduino 1.56 - LINUX64 (teensy_reboot)"
22:15:51.742 (loader): remote cmd from 11: "status"
22:15:51.743 (reboot 23): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_970580/, EngineMonitor-F1.ino.hex
22:15:51.743 (reboot 23): do_reset (serial) /dev/ttyACM0
22:15:51.759 (loader): remote cmd from 11: "status"
22:15:51.759 (reboot 23): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_970580/, EngineMonitor-F1.ino.hex
22:15:51.759 (reboot 23): status read, retry 0
22:15:51.859 (loader): remote cmd from 11: "status"
22:15:51.859 (reboot 23): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_970580/, EngineMonitor-F1.ino.hex
22:15:51.859 (reboot 23): status read, retry 1
22:15:51.960 (loader): remote cmd from 11: "status"
22:15:51.960 (reboot 23): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_970580/, EngineMonitor-F1.ino.hex
22:15:51.960 (reboot 23): status read, retry 2
22:15:52.061 (loader): remote cmd from 11: "status"
.
.
.

22:15:57.911 (reboot 23): Status: 1, 1, 0, 0, 0, 0, /tmp/arduino_build_970580/, EngineMonitor-F1.ino.hex
22:15:57.911 (reboot 23): status read, retry 61
22:15:58.011 (reboot 23): Teensy did not respond to a USB-based request to automatically reboot.
22:15:58.012 (loader): remote connection 11 closed
22:15:59.791 (ports 5): del child: location=/sys/devices/pci0000:00/0000:00:1c.4/0000:06:00.0/usb3/3-2/3-2.4/3-2.4:1.0/tty/ttyACM0
22:15:59.791 (ports 5):   devnode=/dev/bus/usb/003/122, subsystem=usb, ifacenum=-1
22:15:59.791 (ports 5): unknown action: unbind
22:15:59.796 (ports 5): del child: location=/sys/devices/pci0000:00/0000:00:1c.4/0000:06:00.0/usb3/3-2/3-2.4/3-2.4:1.1
22:15:59.797 (ports 5): unknown action: unbind
22:15:59.799 (ports 5): del child: location=/sys/devices/pci0000:00/0000:00:1c.4/0000:06:00.0/usb3/3-2/3-2.4/3-2.4:1.0
22:15:59.803 (ports 5): unknown action: unbind
22:15:59.804 (ports 5): del device: location=/sys/devices/pci0000:00/0000:00:1c.4/0000:06:00.0/usb3/3-2/3-2.4
22:16:00.373 (ports 5): add device: subsys=usb, type=usb_device, location=/sys/devices/pci0000:00/0000:00:1c.4/0000:06:00.0/usb3/3-2/3-2.4
22:16:00.373 (ports 5):   devnode=/dev/bus/usb/003/123, subsystem=usb, ifacenum=-1
22:16:00.373 (ports 5): usb_add: /dev/bus/usb/003/123 (Teensy 4.1) Serial

And the existing code on the Teensy resets and starts running again. The new code is not loaded and I get the following in the IDE status window.
I've tried this with small simple example code and have the same issue.
Hesitant to build up another board to have this happen again if we can figure out why here (and possibly save this one - not sure I can desolder the Teensy as the SMD components are on the back side of the board - lesson learned!)

Memory Usage on Teensy 4.1:
FLASH: code:113132, data:199808, headers:8592 free for files:7804932
RAM1: variables:204448, code:110232, padding:20840 free for local variables:188768
RAM2: variables:12640 free for malloc/new:511648
Teensy did not respond to a USB-based request to enter program mode.
Please press the PROGRAM MODE BUTTON on your Teensy to upload your sketch.
An error occurred while uploading the sketch


Any thoughts?
 
@PaulStoffregen might make something useful of the Verbose output

It shows linux in use. Wonder if some OS update recently is breaking Teensy connection?

Do you have access to another computer?
 
I'm catching up to messages I've missed over the last few days. Looks like msg #23 to #30 on this thread about about different case than the msg #1 - #22. Is everything after msg #23 specifically about the hardware shown in photos on msg #25?

This really looks like case of damaged hardware, especially since programming another known good Teensy works. Messing around with reinstalling software and pouring over verbose info logs from the software side is probably isn't a good use of time.

Let me first ask if I'm read and understood some key pieces correctly.

In msg #29, "When I try to program it ... the existing code on the Teensy resets and starts running again". Just so I understand, it seems you're saying that clicking Upload in Arduino is having an effect on this Teensy board, causing it to restart your program. Is that right?

Also in msg #29, "Nothing additional happens when I press the button (or short the program pin to ground.)" means that pressing the button does not cause your program to restart, that it keeps on running properly?

Again in msg #29, the verbose info shows "parent location=/sys/devices/pci0000:00/0000:00:1c.4/0000:06:00.0/usb3/3-2/3-2.4" and "model=37 (Teensy 4.1)" meaning a Teensy 4.1 was detected connected to USB controller 3 at port 3-2.4. Was any other Teensy connected at that time, perhaps the known good one? In other words, if the damaged Teensy was the only one connected to your PC, then this message confirms the USB port is working properly on that damaged board. You could also run "tail -f /var/log/syslog" in a terminal and just plug & unplug the USB cable and watch whether the Linux kernel gives message about the USB device connecting and disconnecting. The main question is whether this board still has working USB communication?

My gut feeling from the info shows so far is a loss of communication between the bootloader chip (U2) and main processor (U1). But normally the bootloader should blink the red LED in various blink codes if communication isn't working. So maybe whatever has gone wrong is also impacting the ability to control the red LED?

I'm afraid all the facts so far don't quite fit any of the well known failure modes. Pretty mysterious...

One random thing to try is physically pressing on U1. Sometimes mechanical flexing of the PCB or a heat gradient across U1 if accidentally heated on 1 side or corner by a soldering iron can weaken or break the BGA solder joints underneath the chip. When this happens, the chip may have just a microscopic air gap between some of the BGA pads and the PCB. In those cases, just pressing on the chip can get it to temporarily connect. Sometimes this type of damage can be fixed by applying liquid flux and then reheating the BGA with a hot air gun.

The other concern I have, from the photo in msg #25, it whether anything on the bottom side of Teensy 4.1 might be touching the metal ground plane or anything else on the PCB. I can't tell the height of the plastic between Teensy and the PCB. It looks shorter than normal, but maybe that's just an optical illusion from the camera angle?

Well, that's all the guesswork I have right now. This really looks like lack of communication between U1 & U2, but the lack of red LED blink codes about the error contradicts that guess, so I'm afraid I just don't have a really good answer here about what really went wrong, which of course means I don't have specific suggestions to fix it.
 
I'm catching up to messages I've missed over the last few days. Looks like msg #23 to #30 on this thread about about different case than the msg #1 - #22. Is everything after msg #23 specifically about the hardware shown in photos on msg #25?

Correct.

This really looks like case of damaged hardware, especially since programming another known good Teensy works. Messing around with reinstalling software and pouring over verbose info logs from the software side is probably isn't a good use of time.

Let me first ask if I'm read and understood some key pieces correctly.

In msg #29, "When I try to program it ... the existing code on the Teensy resets and starts running again". Just so I understand, it seems you're saying that clicking Upload in Arduino is having an effect on this Teensy board, causing it to restart your program. Is that right?
That is correct.

Also in msg #29, "Nothing additional happens when I press the button (or short the program pin to ground.)" means that pressing the button does not cause your program to restart, that it keeps on running properly?
Correct. Button does nothing at all when the code is running. (nor does shorting the program pin to ground)

Again in msg #29, the verbose info shows "parent location=/sys/devices/pci0000:00/0000:00:1c.4/0000:06:00.0/usb3/3-2/3-2.4" and "model=37 (Teensy 4.1)" meaning a Teensy 4.1 was detected connected to USB controller 3 at port 3-2.4. Was any other Teensy connected at that time, perhaps the known good one? In other words, if the damaged Teensy was the only one connected to your PC, then this message confirms the USB port is working properly on that damaged board. You could also run "tail -f /var/log/syslog" in a terminal and just plug & unplug the USB cable and watch whether the Linux kernel gives message about the USB device connecting and disconnecting. The main question is whether this board still has working USB communication?
Only the suspect Teensy connected. USB connection info looks just like a good Teensy being connected - from dmesg...

My gut feeling from the info shows so far is a loss of communication between the bootloader chip (U2) and main processor (U1). But normally the bootloader should blink the red LED in various blink codes if communication isn't working. So maybe whatever has gone wrong is also impacting the ability to control the red LED?

I'm afraid all the facts so far don't quite fit any of the well known failure modes. Pretty mysterious...

One random thing to try is physically pressing on U1. Sometimes mechanical flexing of the PCB or a heat gradient across U1 if accidentally heated on 1 side or corner by a soldering iron can weaken or break the BGA solder joints underneath the chip. When this happens, the chip may have just a microscopic air gap between some of the BGA pads and the PCB. In those cases, just pressing on the chip can get it to temporarily connect. Sometimes this type of damage can be fixed by applying liquid flux and then reheating the BGA with a hot air gun.

The other concern I have, from the photo in msg #25, it whether anything on the bottom side of Teensy 4.1 might be touching the metal ground plane or anything else on the PCB. I can't tell the height of the plastic between Teensy and the PCB. It looks shorter than normal, but maybe that's just an optical illusion from the camera angle?

Well, that's all the guesswork I have right now. This really looks like lack of communication between U1 & U2, but the lack of red LED blink codes about the error contradicts that guess, so I'm afraid I just don't have a really good answer here about what really went wrong, which of course means I don't have specific suggestions to fix it.

Paul, Defragster, I really appreciate the help! I tried pressing on the processor - to no avail.

These things are awesome - Rev1 has been flying for ~100 hours so far. Need to get Rev2 flying ASAP as I have a project starting with the University in a month or so.

I'm going to spin this PCBA (I committed the standard "connect Rx to Rx and Tx to Tx error" :mad:) and install a new Teensy 4.1 on it... Need to spin the board that sits near the engine as well - InAmp design error... Can't wait for the bigger display and more data!
 
Back
Top