How to configure flash tool, debugger

[embitz]

My code targets an STM32L051 processor and consists of two separate projects: a bootloader and application firmware. 

The bootloader serves several purposes, including authenticating the application firmware which is digitally signed.

From EmBitz, I can build, flash, and debug the bootloader with no problem.  The bootloader is located at the start of flash (0x08000000).

The application firmware has a custom linker script to locate the application code at a different offset in flash 
(0x08003000).  Post-build steps generate a header containing meta-data and a digital signature used by the
bootloader to authenticate the application firmware.  The header is pre-pended to the binary application
firmware image generated by EmBitz to yield a final signed hex file.  

I'm doing exactly the same with several IoT projects of mine. I use an external tool, invoked after build by EB, to put the image length in the application image and to sign it with checksums.

This all works: I can load this signed hex file into the target using stm32cubeprogrammer and it is
then authenticated and launched by the bootloader when the target is reset. However, I can't figure
out how to configure the IDE to load the post-processed .hex file (instead of whatever it is loading
by default that currently overwrites the bootloader).  So what I'm looking for is how to configure
the flash tool so that when I run Flash->Flash Target  from within EmBitz, it will flash the target
with myApplication_signed.hex  instead of whatever it does by default (which overwrites the bootloader).

If anyone knows how to do this, I'd appreciate your guidance; thanks!

P.S. development environment: EmBitz 2.41 running on Windows 11

I use it as follows:

Application development

I have several build targets. Debug, Release and Boot. The Debug and Release targets are just using a standard positioned linker script to work as standalone application. The debug uses the special booted linker script with location sectors behind the bootloader and this target will also call the external program after build to add the length field to the image and add signatures. That same tool also can create different types of output such as Intel HEX or binary (used for upload OTA).

So normal development is done with Debug and Release (check performance).

Bootloader development

During bootloader development I flash the signed HEX file created during application development just from the windows explorer  menu. I start debugging the bootloader with EBlink caching turned off because we have a code (flash) modifying application to debug. Now I can just debug the bootloader because EBlink won't clear the sectors of the application area. It will only clear the sectors which are affected by the bootloader code.

Normally once the bootloader is released we don't need to test this again. It is prepended to the HEX application file for production and in the field only the binary signed application image is used for updates. The last time I touched or debugged our bootloader code was more than 2 years ago.

The bootloader is generic by using fields in the application header to differentiate  not only on firmware version but also device type so that only the images of the correct device type will be flashed inside application area.

Will this help you?