Bug #4302
closedDFU bootloader start fails
100%
Description
this is a copy of the issue first reported internally.
reported on device:
sysmoQMOD v3.1
affected devices:
sysmoQMOD, SIMtrace v2, and possibly OWHW (the USB setup did not show this behavior)
affected bootloader:
DFU <= 0.6.1.12
issue symptoms:
it is not possible to flash the main application firmware over USB (using the DFU bootloader).
when using dfu-util, the device is detached to restart in DFU mode (DFU procedure), but device does not appear in DFU mode. dfu-utils still finds the device in runtime mode.
dfu-util log output:
ID 1d50:4004 Run-time device DFU version 0100 Claiming USB DFU Runtime Interface... Determining device status: state = appIDLE, status = 0 Device really in Runtime Mode, send DFU detach request... Resetting USB... dfu-util: Lost device after RESET?
solution:
- try to run dfu-util multiple times until it works once (temporary, unreliable solution)
- force the DFU bootloader as described in https://osmocom.org/projects/simtrace2/wiki/Flashing#DFU-2 (temporary solution)
- flash DFU bootloader >= 0.6.1.13 (permanent solution fix fixes). the flashing process is partially described in https://osmocom.org/projects/simtrace2/wiki/Flashing#SAM-BA-2 . a less cumbersome alternative is being worked on.
issue description:
is output indicates the DFU bootloader failed to be USB enumerated after reset (tried multiple times over a couple of seconds).
In this case the bootloader restarts the micro-controller (a USB bootloader which is not reachable over USB is not very useful).
Often this means the host missed the USB reset and/or did not enumerate in time.
The same USB reset procedure is used afterwards by the main application, and this works since this has been enumerated (where the DFU detach has been sent over).
This issue is very USB host, stack, hub, and load dependent (I was not able to see it on my setup, but reports show it appeared sporadically on others).
USB reset works the following way:
- optional: USB host sends a RESET request (a USB packet)
- 1.5k pull-up resistor on D+ is removed/disabled
- wait 20 ms (required >= 10 ms, as specified in "Universal Serial Bus Specification Revision 2.0" Table 7-2. Low-/full-speed Signaling Levels, but acceptable > 2.5 us)
- start USB stack (including pull-up on D+)
I've made two changes:
- increase the time to 50 ms (https://gerrit.osmocom.org/c/simtrace2/+/16431). this solved the enumeration issues on the affected setups.
- reboot bootloader instead of main firmware when the bootloader USB enumeration failed (https://gerrit.osmocom.org/c/simtrace2/+/16432)
this first change has been tested on the following USB laptops and hubs (including the setups where it did not work):
- QMOD testing station + logilink UA0096
- thinkpad T420 (directly)
- lenovo E495 (directly and with hub, 10 consecutive runs)
- logilink UA0096
- logilink UA0124
- logilink UA0126
- d-link DUB-H7 rev D1
- Terminus Technology 1a40:0101 (noname)
switching to the DFU bootloader now works flawlessly (on these setups).
there still might be existing setups where USB enumeration after reset fails, but this can't be predicted (we already respect the USB specification).
virtual machines might exhibit this behavior even more.
