Debugging bootloader + app: How to get a CRC header to the target, too?

[SKled.1]

I have a workspace in CubeIDE that has two STM32F0 projects: A bootloader and an app.

To be able to debug both, bootloader, and then jumping through to the app code, I made an additional Debug Configuration where I added the source folder, and the symbol file of the application.

In principle, this works, and I can jump from bootloader right through my app code at source level (to land in the hardfault handler, see other thread ;) But it's in the app nonetheless)

But only if I comment out my bootloader line "if (check_app_CRC()) ...".

Because what I do is, as a post build step of the application, run a custom program I wrote to generate a header with e.g. CRC for the app.

This is a separate file, and for update via my bootloader, I just concatenate header + app binary.

But for debugging, and loading everything onto the target flash:

Now, I can't add that custom header blob file to CubeIDE (Eclipse)'s Startup / Load Image and Symbols tab - as that requires an ELF file.

I guess since an ELF file really is for programs I can't fake one that contains only my special binary data blob, right?

Also, the header is smaller than 1 flash sector, so I'm not even sure the IDE would do it right, flashing one after another, without earsing the first again...

I have thought about whether one could somehow make the header a part of the application firmware image itself - then this problem would just go away.

But I would need to execute my CRC & info compilation programlet over the basically completely linked executable and then the linker would somehow have to integrate that header still.

My GNU linker chops are nowhere near the required level here.

Perhaps one might just reserve one empty region in the app image as some array at a fixed location, and then have my programlet write the CRC etc data over that part of the image file, calculating the CRC over all but that region.

It does seem kinda hacky.

What ways are there to tackle this? I guess there is some tried & proven standard way to do it?

[MM..1]

Sorry, but your idea is on most cortex mcu completely bad. Interrupt vector table need be alligned to memory boundary and not shifted with any header.

Maybe when you copy to RAM alligned to zero, this work, but this code is hard to check.

Try change placement for crc to footer...

[SKled.1]

Yeah I do copy it to RAM, on the M0 I need to.

Footer is a bit difficult - I don't know the size of the app firmware. So it will not be static, and I don't know where to look for the CRC. I could put it at the very end of the flash always, but if I want to flash that as an image, it means you'd flash the whole flash all the time even if the firmware is much smaller.

Or am I overlooking something here?

[SKled.1]

Btw, to what kind of block size does this need to be aligned to for MCUs where I can sue VTOR? I don't recall seeing a restriction like that.

But I guess I could, for those MCUs, just make the header as big as one such block, so the vector table will be aligned after that. Depending on block size, perhaps a small loss.

[MM..1]

Try read vector table (st.com)

[Tesla DeLorean]

As object files go the .ELF isn't particularly complex, shouldn't be that difficult to add some CRC or other signing to the file in a post-linker step. Don that kind of thing here for packaging tools that can sign, compress and crypt.

In terms of debugging, or flagging a debug image, one could perhaps mark a specific device, use its unique code, or use an unused vector to alter behaviour.