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$
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.
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:
a list option that only decodes the files but does not write new files
an option to set usb ID (defaulting to 0483:df11, which most DfuSe loaders already use, makes sense)
add your name and copyright, and let me add it to the git tree
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
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
