Dear Marcel and others,

I'm developing DFU capabilities for a ARM7 STM32 based device. As I've been 
new to DFU this wasn't a straigt forward process for me, but my endeavors are 
slowly paying off. :) I must say that I've been glad to find dfutool. It was 
very helpful to have a lean code base I was able to modify as I whished and 
that could easily be stepped through with gdb.

While the device by now can be programmed more or less using the stock 
dfutool, I have made some modifications (based on 
http://www.usb.org/developers/devclass_docs/usbdfu10.pdf) that may be useful 
to others; these are mainly:

- When waiting for the DNLOAD_BUSY -> idle state transition, do not sleep 1s, 
but use the timeout suggested by the device in the state response. makes the 
upgrade a little bit quicker.

- Between the last download request in the loop and the EOF (zero length) 
download-request, there should also be repeated get_status requests; otherwise 
the EOF-download request would fail (for me, it did).
The patch fixes it this way: basically, the order of get_status and download 
within the download loop should better be reversed, in my eyes. Download 
should be first, and get_status should wait for idle state.

- After the EOF download request, some devices want to get put into 
manifestation state (initiated by get_status) where the write operation could 
be finished and the device can reset itself. I have implemented this.


I didn't find information about the current state and goals for dfutool. Would 
you mind elaborating a little about this?
Is dfutool only targeted at bluetooth device firmware upgrades? Does it cover 
the full range of bluetooth devices (this would surprise me since DFU protocol 
implementations seem to differ from device to device. there are various 
different tools for linux, each with its own strength/weakness/list of 
supported target devices)? 

I'm curious about any experience of how devices in practise do differ in 
details when talking to them via DFU. With DfuSe by STMicroelectronics there 
is an effort of an DFU extension that allows devices to announce their 
capabilities (memory layout, alternative memory settings to choose from, add 
generic 'function' list and functions such as LIST_FUNCTIONS, SET_POINTER, 
ERASE). I'm not considering to use it since it appears to be a little complex 
for simple consumer devices. I consider it dangerous as well, since 
SET_POINTER/ERASE allows to access any memory area, not just the one reserved 
for the firmware image, possibly making the device not recoverable via DFU. 
And ironically, is incompatible to most dfu tools because in UPLOAD/DOWNLOAD 
requests, the blocks 0 and 1 are reserved for the generic function extension 
thing (data blocks are numbered from 2 to n instead of 0 to n. when used with 
e.g. dfutool, the device would get into STATUS_ERRSTALLEDPKT because it's 
forbidden to DNLOAD to block 1).

Another question regarding the hardcoded upload/download packet size of 1023 
bytes (in dfutool.c): Why this and not e.g. 1024? (I'm going to use a fixed 
size of 1024 because this allows usb firmware code to erase one page of flash 
memory and program it in one go).

Best regards,
Sandro