The UM0391 document at my.st.com/public/STe2ecommuniti … UM0391.pdf is also useful.
I have a number of issues with DfuSe:
- The compatibility issue already mentioned. It is using the same mechanisms and facilities but in a different way. I checked the Bluez link from ant9000 and it confirms how bad it is, it is impossible to use tools made for one with the other.
- ST has not published all the code for their Windows “Demonstration” program
- Reverse engineering of their program shows that they are not following their own recommendations
So for any project my recommendation is “DfuSe - just say no” 
However we already have all those Nanos out there with the DfuSe bootloader installed and it is a bit tricky to replace it. So making a minimal dfuse tool should be worthwhile.
Using the USB sniffer UsbSnoop I captured the session between the ST Demo and the DSO Nano when downloading a dfu file. Please find attached my analysis of it together with the full log. You’ll see that for instance, ST downloads only one block of 1k in each DNLOAD “session”, setting the address each time, whereas they describe the download in UM0391 as setting the address once, then run one DNLOAD session with the whole firmware. Of course, both ways should work in theory, but why did they say one thing and do another… Note also they use DFU_ABORT to quit from dfuDNLOAD-IDLE and to change mode, apparently there is no “cleaner” way to do this.
The current status of my code is that after quitting the DNLOAD that sets the address, the state looks fine, but initiating the UPLOAD to read from that address fails with the dreaded “failed control message” (maybe the same as the “Broken pipe (32)”) and the device needs to be reset. Uploading without setting the address (dfu-util --dfuse default -a 0 -U /tmp/test) works great (and really fast too).
More hands and eyeballs on this code would be very welcome!