2019-09-04 05:24 AM
I'm planning to use the built-in ROM bootloader in an STM32F4 chip for DFU uploads and having a hard time figuring out how it works exactly (in particular what pins it initializes at what moment in the boot process, and what I need to do externally to prevent it from going into e.g. SPI or UART mode). The documentation is missing some details (and experiments also give me puzzling results), so I'm looking for some more specific insight in the workings of this bootloader, which would be perfectly solved by looking at the source code.
I've read some earlier related posts, and I suspect that the sources are not currently available, but maybe someone at ST will see this as a request to change that? I would think there will not be any secrets in their bootloader sources, but it would make the bootloaders (and thus their hardware platform) a lot more usable.
Note that I realize that the ROM bootloader is not perfect and might not be a good basis for a custom bootloader, but that is not my goal (my goal is to understand and use the ROM bootloader). I also realize that the bootloader is in ROM and cannot be modified.
I also realize that using a custom bootloader in flash is also a commonly used option, but I'd prefer to use the builtin one (since that can certainly not be erased, and simplifies production).
I noticed @Community member mentioning in this topic that you can read back the compiled bootloader from ROM and disassemble that, which would also be helpful (but a lot harder to read, of course). He mentions his "own annotated listings", but without a link it seems. I wonder if there is any repository of such listings or dumps? If not, anyone aware of some tutorial on how to generate them? Though I guess it's a matter of dumping memory through SWD and then disassembling with something like `objdump`?
2019-09-04 05:33 AM
> Though I guess it's a matter of dumping memory through SWD and then disassembling with something like `objdump`?
Instead of objdump it's better to use a proper reversing tool like Radare2 (with Cutter GUI if you would like), or Ghidra. They can even help to get a decompiled C code (not the original, of course). Try to get help in reverse engineering communities.
IANAL, but before actually using the disassembled/decompiled code of ST's proprietary binaries I advise you to explore the legality of doing that.
2019-09-04 06:17 AM
You present no good reason to decompile. System bootloader is described in AN2606 and there are a lot of programs that use DFU successful with STM32, to name dfu-utils. You put some test for some magic in some RAM that is not yet erased and if you see that magic, erase the magic and jump to the bootloader. In your user program, have some command to set that magic and to a warm reset. That is all.
2019-09-04 07:15 AM
> Instead of objdump it's better to use a proper reversing tool like Radare2 (with Cutter GUI if you would like), or Ghidra.
Thanks, I'll have a look at those.
> You present no good reason to decompile. System bootloader is described in AN2606 and there are a lot of programs that use DFU successful with STM32, to name dfu-utils.
Ok, let me make some of the questions I have (and which I cannot find answered in AN2606) explicit. I'm looking at the STM32F401xE
I guess that clarifying these things in the official docs would also be great and a lot easier than having to read the source code. However, being able to read the source code would make it possible to also answer these questions (and more, these are just the things that I remembered wondering and needing recently, I can imagine that for different usecases, other details can be important).
Does this help clarify the background of my question?
> and there are a lot of programs that use DFU successful with STM32, to name dfu-utils. You put some test for some magic in some RAM that is not yet erased and if you see that magic, erase the magic and jump to the bootloader. In your user program, have some command to set that magic and to a warm reset. That is all.
That part is actually already clear, I've made the "warm reset" part and dfu-utils upload work. However, I need to make this reliable and ensure the bootloader 1) does not jump into e.g. SPI mode accidentally, breaking USB uploads and 2) does not put some pins in output mode that would cause a short-circuit or overcurrent condition. Both of these I can fix by careful pin selection and PCB design, but then I do need to know what the constraints are exactly.
2019-09-04 07:55 AM
To more completely quote myself, I said "Created my own annotated listings here", which basically means I did it myself, it took effort and it is work product. Publishing other people's work tends to get into a more complex area, whereas interfacing, vulnerability testing, and due-diligence tend to be broadly acceptable use cases.
One could perhaps use objdump or fromelf, but these are a bit like Butter Knives, I use instruments which are a lot sharper, which I fashioned myself. The use of simpler/prolific tools tends to be improved significantly with post-processing to reformat to a preferred style with flow and interaction paths identified.
I can also sight-read code, so it doesn't matter much if it is C, Assembler or whatever.
2019-09-04 08:02 AM
I don't know, the documentation from ST is seriously deficient and not up to date. There's almost always a good reason to understand what the micro-controller is doing in any given circumstances.
The OP already indicated that it is the undocumented and nuanced behaviour that is problematic. Things like post-reset pin sensitivity and control flow, which can render a design difficult to program.
2019-09-04 08:19 AM
Did you have a look at the Bootloader selection flows presented in AN2606. It also clearly tells what facilities are involved. But if you want full controll over the bootloader, write your own or look on the web for existing ones.
2019-09-04 08:34 AM
> To more completely quote myself, I said "Created my own annotated listings here", which basically means I did it myself, it took effort and it is work product.
That makes sense. I think I was hoping that "here" in your sentence was supposed to be a link, but reading it as "here in-house" also makes sense. I understand that publishing that might not be trivial. Thanks for you addition, though :)
2019-09-04 08:37 AM
Yeah, I have looked at the selection flow, but it is lacking in detail (as indicated in my reply above), and also does not paint the whole picture (it does not detail when pins are initialized, for example). Also, I am not looking for full control over the bootloader, I'm looking the understand the builtin one so I can use it without problems later on.
2019-09-04 09:05 AM
While AN2606 does provide some level of detail, I find it to be lacking and incomplete. It really doesn't help to identify where all the land mines are buried, and stuff in general is not fully disclosed and subject to change.
The more pins/functionality they add, the more difficult it is to avoid clashing with that at a board level, especially with the lack of alternate-function mapping abilities of the part. Kind of would like to have USART1 and USART3 attached to things that might squawk at startup.
The behaviour of new devices to test and jump into FLASH applications, being particularly unhelpful. More considered ROM Boot Loaders provide multiple entry points and APIs. In such a scenario a boot could be directed to use only a specific interface/pins.