#33 dfu-util freezes

[Thanathan]

I'm trying to download/upload firmware to the simtrace board using dfu-util.

However even though the device is idle, dfu-util does not continue:

$ dfu-util -d 16c0:0762 -a0 -U ./main_simtrace_backup.bin -R

dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Opening DFU capable USB device...
ID 16c0:0762
Run-time device DFU version 0100
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0

The device was booted in bootloader mode.
Anything I can do?

[Thanathan]

OS is a freshly set up and updated Kali Linux.

[Tormod Volden]

Hi, are you sure upload works on this device? Did it work with an earlier version of dfu-util? Just checking because many bootloaders do not support uploads properly although they advertise it.

[Thanathan]

Hi Tormod,

I have the same problem when I try to download a firmware to the device.
I just tried it with dfu-util 0.8 on a freshly set up debian machine as well. Same result it freezes after determening that the device is idle.

[Tormod Volden]

We'll need someone who has such a device to do some debugging. What do you know about the bootloader on the device? Has it been upgraded over the last years? Did the failing devices work with dfu-util before? If so, it could be a change in dfu-util, or in libusb, or in the kernel that caused the regression. This can be narrowed down by trying out different versions.

Running dfu-util with the verbose options (multiple use of -v) can provide more information about what is is stuck at. Also running with strace or ltrace can be of help. Or rebuilding dfu-util for debugging, and running it in gdb or another debugger.

[Tormod Volden]

Apparently mentioned on the Simtrace mailing list but not much useful information available: http://lists.osmocom.org/pipermail/simtrace/2016-November.txt

[Anonymous]

Hi,

I found some time to debug the issue using the simtrace v1.4 board.
The issue was introduced with df-util v0.8.
Flashing stucks on the milli_sleep here:
milli_sleep(status.bwPollTimeout);
https://sourceforge.net/p/dfu-util/dfu-util/ci/master/tree/src/main.c#l546

The timeout value was read from the device using DFU_GETSTATUS command:
https://sourceforge.net/p/dfu-util/dfu-util/ci/v0.7/tree/src/main.c#l978
Received value is always 8946091, so quite a lot milliseconds ;)

It seems there is a missing quirk (QUIRK_POLLTIMEOUT) for SimTrace board, like here:
https://sourceforge.net/p/dfu-util/dfu-util/ci/v0.9/tree/src/quirks.c#l36
The quirk will set the timeout to fixed 5 ms.

Could you please add such quirk in the next release for:
VENDOR: 0x16C0 (VENDOR_VOTI)
PRODUCT: 0x0762 (Osmocom SIMtrace)

Such quirk was set for all VOTI devices in dfu-util v0.7.

BR,
Szymon Mielczarek

[Tormod Volden]

Hi Szymon,
Wonderful! Thanks a lot for the debugging. I will add the quirk, and also make a new release in the not so far future - this was pretty much the blocking bug.

I should also think about printing a warning when these crazy timeout values appear...