"error sending reboot command (HID)"

Status
Not open for further replies.
S

smarrocco

Member
I've begun seeing this error command ("error sending reboot command (HID)") when upload to a teensy 4. It happens approximately 90 times out of 100, with the other ten occasions working successfully. Both platformIO and Arduino IDE have the issue.

The TeensyLoader (v1.49) appears when expected, displaying "Arduino is attempting to put Teensy into programming mode...." for several seconds. If I hit the button on the Teensy, the upload will happen and the Loader App shows "reboot successful". If I do NOT hit the button, the console of the IDE shows:

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

....and the upload never happens. Automatic mode in the loader does appear to be active.

Is there some type of config file for the Teensy Loader that might have become corrupt?
 
Is there a only the single T_4 connected?
Is that T_4 properly selected in "Tools / Port"
Does it show any similar failures uploading a simple Blink example?
TeensyLoader has a "Help / Verbose Info" option to display a window of the activity passing through it. Does it show any activity on the failed uploads?
What version of the IDE?
What OS?
Is there a SerialMonitor program attached?
 
Yes, only one Teensy 4 is connected. Wiring is unchanged, lengths, cables, hardware setup. It was working fine, then after one compile this message began appearing. Sometimes (maybe one in 10 times) the Blink example will succeed, then my other code project might works once, then continuously fails with the same error. Happens in both Arduino IDE and platformIO. Several cold boots had no effect. I did notice that someone else mentioned online having a similiar error--in their case the Blink example "fixed" it. However, that does not always seem to be the case for me. There does not seem to be any obvious pattern between blink and my other code working or not. I recently began using the build flags for "USB_KEYBOARDONLY"--but disabling/enabling that does not seem to have any effect either.

Arduino IDE is 1.8.10
OS is Windows 10 1909.
I have not attached any serial monitor.

What follows is the verbose output from the Teensy Loader.....

12:51:20.832 (post_compile 1): Begin, version=1.49, high-res time
12:51:21.069 (loader): Teensy Loader 1.49, begin program
12:51:21.140 (loader): File "firmware.hex". 46780 bytes, 2% used
12:51:21.156 (loader): Listening for remote control on port 3149
12:51:21.156 (loader): initialized, showing main window
12:51:21.180 (loader): remote connection 1356 opened
12:51:21.181 (post_compile 1): Sending command: comment: Teensyduino 1.49 - WINDOWS (teensy_post_compile)
12:51:21.181 (loader): remote cmd from 1356: "comment: Teensyduino 1.49 - WINDOWS (teensy_post_compile)"
12:51:21.181 (loader): remote cmd from 1356: "status"
12:51:21.183 (loader): HID/win32: vid:056A pid:0028 ver:0107
12:51:21.183 (loader): HID/win32: vid:056A pid:0028 ver:0107
12:51:21.183 (loader): HID/win32: vid:195D pid:6008 ver:0015
12:51:21.183 (loader): HID/win32: vid:195D pid:6008 ver:0015
12:51:21.184 (loader): HID/win32: vid:05AC pid:0220 ver:0069
12:51:21.184 (loader): HID/win32: vid:195D pid:6008 ver:0015
12:51:21.184 (loader): HID/win32: vid:195D pid:6008 ver:0015
12:51:21.246 (loader): HID/win32: vid:0B05 pid:1867 ver:0200
12:51:21.247 (loader): HID/win32: vid:046D pid:C526 ver:0500
12:51:21.247 (loader): HID/win32: vid:16C0 pid:04D0 ver:0279
12:51:21.247 (loader): HID/win32: vid:16C0 pid:04D0 ver:0279
12:51:21.248 (loader): HID/win32: vid:046D pid:C526 ver:0500
12:51:21.248 (loader): HID/win32: vid:046D pid:C526 ver:0500
12:51:21.249 (loader): HID/win32: vid:056A pid:0028 ver:0107
12:51:21.250 (post_compile 1): Status: 1, 0, 0, 0, 0, 0, z:\CodeArchive\PlatformIO\Teensy 4.0\SamPad\SamPad 2.0.0011\.pio\build\teensy40\, firmware.hex
12:51:21.250 (post_compile 1): Sending command: dir:z:\CodeArchive\PlatformIO\Teensy 4.0\SamPad\SamPad 2.0.0011\.pio\build\teensy40\
12:51:21.250 (loader): remote cmd from 1356: "dir:z:\CodeArchive\PlatformIO\Teensy 4.0\SamPad\SamPad 2.0.0011\.pio\build\teensy40\"
12:51:21.251 (post_compile 1): Sending command: file:firmware.hex
12:51:21.251 (loader): remote cmd from 1356: "file:firmware.hex"
12:51:21.275 (loader): File "firmware.hex". 46780 bytes, 2% used
12:51:21.281 (loader): remote cmd from 1356: "status"
12:51:21.285 (loader): remote cmd from 1356: "auto:eek:n"
12:51:21.285 (post_compile 1): Status: 1, 0, 0, 0, 0, 0, z:\CodeArchive\PlatformIO\Teensy 4.0\SamPad\SamPad 2.0.0011\.pio\build\teensy40\, firmware.hex
12:51:21.285 (post_compile 1): Sending command: auto:eek:n
12:51:21.286 (post_compile 1): Disconnect
12:51:21.297 (loader): remote connection 1356 closed
12:51:21.297 (post_compile 2): Running teensy_reboot: "C:\Users\smarrocco\.platformio\packages\tool-teensy\teensy_reboot.exe" teensy_reboot.exe "-board=TEENSY40"
12:51:21.298 (loader): remote connection 1412 opened
12:51:21.322 (reboot 3): Begin, version=1.49, high-res time
12:51:21.322 (reboot 3): LoadLibrary cfgmgr32 ok
12:51:21.322 (reboot 3): LoadLibrary ntdll ok
12:51:21.325 (reboot 3): found_usb_device, id=\\?\usb#vid_16c0&pid_04d0#6770710#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
12:51:21.325 (reboot 3): found_usb_device, loc=usb:0/140000/0/8/4/4 Port_#0004.Hub_#0006
12:51:21.325 (reboot 3): found_usb_device, hwid=USB\VID_16C0&PID_04D0&REV_0279
12:51:21.325 (reboot 3): found_usb_device, devinst=00000007
12:51:21.325 (reboot 3): add: loc=usb:0/140000/0/8/4/4, class=USB, vid=16C0, pid=04D0, ver=0279, serial=6770710, dev=\\?\usb#vid_16c0&pid_04d0#6770710#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
12:51:21.325 (reboot 3): hiddev_from_devinst_list: iface=1
12:51:21.326 (reboot 3): 00000010: path=\\?\hid#vid_16c0&pid_04d0&mi_01#9&15f5b036&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
12:51:21.328 (reboot 3): found_usb_device complete
12:51:21.329 (reboot 3): hid, found devinst=0000000E
12:51:21.329 (reboot 3): hid, found devinst=00000012
12:51:21.329 (reboot 3): hid, found devinst=00000010
12:51:21.332 (loader): remote connection 1360 opened
12:51:21.332 (loader): remote cmd from 1360: "show:arduino_attempt_reboot"
12:51:21.332 (loader): got request to show arduino rebooting message
12:51:21.333 (reboot 3): found Teensy Loader, version 1.49
12:51:21.333 (reboot 3): Sending command: show:arduino_attempt_reboot
12:51:21.336 (loader): remote cmd from 1360: "comment: Teensyduino 1.49 - WINDOWS (teensy_reboot)"
12:51:21.336 (loader): remote cmd from 1360: "status"
12:51:21.336 (reboot 3): Sending command: comment: Teensyduino 1.49 - WINDOWS (teensy_reboot)
12:51:21.339 (reboot 3): Status: 1, 1, 0, 0, 0, 0, z:\CodeArchive\PlatformIO\Teensy 4.0\SamPad\SamPad 2.0.0011\.pio\build\teensy40\, firmware.hex
12:51:21.339 (reboot 3): hid_send_feature
12:51:23.701 (loader): Verbose Info event
12:51:26.339 (loader): remote cmd from 1360: "status"
12:51:26.339 (reboot 3): error opening reboot command
12:51:26.345 (reboot 3): Status: 1, 1, 0, 0, 0, 0, z:\CodeArchive\PlatformIO\Teensy 4.0\SamPad\SamPad 2.0.0011\.pio\build\teensy40\, firmware.hex
12:51:26.345 (reboot 3): status read, retry 0
12:51:27.670 (loader): remote cmd from 1360: "status"
12:51:27.674 (reboot 3): Status: 1, 1, 0, 0, 0, 0, z:\CodeArchive\PlatformIO\Teensy 4.0\SamPad\SamPad 2.0.0011\.pio\build\teensy40\, firmware.hex
12:51:27.674 (reboot 3): status read, retry 1
12:51:27.774 (loader): remote cmd from 1360: "status"
12:51:27.784 (reboot 3): Status: 1, 1, 0, 0, 0, 0, z:\CodeArchive\PlatformIO\Teensy 4.0\SamPad\SamPad 2.0.0011\.pio\build\teensy40\, firmware.hex

....(Contents edited for brevity)......

12:51:33.142 (loader): remote cmd from 1360: "status"
12:51:33.155 (reboot 3): Status: 1, 1, 0, 0, 0, 0, z:\CodeArchive\PlatformIO\Teensy 4.0\SamPad\SamPad 2.0.0011\.pio\build\teensy40\, firmware.hex
12:51:33.155 (reboot 3): status read, retry 49
12:51:33.256 (reboot 3): Teensy did not respond to a USB-based request to automatically reboot.
12:51:33.295 (loader): remote connection 1360 closed
12:51:33.318 (loader): remote connection 1412 closed


At any point during or after this output, clicking the Teensy 4 on board button loads the code successfully.
 
Good info. Not seeing anything giving a solution based on what I've observed. Can you change to another known good USB data cable?

Can you open IDE to one SLOW blink sketch, and then another FAST Blink sketch - both with Port to that T4
>Open the Verbose Info and clear it, on each upload the TeensyLoader GUI should show the 'sketchName.Hex' as it changes.
->Upload Slow, if it works clear Verbose
->Upload Fast, if it works clear Verbose

Repeating that until one fails will see if the TeensyLoader observes anything to report.

If that works as it should it might suggest the other sketch is taking T4 USB offline with memory overwrite or such thing.

There may be something simpler being the problem or to test another might suggest?
 
First, this message is absolutely normal for the case of a program running on Teensy which keeps interrupts disabled or otherwise prevents USB communication. Since you tested with just a simple LED blink program which doesn't do those things, that case doesn't apply. But I'm mentioning it first because it's by far the most common cause of this problem. Other people will find this thread, and the message needs to be clear that a program which blocks interrupts or stays in low power modes or hard faults the CPU or shuts off the USB will cause this problem.

The rest of this message only applies when you've ruled out the problem is code on Teensy.

Investigating *why* Teensy doesn't respond is difficult. The first step is to figure out whether your PC really is sending the request (it probably isn't). Doing this requires monitoring the USB traffic. The best but very expensive way is to use a USB protocol analyzer which captures all the USB communication and sends it to another PC. The cheap but less-than-ideal way is to run software on your PC which tries to capture all the USB communication. I'm not personally familiar with those programs, since I use the Beagle 480 analyzer.

If you discover your PC isn't actually sending the control transfer which asks Teensy to reboot, the *really* hard task is figuring out why. Usually this involves stopping other programs or services, hoping to get lucky to find the one that's interfering. Having a way to reliably view the USB communication, so you can quickly see whether the control transfer happened on the USB port makes this faster & easier than having to try uploads and wait for the 5 second timeout before that message prints.
 
Do you use a Hub? I had trouble with HUBs (some Time ago, with T3.x) - try without.
And if not, just try an other USB Port. I'm not sure that everything regarding USB is bug-free in Windows, and it seems to cache some "things".
it might have been my PC-Mainboard in conjunction with the HUbs or defective drivers.. don't know.
With new PC, everything is OK now, even with the old HUBs (?!) - ok, this involves a new Windows installation..
 
I've brushed away as much as possible to narrow down this issue. At first glance, it seems very similar to a posting someone else made on the forums regarding Blinkie code "fixing the problem", but I suspect that it is a coincidence.

@ Frank B: No hubs involved, also tested with different ports just in case. Paul has mentioned to me (previously) about the possibility of "iffy" USB cables and I have experience it firsthand.

@defragster: You mentioned the possibility of something in the code "taking T4 USB offline with memory overwrite or such thing." Paul was correct; determining why the Teensy wouldn't respond was difficult. While a USB protocol analyzer sounds like a fun way to kill an evening, I decided to debug without it. I did try (yet again) another set of USB cables just in case. If anything, I now wish I had a proper USB cable checker for future testing.

I've been utilizing a third-party developed linked list library. Careful code analysis seems to indicate that, when utilizing a nested linked list, that there are some memory shenanigans taking place, i.e. leaking or memory overwriting, perhaps over something expected to be available or hard-faulting the CPU or blocking an interrupts as Paul suggested.

Seems a classic example of "just because it compiles correctly doesn't mean it does what it should".

Eliminating the inner nested linked list and keeping the code limited to a single list made the problem go away, but now I don't trust the source for that Linked List. Back to arrays for the time being, which makes me long for a nice VB.NET memory managed collection.

One difficulty was that once the issue began happening, the platformIO IDE needed to be shut down entirely, then restarted before repaired code would succeed.

In the end, the problem seems to have boiled down to bad source code (in my sketch, not firmware) that caused some type of memory corruption on the Teensy 4 and caused it to fail to respond to the external Teensy Loader when it attempted to upload new code.

Thank you all for the assist!
 
The post #4 double Blink only test was to rule out code issue as Paul noted and explained in p#5 - given the test was intermittent after p #2 blink test.
 
Status
Not open for further replies.
Back
Top