Project

General

Profile

Actions

Bug #4302

closed

DFU bootloader start fails

Added by tsaitgaist over 4 years ago. Updated over 4 years ago.

Status:
Resolved
Priority:
Urgent
Assignee:
Category:
firmware
Target version:
-
Start date:
12/03/2019
Due date:
% Done:

100%

Spec Reference:

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.

Actions #1

Updated by tsaitgaist over 4 years ago

the exact same bootloader does not work reliably on ST34.
the USB stack does not manage to reach the configured state.
I also don't see USB messages on the SIMtrace side coming in, except reset frames sent by the host after some time (when it thinks there is something wrong with the cable).

more debugging is ongoing.

Actions #2

Updated by tsaitgaist over 4 years ago

I do not recommend flash the current bootloader until I fixed this issue.
surprisingly the old bootloader not also shows this behaviour, but only on ST34.
at least I can reliably debug the issue now.

Actions #3

Updated by tsaitgaist over 4 years ago

  • Status changed from New to In Progress
Actions #4

Updated by laforge over 4 years ago

Is therr anything I can help with? Do we have log output of working vs non-working situations? this should always be attached to bug reports. Do we know the reset cause, I.e. why the CPU is reset during starting the dfu loader on st34?

Actions #5

Updated by laforge over 4 years ago

[...]
-I- Modem 0: physical SIMrata work-around
-I- 0: Use local/physical SIM
-I- Modem 1: physical SIM
-I- 1: Use local/physical SIM
-I- entering main loop...
-I- 0: Card Detect Status -1 -> 1
-I- 1: Card Detect Status -1 -> 1
-I- USB is now configured
-W- Sta 0x88828 [0] -W- _ 

=============================================================================
DFU bootloader 0.6.1.15-d708 for board qmod
(C) 2010-2017 by Harald Welte, 2018-2019 by Kevin Redon
=============================================================================
s

=============================================================================
SIMtrace2 firmware 0.6.1.15-d708
(C) 2010-2017 by Harald Welte, 2018-2019 by Kevin Redon
=============================================================================
-I- Chip ID: 0x28900960 (Ext 0x00000000)
-I- Serial Nr. 51203120-39513450-30303232-37323035
-I- Reset Cause: software reset (processor reset required by the software)
-I- Detected Quad-Modem ST34
-I- VERSION_DET ADC=3731 => 3003455 uVund
-I- USB init...
USBD_Init
SetAddr(40) SetCfg(1) cfgChanged1 -I- calling configure of all configurations...
-I- calling init of config 1...
-I- Modem 0: physical SIMrata work-around
-I- 0: Use local/physical SIM
-I- Modem 1: physical SIM
[...]
Actions #6

Updated by laforge over 4 years ago

Latest news from my side:

  • 0.5.1.33-d1497 still works
  • 0.5.1.58-71cf fails
Actions #7

Updated by laforge over 4 years ago

I seems that qmod-dfu-flash-0.5.1.47-389a.bin is the first broken version, while qmod-dfu-flash-0.5.1.45-ac7e.bin is still working.

Actions #8

Updated by laforge over 4 years ago

culprit ist definitely 5db9402a5f346e30288db228157f71c29aefce5a - if I revert that on top of master, things start working

Actions #9

Updated by laforge over 4 years ago

  • Assignee changed from tsaitgaist to laforge
  • % Done changed from 50 to 90

This should be fixed by https://gerrit.osmocom.org/#/c/simtrace2/+/16514/

mschramm and tsaitgaist, please help by verifying in your setups.

Actions #10

Updated by mschramm over 4 years ago

  • Assignee changed from laforge to tsaitgaist

Thanks, looks good: with 0.6.1.16-c9af the ST34 can again be updated by DFU; it was successfull several subsequent times.

This also means, the testsuite again runs through!

Actions #11

Updated by mschramm over 4 years ago

  • Assignee changed from tsaitgaist to laforge

(assignee change was not intended)

Actions #12

Updated by laforge over 4 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 90 to 100

same here, I did quite a bit of (DFU only) testing with 0.6.1.16-c9af on both the dfu and cardem side, and it seems it works reliably.

Actions #13

Updated by laforge over 4 years ago

I tagged 0.7.0 to make the change more obvious. Let's use + announce 0.7.0 to customers.

Actions #14

Updated by tsaitgaist over 4 years ago

I will test it tomorrow

Actions #15

Updated by tsaitgaist over 4 years ago

laforge wrote:

This should be fixed by https://gerrit.osmocom.org/#/c/simtrace2/+/16514/

mschramm and tsaitgaist, please help by verifying in your setups.

well spotted. yes this was the issue and fixed it.
I tested 10x times in a row on both ST and had no error, even no USB reset issues.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)