Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 8 of 8

Thread: "error sending reboot command (HID)"

  1. #1
    Junior Member
    Join Date
    Jan 2020
    Posts
    17

    "error sending reboot command (HID)"

    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?

  2. #2
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    12,233
    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?

  3. #3
    Junior Member
    Join Date
    Jan 2020
    Posts
    17
    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: "auton"
    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: auton
    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.

  4. #4
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    12,233
    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?

  5. #5
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,530
    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.

  6. #6
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    6,920
    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..

  7. #7
    Junior Member
    Join Date
    Jan 2020
    Posts
    17
    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!

  8. #8
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    12,233
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •