Reputation: 37
I am working with two distinct Platformio projects for an stm32f4 target: a bootloader and an application. Eventually, the bootloader should be able to update the application code over the network but for now I want to structure the build system such that I can conveniently flash the chip using a programmer for development.
I was able to get the two parts to execute correctly by creating separate .elf images and flashing the application image followed by the bootloader image manually using OpenOCD. However, it would only run if I flashed the application first and then manually erased and wrote the bootloader sector using OpenOCD's flash erase_sector
and flash write_image
commands.
My goal is to have a flexible setup that allows me to flash the MCU conveniently and to generate separate binaries in the future when updates over the network come into play.
I have some ideas about how to proceed but I am unsure what the best way forward is:
a) keep building separate images and look into objcopy/objdump
to slice and merge .elf files to be able to create a combined image which should be easy to upload onto the target MCU, or
b) work with scripting PlatformIO such that I link a combined image from object files in the two projects' .pio/build
directories.
I was also wondering whether I could work within the PlatformIO frame instead of scripting around two entirely separate projects.
Any input is appreciated.
Upvotes: 0
Views: 113
Reputation: 37
I've figured out a way that works with PlatformIO and is convenient:
arm-none-eabi-objcopy -O binary
(I've included this as a post action with PlatformIO).openocd
. The important part here is to upload the images as binary and not as .elf. This requires providing the addresses in flash:openocd <target-specifics copied from Platformio> --command 'program { <path/to/bootloader.bin> 0x08000000 verify' --command 'program {path/to/app.bin} 0x08020000 verify' --command reset --command shutdown
This preserves debug symbols and works with the debugger in VSCode.
Upvotes: 1