There is no .end just END. I have not previously had issues with the version of sed on a Mac before
I see the pattern so I am a bit lost; I will experiment a bit and see. I just want to know where the error was. I will look into why sed is missing it.
LDMIA SP!, {R4-R7}
BX LR
END
/* ******************************* END OF FILE *********************************** */
The “.end” is not being eaten, but I am unfamiliar with the “>” after the END in the s clause. If I remove that it works.
That is a new pattern symbol on me, and clearly the Mac hasn’t heard of it either.
So currently my pool has this one change
And I can compile.
How does one go from the output of the Make to something dfu-util can download? I seem to being missing a step or, as usual understanding, in how the whole process works.
This is the end-of-word pattern, which makes sure for instance ENDING is not matched. Does it help if you use the sed -r option for extended regular expressions? Anyway, this sed vomit is just a quick hack to make the source compile without changing it. Once we have a real official open-source repository we should make the assembly code easier to maintain for both IAR and gcc, for instance using #ifdefs or macros.
There is actually a missing step 
We do not have anything that wraps the compiled binary into a dfuse file. However, if you have my latest dfu-util code, you can download the raw binary file “dso.bin” as long as you know the address where it should be loaded:
src/dfu-util --dfuse $((0x0800c000)) -a 0 -D dso.binIn general, to see where the code should be loaded if you don’t know the source code, you can find it in the hex file:
:10C000000050002021150108611501086115010883[/code]
the first :02 line is an address offset directive, the 0800 in there is the MSB (and the last byte on a line is always a checksum). On the normal
:10 data lines, the first two bytes form the address LSB, C000. Or look at the s19 file, which have the whole address on each line:
codeS00A000064736F2E733139A4
S3150800C0000050002021150108611501086115010875[/code]
The data line S3 starts with the number of bytes, 15, then the address, before the data.
Or simply run “objdump -s dso.hex” which will list all addresses. You can also use a tool like srec_info to decrypt the s19 file.
Notice also that the first bytes in a STM32 binary is almost always the interrupt vector, starting with stack address and the reset address. So in the example above, the stack pointer is 0x20005000 (in RAM) and the code starts running at 0x08011521.
And that makes me start thinking why the recompiled APP does not work with the closed-source LIB. Maybe the LIB has hardcoded an entry point in the APP and is not going via the reset vector?
Note also that the code really starts at 0x08011520, if you want to disassemble it. The +1 is a way to tell the processor this is thumb code. I am not sure if this is correct everywhere. This is also the reason for the .thumb directives in the assembly code.
I’m planning to write some Python script to do that; for now, I’ve been dissecting the dfu files for 2.5e and 3.1 BenF firmwares, in order to grasp the format better:
File: "./seeed/DS0201_LIB_V2.5.dfu"
DfuSe v1, image size: 20079, targets: 1
Target 0, alt setting: 0, name: "ST...", size: 19794, elements: 2
0, address: 0x08004000, size: 14634
1, address: 0x0800792c, size: 5144
usb: 0483:0000, device: 0x0000, dfu: 0x011a, UFD, 16, 0x42c9c2e9
File: "./seeed/DSO nano APP v2.5e.dfu"
DfuSe v1, image size: 26453, targets: 1
Target 0, alt setting: 0, name: "ST...", size: 26168, elements: 1
0, address: 0x0800c000, size: 26160
usb: 0483:0000, device: 0x0000, dfu: 0x011a, UFD, 16, 0x78f39025
File: "./BenF/DSO BenF LIB v3.01.dfu"
DfuSe v1, image size: 14009, targets: 1
Target 0, alt setting: 0, name: "ST...", size: 13724, elements: 1
0, address: 0x08004000, size: 13716
usb: 0483:0000, device: 0x0000, dfu: 0x011a, UFD, 16, 0x36d848a4
File: "./BenF/DSO BenF APP v3.10.dfu"
DfuSe v1, image size: 21172, targets: 1
Target 0, alt setting: 0, name: "ST...", size: 20887, elements: 1
0, address: 0x0800c000, size: 20879
usb: 0483:0000, device: 0x0000, dfu: 0x011a, UFD, 16, 0x02e4298dThe simplistic parser I wrote is attached.
Antonio
dfu.zip (880 Bytes)
Okay, I was guessing that is what it was, but that is not a v7 pattern, which is when I learned sed. The -r flag does not exist in the Mac version. These new sets of patterns are not found in bsd derived systems. I understand it is just a hack at this point. So I am debating how to best handle this. Match eol, which would work in this file for the case in question? or should I put [ ,.\t$]. At the moment I would just go for $ as it will handle this file and that is all that is needed.
Edit: Actually I had to go back to just END, but ENDING does not appear in that file so that is okay. Matching on $ doesn’t work because there is a dos line termination. This does not seem worth the effort.
Hmm I tried that and it does the upload, but no joy. It acts as if the upgrade was only half done. Which I am suspecting is the case. How do I build the lib portion and upload that piece too? Thank you for taking the time to answer my noob questions. I am guessing I read that we don’t have to have two pieces any more as we no longer have them, when in fact the current build still uses both pieces.
I think you maybe have not read the whole thread to have the whole picture of where we stand. Recompiling the 2.5 APP with gcc and running it with the closed-source binary 2.5 LIB does not work (yet). I am not sure I want to spend time on getting it to work either, since I consider a closed-source library a dead end. To see that we can do the whole build with gcc, I would rather try the 1.1 sources, where everything is open-source and should be easier to have working. But living in the hope that we would soon see an open-source 3.02 version or so, I haven’t looked much at the old code. Anyway, there has been enough to do with dfu-util and dfuse, which is a prerequisite for me working on this on Linux.
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.