Problem with custom DFU and dfu-util

Products & Technology DSO Nano
#1

Hello,
here’s a new thread for dfu-util, so that the open questions are not lost.

What’s exactly in the uploaded file obtained by dfu-util -U? It is clearly different from my original DFU, being 32768 instead of the 46263 I’ve downloaded to the DSO Nano. It is a direct dump of the flash, I’d say - but I don’t know how to compare the two files and tell if the bin is corrupted or not. How would you go about for spotting a problem?

Thanks,

Antonio
compare.tgz (34.5 KB)

#2

It is a memory dump, starting by default at 0x08004000 (determined by the boot loader) unless you specify another address. The length is limited in the dfu-util program to 32k (you can change it if you like), since there is nothing in the bootloader that stops at the end of the memory, and going beyond hangs the bootloader. Adding an option to dfu-util for specifying length is on the TODO list, but uploading is very fast anyway and it is easy to trim the output with for instance “dd”.

So if you upload from 0x08004000 you should be able to compare it with a raw binary file of the LIB, and from 0x0800C000 with a raw binary file of the APP.

#3

I’m not able to get dfu-util to work the way you describe. As far as I can tell, setting the start address makes no difference - the uploaded file is always a dump of the first 32k of memory only:

sudo ./dfu-util -s 0x08004000 -a0 -U lib0.bin
sudo ./dfu-util -s 0x0800792c -a0 -U lib1.bin
sudo ./dfu-util -s 0x0800c000 -a0 -U app.bin

and I end up with three identical bin files. Is there something I’ve missed?

Thanks,

Antonio

#4

Yes, the dfu-util does not interpret 0x so it silently misreads the address as 0, which is then used in the code to signify default address, and the bootloader will use 0x08004000 each time… This should be fixed in dfu-util of course. Until then, use for instance:

dfu-util -a 0 --dfuse $((0x0800c000)) -U app.bin

To compare the files, truncate the app.bin to the size of the original bin, then run diff on them. If they do not match, run “hd” on each of them and for instance “diff -y -W 200” on the two hd output files.

EDIT: Fixed dfu-util to complain and bail out if it does not understand the address, and to accept 0x (hex) or 0 (octal) prefix.

#5

Thanks a lot for your fix!

I’ve tried again and can confirm that the dump uploaded from the Nano is not equal to the firmware I download - the first image file is identical, the second one starts equal but diverges after some hundreds bytes, the third one is different right from the start.

In a hex editor you see that some bytes do stay the same in both the original firmware image and the uploaded one - maybe sometimes the routine to set the address fails and dfu-util fails to recognize it?

In attachment you find all the files I use to test; use the shell script prova.sh for following my test step by step. If I can do something more for narrowing down the problem, just let me know!

Antonio
compare-20101121_1601.tgz (99.3 KB)

#6

tormod are you aware of this project stm32flash ?

#7

Thanks for the testing package and the log. I realized when looking at the log that there was a serious bug: If the address of the data is not the beginning of a flash page, and the data is large enough to reach into the following page, the program did not erase both pages…

I have fixed it, and verified using your test files.

#8

Thanks, I just saw this project today myself. This is a better link: http://code.google.com/p/stm32flash/
Also the web page that is mentioned there, http://stm32.spacevs.com/, is excellent.

However, the stm32flash tool is for flashing over serial line, and not over USB, so it is not so useful for the DSO Nano.

#9

Yes, very good source of information! :slight_smile:

Yes, I know but it was in the hope you can reuse some information from this project…

Following your advice, I continu here this thread http://www.seeedstudio.com/forum/viewtopic.php?p=4543#p4543, and I compiled dfuse-dfu-util with the latest version of Sourcery G++ Lite 2010.09-51, but nothing, nothing happen with the same previous command…

In attachment, there is the resulting binary.

#10

dfu-util is going to run on your computer, so compile it with your normal gcc. Only code that should run on your Nano (or other arm-based device) needs to be built with arm-none-eabi-gcc.

And, as explained on http://gitorious.org/~tormod/unofficial-clones/dfuse-dfu-util, you will need to switch to the dfuse branch before building it. Otherwise there is no dfuse support.

#11

I’ll repost full instructions here since they have become buried deep in other threads:

sudo port install libusb libusb-compat git-core   #   on MacOSX (install MacPorts and Java Developer Package first)
sudo apt-get build-dep dfu-util   # on Ubuntu and Debian and derivatives
git clone git://gitorious.org/~tormod/unofficial-clones/dfuse-dfu-util.git
cd dfuse-dfu-util
git checkout dfuse  # Or for old git versions: git checkout -t origin/dfuse
./autogen.sh
./configure  # on most systems
./configure --libdir=/opt/local/lib --includedir=/opt/local/include  # on MacOSX only
make[/code]
If you later want to update with latest git version:
[code]make maintainer-clean
git pull
./configure
make[/code]
Your dfu-util binary is now inside the src folder. Use it from there, or install it to /usr/local/bin by running "sudo make install".

Now to download a dfu file from your computer to your Nano:
[code]
dfu-util -a 0 --dfuse default -D your-firmware.dfu
[/code]
Or to download a raw binary file (in case you are developing):
[code]dfu-util -a 0 --dfuse 0x08004000 -D your-lib.bin
dfu-util -a 0 --dfuse 0x0800C000 -D your-app.bin
#12

hum, not exactly, I just see that in my /var/log/messages…

ok, I saw your message, but I still get segfault of dfu-util. In attachment, the latest version compiled following your latest instruction.

In attachment, the resulting ouputs strace with the command below

strace dfu-util -a 0 --dfuse default -D DSO_BenF_LIB_v3.02.dfu 2>&1 |tee -a /tmp/DFuse_DSO_BenF_LIB_v3.02.dfu.v6.retry.log

and, the corresponding log in /var/log/messages:

segfault at ffffffff ip 00189e1e sp bff7655c error 4 in libc-2.11.1.so[110000+153000]

DFuse_DSO_BenF_LIB_v3.02.dfu.v6.retry.log.gz (1.5 KB)

#13

You are simply not following my instructions. The dfu-util you attached has no dfuse support. Please attach a terminal session log where I can see you do all the steps from scratch. That will be more useful than “nothing happen” :wink:

#14

perhaps you prefer, nothing happened on the command line. Anyway, I am not able to send you by private message, then in attachment [edit: removed]all the log session are available in the hope you understand what’s I had messed in the compilation process of dfu-util.

ok, may you provide directly the right command to detect directly my error (grep ‘dfuse’ dfu-util?) ?

#15

Thanks. It seems that the building goes fine. But note that “make” only leaves the new dfu-util in the src directory. You can use it from there (usually what I do) or run “sudo make install” which will copy dfu-util and man pages to /usr/local/bin etc. But since this is a work in progress and you will likely update it often, I would recommend just keeping it in src so that you do not have any old versions lying around.

So I think you are running another dfu-util than the one you have built. The right one will list “experimental DfuSe support” when you run it with “-V”. And as you suggest, you can run “strings dfu-util | grep -i dfuse” on it also.

#16

Due to popular demand :slight_smile: Note that the software is still experimental.

I am afraid I can not do this for each time I update the git repo, but I have made a Ubuntu package of it right now which you can download from
launchpad.net/~tormodvolden/+ar … lter=lucid
Just download and install the right .deb package. It should install fine in Ubuntu 10.10 or Debian unstable as well.

#17

you are right, shame on me, I switched to another user due to compiler messing but for the “make install” I switched to root account to jump in the wrong old directory… :confused:

Thanks.

Command used to upgrade:

dfu-util -a 0 --dfuse default -D DSO_BenF_LIB_v3.02.dfu dfu-util -a 0 --dfuse default -D DSO_BenF_APP_v3.20.dfu

In attachment, the logs and the final binary in 32bits for distribution like Ubuntu 10.04 (don’t use it until you know exactly what you are doing, provide as this without any waranty etc)

tormod thank you very much for your endavour and for your help (Apologize me to bother you with futility).
DFuse_DSO_BenF_APP-LIB_v3.02-20.dfu.v6.log.tar.bz2 (1.5 KB)
dfu-util.2010111820.gz (32.2 KB)

#18

Hello Tormod,
now each DFU file I’ve tested can be uploaded without problems: thanks a lot for your excellent work!

Antonio

#19

My dfu-util has gone through many changes lately and I have updated garden.seeedstudio.com/index.php?title=Dfu-util with new syntax and build instructions. Expect this to land in the official dfu-util 0.5 soon.