Uploading using st-flash removes access to bootloader

[vicgwee]

I did the following steps:

1. Flash https://github.com/devanlai/dapboot/releases/download/v1.11/highboot-v1.11-stlink-128.bin to my STM32F103 using st-flash
2. Use 'Firmware Download' on https://devanlai.github.io/webdfu/dfu-util/ for my own program
3. Enter bootloader mode from my program (which places the 'BOOT' code in the RTC backup registers)
4. Use the website's 'Firmware Upload' to obtain the firmware.bin file
5. Flash the firmware.bin using st-flash

After the following steps, I cannot enter bootloader mode from my program. I used st-flash read to get the .bin file that is now on the STM32, and it's identical to the firmware.bin file above.

[devanlai]

Hi @vicgwee, perhaps I should have documented the highboot bootloader a little better.

When it writes the application into flash, it modifies the contents of the vector table in the first flash sector so that the reset address points to the bootloader instead of the application. This ensures that the bootloader is the first program to run. When the bootloader decides to boot the application, it then jumps to the application's reset address which is stored in an unused slot in the vector table.

The bootloader attempts to appear totally transparent compared to if there were no bootloader installed, so if you perform a firmware upload, you would expect to get back the same firmware that you put in, which means it does not include the modified vector table or the bootloader itself, so if you flash that image with st-flash, it's not any different than if you were to just flash the original image with st-flash.

Could you elaborate a bit on what you're trying to accomplish? Did you want to create single flashable image that includes the bootloader and the application together? If so, you could potentially do this with a bit of careful linker script construction or by using st-flash to read out the complete flash contents directly rather than using the dfu upload capability to read back the firmware.

[vicgwee]

Hi @devanlai, thanks for the quick response! I see, the bootloader's 'totally transparent' feature has worked very well :) I was quite surprised when the vector tables were the same!

Yes, I would like my build tool to create a single flashable image so that whenever I use my ST-Link, I don't have to re-flash the bootloader and then download my program using the bootloader. Would you recommend using the highboot or the standard bootloader for that?

EDIT: I took a look at some of the history of highboot and saw it was mentioned in #23 that

The high-memory bootloader has a brief window of danger when rewriting the mixed application/bootloader vector table where it can brick itself if it is reset or power is lost in the middle of the middle of erasing / writing the vector table.

Since that is the case, I would prefer to use the standard bootloader instead!

[devanlai]

There are a few different ways to generate a combined image.

If you're generating a bin file, it's an exercise in taking the bootloader bin file and padding it until the size equals to the application offset (which is 8KiB for the standard dapboot image). If you don't mind padding with zeroes (which means the padding will be written into the flash instead of just erasing flash to 0xFF), there are some shell-script friendly ways to do so with dd, e.g: How to pad a file to a desired size.
For padding with 0xFF, it's not as straightforward to use common shell tools so I just use a small Python script.

If you're generating a hex file, there are utilities that can handle merging hex files together, e.g: Merging 2 hex files.