It is a great idea to use version 1.1. Because we used 3rd party codes which does not permit open source and divided it into LIB in version 2.2 or later ,I do not have the complete source code. 
I will try to use v1.1.
I’ve been investigating about DFU mode, in order to do a full Linux build.
The command dfutool from bluez-utils seems almost what is needed,
but fails at the end:
ant9000@sirius:~/dfu$ lsusb
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 005: ID 0483:df11 SGS Thomson Microelectronics
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hubSo my Nano is attached on bus 3, let’s try to flash it:
# dfutool -d /dev/usbmon3 upgrade DS0201_LIB_V2.5.dfu
Filename DS0201_LIB_V2.5.dfu
Filesize 20095
Checksum 42c9c2e9 (valid)
Available devices with DFU support:
1) Bus 003 Device 009: ID 0483:df11 Interface 0
Select device (abort with 0): 1After loading for a while, the tool says it is finalizing, but bails out
with the message
Can't send final block: Broken pipe (32) Still need to investigate what is the meaning of this, but definitely the upload is
not finalized - no trace of it when rebooting the scope.
This thread is interesting:
http://www.spinics.net/lists/linux-bluetooth/msg01967.html
Source code for dfutool:
http://git.kernel.org/?p=bluetooth/bluez.git;a=blob_plain;f=tools/dfutool.c;hb=HEAD
Antonio
The DfuSe protocol made by ST and used in the DSO Nano is considerably different from the USB standard DFU. There is no compatibilty either way. DfuSe uses special DFU files with a number of images including the starting addresses. The host program has to decrypt the DFU file and program the flash at the right memory location after erasing the affected memory pages.
On standard DFU, the host program just sends the whole file to the device and the device knows itself where and how to flash it.
I have been looking at extending the dfu-util program to deal with DfuSe. My non-functional WIP is on http://gitorious.org/~tormod/unofficial-clones/dfuse-dfu-util/commits/dfuse. I have got uploading to work, and am working on setting address pointers. To do is erasing and downloading, and finally, decoding of DFU files.
Thanks for the clarification, Tormod - and for the code, of
course!
I’ve downloaded also the ST manual for DFUse, and will
look into it harder - at first sight it seemed to me that
the DFUse protocol does contain a few extensions, but
is mostly the same stuff as standard DFU.
http://www.st.com/stonline/products/literature/an/17068.pdf
Antonio
Thanks tormod. You are doing a great job. I can learn a lot from what you did. 
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!
Short update: Setting address and erasing pages work now, after I fixed a “typo” in my address parsing code. The rest should be straight forward but I have not so much time…
Tip for those who want to debug USB on Linux: wireshark works great for USB sniffing, but you will need a recent version. For Ubuntu 10.04 you can find updated packages for wireshark and libpcap0.8 in my PPA https://launchpad.net/~tormodvolden/+archive/ppa. It seems like you have to launch it with “gksu wireshark” to be able to read the USB streams.
Also, for working on the DFU without sudo, make a /etc/udev/rules.d/45-dsonano.rules file with this:
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="df11", MODE="660", GROUP="plugdev"
Success! Finally I can reflash my DSO (and some other ST-based stuff I have) natively on Linux. Use it like this:
The software is of just-enough-to-make-it-work-for-me quality. Later I will see if it can be accepted into the official dfu-util.
Hello Tormod and Jerry,
I’ve been also testing the dfu-util code on my DSO Nano v2, but had no success: the scope reboots immediately after receiving the lib file, and I cannot send the app. At reboot, the firmware still is the older version.
# ../../dfu-util -v --dfuse default -a 0 -D DS0201_LIB_V2.5.dfu
dfu-util - (C) 2007-2008 by OpenMoko Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY
dfu-util does currently only support DFU version 1.0
Opening USB Device 0x0000:0x0000...
Claiming USB DFU Runtime Interface...
Determining device status: state = dfuIDLE, status = 0
WARNING: Runtime device already in DFU state ?!?
Found Runtime: [0x0483:0xdf11] devnum=30, cfg=0, intf=0, alt=0, name="@Internal Flash /0x08000000/12*001Ka,116*001Kg"
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x0400
bytes_per_hash=401
Starting download: [##################################################] finished!
state(7) = dfuMANIFEST, status(0) = No error condition is present
unable to read DFU statusDo I have to pack both LIB and APP in a single .dfu file to make it work?
Antonio
Antonio, it does not look like you have the latest version (git commit 0530f73). And are you on the dfuse branch (“git checkout dfuse”)?
Jerry,
you are right - I’ve downloaded my version yesterday…
so long ago 
Tried the commit you refer to, and it works great for me
too.
Thanks a lot for your work, Tormod!
Antonio
Thanks, Tormod and Antonio. Later,we will use GNU toolchain for the development.
FWIW The sh autogen.sh fails on osx, with an expansion failure on libusb. Removing that from the resulting configure and hand editting src/Makefile yields an executable on OSX that at least response to dfu-util -l
Update: I was able to update my V1 on my mac.
I too gave it a shot to get it running on OS X but there’s something that causes a segdump when trying to actually upload a firmware. Haven’t had time to debug the issue yet but here are my instructions:
Install MacPorts
Install the Java Developer Package for your OS version.
sudo port install libusb libusb-compat git-core
(mkdir somedir)
cd somedir
git clone git://gitorious.org/~tormod/unofficial-clones/dfuse-dfu-util.git
cd dfuse-dfu-util
git checkout dfuse
./autogen.sh
./configure --libdir=/opt/local/lib --includedir=/opt/local/include
#
# Look for the line "echo -e '#ifndef DFU_UTIL_VERSION' \" in src/Makefile and remove the -e argument
#
make
(sudo make install)I have not tried your path, but I have already installed the Java developer framework and macports libusb. I pointed to the libusb in /opt/local. With the configure edit and had editting the Makefile to use libusb in /opt/local I was able to upgrade the firmware on by DSO nano 1.0. I did configure. Removed the failed expansion of libusb. editted the makefile in src to use /opt/local/include and lib for libusb, and it works.
I may have been to quick to claim success. The firmware does not appear to have change. 
But it thinks it is
About everyone time it fails with a permission denied on failing to claim interface.
macbook:DSO%20BenF%20Firmware%20v3-1 rich$ dfu-util -d 0x0483:0xdf11 -i 0 -D DSO\ BenF\ LIB\ v3.01.dfu
dfu-util - © 2007-2008 by OpenMoko Inc.
© 2010 Tormod Volden (experimental DfuSe support)
This program is Free Software and has ABSOLUTELY NO WARRANTY
dfu-util does currently only support DFU version 1.0
Opening USB Device 0x0483:0xdf11…
Claiming USB DFU Runtime Interface…
Determining device status: state = dfuIDLE, status = 0
WARNING: Runtime device already in DFU state ?!?
Found Runtime: [0x0483:0xdf11] devnum=4, cfg=0, intf=0, alt=0, name="@Internal Flash /0x08000000/12001Ka,116001Kg"
Claiming USB DFU Interface…
Setting Alternate Setting #0 …
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x0400
bytes_per_hash=280
Starting download: [##################################################] finished!
state(7) = dfuMANIFEST, status(0) = No error condition is present
unable to read DFU status
macbook:DSO%20BenF%20Firmware%20v3-1 rich$ dfu-util -d 0x0483:0xdf11 -i 0 -D DSO\ BenF\ APP\ v3.10.dfu
dfu-util - © 2007-2008 by OpenMoko Inc.
© 2010 Tormod Volden (experimental DfuSe support)
This program is Free Software and has ABSOLUTELY NO WARRANTY
dfu-util does currently only support DFU version 1.0
Opening USB Device 0x0483:0xdf11…
Claiming USB DFU Runtime Interface…
Determining device status: state = dfuERROR, status = 10
dfuERROR, clearing status
not at least 2 device changes found ?!?
Opening USB Device…
Found Runtime: [0x0483:0xdf11] devnum=4, cfg=0, intf=0, alt=0, name="@Internal Flash /0x08000000/12001Ka,116001Kg"
Claiming USB DFU Interface…
Cannot claim interface: Permission denied
macbook:DSO%20BenF%20Firmware%20v3-1 rich$ dfu-util -d 0x0483:0xdf11 -i 0 -D DSO\ BenF\ APP\ v3.10.dfu
dfu-util - © 2007-2008 by OpenMoko Inc.
© 2010 Tormod Volden (experimental DfuSe support)
This program is Free Software and has ABSOLUTELY NO WARRANTY
dfu-util does currently only support DFU version 1.0
Opening USB Device 0x0483:0xdf11…
Claiming USB DFU Runtime Interface…
Determining device status: state = dfuIDLE, status = 0
WARNING: Runtime device already in DFU state ?!?
Found Runtime: [0x0483:0xdf11] devnum=4, cfg=0, intf=0, alt=0, name="@Internal Flash /0x08000000/12001Ka,116001Kg"
Claiming USB DFU Interface…
Setting Alternate Setting #0 …
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x0400
bytes_per_hash=423
Starting download: [##################################################] finished!
state(7) = dfuMANIFEST, status(0) = No error condition is present
unable to read DFU status
macbook:DSO%20BenF%20Firmware%20v3-1 rich$
macbook:DSO%20BenF%20Firmware%20v3-1 rich$ dfu-util -l
dfu-util - © 2007-2008 by OpenMoko Inc.
© 2010 Tormod Volden (experimental DfuSe support)
This program is Free Software and has ABSOLUTELY NO WARRANTY
dfu-util does currently only support DFU version 1.0
Found Runtime: [0x0483:0xdf11] devnum=4, cfg=0, intf=0, alt=0, name="@Internal Flash /0x08000000/12001Ka,116001Kg"
Found Runtime: [0x0483:0xdf11] devnum=4, cfg=0, intf=0, alt=1, name="@SPI Flash : M25P64/0x00000000/64064Kg,64064Kg"
Found Runtime: [0x05ac:0x8216] devnum=4, cfg=0, intf=3, alt=0, name=“UNDEFINED”
macbook:DSO%20BenF%20Firmware%20v3-1 rich$
A few more notes or comments. Initially I downloaded a tar ball from the git repository. That one is the one that appeared to work. I just did a git clone and that one times out instead of thinking it is working. I noticed that the transfer size is different.
Also was reminded that I had to hand edit the dfu_version.h because the mac osx echo does not allow echo -e so the generation of that file fails.
If I set the transfer size to a smaller value the git version works like the regular, but it doing so I have trashed by firmware as it will no longer start.
With the git version I managed to trash my firmware and I can nolonger upload more than 3 bytes. Not good. I will try to find a non amd windows box and reflash it tomorrow with the demo and see if I bricked it some how.
Important! You have to checkout the dfuse branch after doing git clone! If not you are on the master branch which is just a clone of the official dfu-util code tree. Therefore you would then be building and running the old dfu-util without my modifications.
Ohh, didn’t get branch… What is the git command for that? Sorry I am a complete git newbie.