antoinealb
commented
5 years ago Do we start at 0x8000 0000 because 0x6000 0000 and 0x7000 0000 are for the bootloader ?
I think you mixed up 0x8000 0000 and 0x0800 0000. The table you shown here is from the register space (the device peripherals basically), whereas we are interested in memory. See below for details. We put the bootloader at the start of the memory, then two sectors of config, then the application. You can find our memory layout in the linker script. The TEXT section means "the program", here it is the bootloader.
The arg -d take "0483:df11", i can't find it on the datasheet of MC, where does it come from ?
This is the Vendor ID and Product ID of an STM32 in bootloader mode. Each device manufactured has such IDs and they must be unique. You can find them by running lsusb under Linux.
This pull request enables flashing of STM32F4 based boards in a reasonable time. It does so by avoiding erasing several time the same "big" sector which is expensive to do on this platform. See commits for implementation details.
The alternative would have been to make the client aware of the more complex sector layout to avoid erasing unnecessary sectors. However this meant either more client-side configuration (commandline flags) to indicate that this is an STM32F4 or a discovery step (for example by reading the board config). In the end I feel that "hacking" the interface leads to a simpler system.
Flashing time with this path is about 30s for the UWB firmware, which is reasonable enough to allow in system flashing of the board.
As a bonus I added a blink pattern to identify the boards which boot in bootloader mode.
Fixes #81