I also started out with some python code for this 
but then thought since I already have all structures defined in dfuse.c it would probably be faster to carve something out from there in c. And then I realized it would be much faster to implement raw binary download in dfuse.c so that’s where I left it at now. So your script would be welcome!
You have the DfuSe file specification UM391, right? It should not be necessary to reverse-engineer the existing DfuSe files.
Absolutely. It is not very likely something new will appear in the assembly file starting with (whitespace)END. So I will strip the > away from the script so that it works on macosx without issues.
rich and tomwid, can you please see if you encounter any trouble (libusb, echo -e) building the latest official dfu-util code at git.openezx.org/dfu-util.git ? They plan a dfu-util 0.2 release next week, so it would be good to report MacOSX issues and have them fixed before the release.
I guess most trouble you had building my dfuse branch would be the same in the upstream code, so it would be good to have it fixed there for everybody.
Yes, I’ve studied that and then had a look at the DFU files; my first attempt is at building a single DFU that combines both LIB and APP.
A script is attached doing this for both Seeed v.25e and BenF 3.10. It is still a pretty raw work in progress (no CRC is computed, .bin addresses and names are hardcoded, DfuSeDemo.exe does not validate the resulting .dfu’s, etc), but most of the stuff is there.
BenF reworked firmware’s can be uploaded successfully, Seeed’s one apparently misses the APP part (I know because flashing only that makes the Nano happy again).
If you care giving it a go, here it is!
Antonio
tests.zip (48.6 KB)
Exploiting my attempt at unpacking the DFUs, I’ve confronted in hexer your dso.bin and the
seeed_app_v2.5e.dfu.target0.image0.bin
.
The working (IAR) one has 442 bytes before those produced by the .text segment - maybe we just need to copy also .isr_vector segment into the .bin file?
Antonio
We do already, although you are right it was missing for a while after some recent changes (the new linker script I think). Please check latest code. But it does not help.
I have looked at the dso.lst and I see that some calls to the library are wrapped with *_from_thumb functions, as if we are calling ARM functions. However, Cortex-M3 only supports Thumb code and not ARM code, so I don’t understand why gcc is doing this.
I tried to check this out but I get
git clone http://git.openezx.org/dfu-util.git
Cloning into dfu-util...
fatal: http://git.openezx.org/dfu-util.git/info/refs not found: did you run git update-server-info on the server?
richard-hydes-macbook-air:test rich$
Sorry for my poorly worded questions, I have carefully read the whole thread 3 times now. I am mostly trying to figure out where things are currently, and what can be expected to work. One thing I do not really understand is the relationship between the lib and app. I believe it use to exist to get around the limitations of the iar free compiler, but as the source is closed I can agree with your point about it not being worth much effort. What I don’t understand is why this is still an issue in the gcc world. Is the current source set assuming the existence of this lib? I am guessing that it is still required, but is there another version I should be loading or compiling against? I was trying to get a version I could build and load. In my case all the PC I have are amd64s and the dfuse demo does not run on them. So I am happy to have something I can run at home. I have ubuntu and macs at home at the moment, plus an old amd64 xp box. I was just trying to load a run a version I could build. I can now load images with your great work, but if I load the current dsonano git tree it does not run. I still see Benf stuff and it does not work. If I reload the benf 3 app it does work so I am guessing I need to load a different library, but I thought that the need for the library had gone away. So I got lost. Which library does the current git tree assume? I fully agree with your analysis and I am hoping to support this effort. If there still is a library required for the current tree, which one is it? I am assuming it is a closed source, because if it weren’t why would it still exist and not be a part of the current dsonano tree?
The http link is to the web interface. To clone, use the git address (displayed on the web page): git://git.openezx.org/dfu-util.git
Yes, this is how it is. The git tree I am playing with is basically the 2.5 APP. It uses calls to the closed source 2.5 LIB. If the LIB was open-source I would have put it inside the git tree, and we would not have so much trouble with the lib function calls, which I think is the reason it does not work. On the other hand, the 1.1 source was from before the split into APP and LIB (originally to overcome the IAR 32k limitation). So maybe that would have been an easier start.
Theoretically it should be possible to recompile the 2.5 APP with gcc (from my git tree) and use it together with the 2.5 LIB. But there are some issues, maybe from calling IAR-compiled code from gcc-compiled code. I think there are some bugs in gcc also, dealing with cortex-m3, for instance the thumb/arm wrappers which should not be there since the cortex-m3 is thumb only.
On your DSO Nano, the bootloader runs at 0x0800000. As long as you do not want to upgrade (pressing the down button) it jumps to the LIB code, which starts at 0x08004000. After displaying the LIB version, it jumps to the APP code which starts at 0x0800c000. In the APP code there are various calls to functions in the LIB.
Each APP hardcodes the addresses of functions in the LIB. So any APP depends on a particular version of the LIB. The LIB has a function vector table so it can be recompiled without having to change the APP again, I suppose. But the ABI (application binary interface) has to match, with a precise definition of what each function does and returns and the number and type of arguments.
Okay doing the correct git clone I fail with the same error as I did with your tree. I am not sure if this is due to a bug in autogen.sh or a feature of the mac autobuild scripts. I am not sure where to report it either.
richard-hydes-macbook-air:dfu-util rich$ ./configure --prefix=/opt/local/ checking for a BSD-compatible install… /usr/bin/install -c
checking whether build environment is sane… yes
checking for a thread-safe mkdir -p… m4/install-sh -c -d
checking for gawk… gawk
checking whether make sets $(MAKE)… yes
checking whether to enable maintainer-specific portions of Makefiles… no
checking for gcc… gcc
checking for C compiler default output file name… a.out
checking whether the C compiler works… yes
checking whether we are cross compiling… no
checking for suffix of executables…
checking for suffix of object files… o
checking whether we are using the GNU C compiler… yes
checking whether gcc accepts -g… yes
checking for gcc option to accept ISO C89… none needed
checking for style of include used by make… GNU
checking dependency style of gcc… gcc3
./configure: line 3332: syntax error near unexpected token USB,' ./configure: line 3332: PKG_CHECK_MODULES(USB, libusb >= 0.1.4,’
richard-hydes-macbook-air:dfu-util rich$
and
*line 3331 in ./configure
PKG_CHECK_MODULES(USB, libusb >= 0.1.4,
{ { echo “$as_me:$LINENO: error: *** Required libusb >= 0.1.4 not installed ***” >&5
echo “$as_me: error: *** Required libusb >= 0.1.4 not installed ***” >&2;}
{ (exit 1); exit 1; }; })
doing some investigation it appears that reasons I do not yet understand the mac ports world does not appear to be expanding pkg.m4 correctly, or there is a well know underquoting problem, or the reference macro does not exist in the version of autoconf and pkg-config on my system. Unfortunately I am not much further along at knowing what to fix.
Thanks. I mentioned the problem on the mailing list for dfu-util, lists.openmoko.org/pipermail/dev … 06927.html and they would like to have it fixed, so more information or patches are welcome.
Hello all,
here’s a Python script for parsing/dumping/building DFU files. I’ve checked the output files with DfuSeDemo.exe, and flashed them to my DSO Nano v2 successfully.
Tormod, I’ve got a bug report for your dfu-util: the file test_seeed.dfu (combined Seeed v2.5e APP + v2.5 LIB) created from my test_dfu.py works correctly when downloaded to Nano via DfuSeDemo.exe on Windows, but it does not if I download it with dfu-util on Linux. Apparently the LIB part is OK, while the APP is broken.
Antonio
dfu-20101116_0050.tgz (48.5 KB)
So there are 2 issues. One the way the package check is being done for libusb is failing to expand. The other which is probably easier to fix, but not one I know how to do, is to make it so the build can specify which libusb he wishes to use at configure time. With the latter I simple command line option of --use-libusb=/opt/local/ would solve all the hand edits I have to do. Fixing that might also solve the expansion failure, but all I can do is test at this point.
Well I spent a little time with BenF’s code base, and I can get most of it to compile. A few more edits to iar2gas to handle a few labels, run cpp. Unfortunately I do not complete understand the map script stuff so I can’t build it all the way. He has 3 libraries in addition to the app.
Finishing the make files is quite straight forward other than that last step. He has done such a good job I do not want to twist his tree around, but I don’t quite get the purpose for each of the different libs.
Sounds good! I would suggest you use a similar Makefile to build the LIB. So you will have two builds, the APP and the LIB. Each of them uses files in its …/library directory (standard stuff from ST) but that is included in each build, you don’t need to build it separately.
The linker script for the LIB has to be modified for RAM and ROM start addresses, which can be found in the project/lnkarm_flash.xcl files.
I hope there will be an official git (or similar) tree soon, where we can contribute patches to make it easier to build with gcc.
That’s a really great tool! Awesome how you could make it so clean and compact with python. I have a few wishes:
I have checked the verbose output and I can not see anything going wrong in terms of erase and write addresses. Can you read back the flash memory (using dfu-util -U) and see if it is corrupted somewhere?
BTW, maybe we should make a separate dfu-util thread. There are so many topics in this thread, about everything but building cross-compilers since we dropped that a long time ago
Well, er, thanks a lot!
Actually I thought it was not sufficiently clean, but compact it is for sure - Python is a very good language for short and quick tools.
If you use it as python dfu.py <file.dfu>, the script already decodes the dfu file only; to dump the contained images, you need to add -d.
In the attached version I’ve added an option for setting the USB id from the command line - the DSO nano is the only ST thingie I have, so I had not thought someone would need it - thanks for asking.
Also, I’ve added a license line: for me LGPL3 is perfectly fine. Of course, if you’d like to put it under git you are more than welcome!
Thanks for your gcc work, btw - I’m trying to follow, but git is not yet a beast I’ve tamed 
Antonio
dfu-20101118.tgz (47.4 KB)
Bit late but I did pull the latest changes from your git repository yesterday and now everything builds correctly without any issues using the instructions I posted earlier