Flashing Nucleo-F439ZI board takes a long time about swift-embedded HOT 2 CLOSED

Hey @ole,

Happy to hear from you that the little demo worked!

1. That is expected (unfortunately). I am currently not aware of any way to easily speed up the flashing process on this board (I haven't looked into it properly, though). I might have some ideas on how to improve this, so I hope this will get better in the future – I agree it's annoying.

2. Good observation. Yes, the file in the build folder is an ELF file and it contains debug symbols (and more). ELF files are organized into segments (those define what gets loaded to memory) and to sections. You can inspect them using arm-none-eabi-readelf (for example arm-none-eabi-readelf -S <elffile> prints out all the sections in the file). There are more tools, for example arm-none-eabi-size <elffile> will print out the size your program will occupy in FLASH (.text + .data).

arm-none-eabi-* tools are part of the toolchain – you can use them by prefixing the call with xcrun. For example: xcrun arm-none-eabi-size <elffile>

Btw, after I read your message, I quickly checked the code size of Blinky and HelloWorld applications built by the published pre-built toolchain. It seems that the code size is currently higher than expected (HelloWorld is about 1.4 MB instead of 1.1 MB). This is something I will have to look into!

And one more thing. A friend found out that the published toolchain has issues when building some of the other demos requiring Glibc. I already have a fix for that and I am going to release a new toolchain this weekend ☺️

from swift-embedded.

Thanks, that's very helpful. I was looking for a way to flash the board that didn't involve GDB, so here's what I tried to remove the debug symbols from the binary. This may be wrong because I'm not very familiar with binary segments and the associated tools, but this seems to be working for me:

1. Perform a build:

   cross build

2. Strip debug symbols from binary:

   xcrun arm-none-eabi-strip --strip-all -o .build/debug/Blinky-stripped .build/debug/Blinky

   I don't know if this strips all unneeded stuff from the binary. On my machine, the resulting Blinky binary is 1.7 MB (down from 3.7 MB). I could probably also get SwiftPM not to generate the debug symbols in the first place, but I don't want to mess with the build process if I can help it.

3. Flash the stripped binary to the board directly with OpenOCD and exit:

   openocd -f board/st_nucleo_f4.cfg -c 'init; reset; halt; flash write_image erase .build/debug/Blinky-stripped; reset; exit'

I find this process more convenient than uploading the binary with GDB because I think it's easier to automate this step in a script this way. But maybe that's just because I'm unfamiliar with GDB (e.g. I couldn't figure out how I could automatically quit GDB after flashing but keep the program on the board running).

Of course, this method doesn't put you in a debugging session, but most of the time that's not what I want anyway.

Unfortunately, it takes the same amount of time as GDB, or maybe even slightly longer (42 seconds on my machine).

from swift-embedded.