For optimized code, BIN file does not match FLASH contents.

[RGods.1]

I'm working with STM32F405, not sure if I'm asking question in right place, or if it matters... I'm working on a self-test for CRC FLASH (can't use libraries, just basic code). I notice that, for non-optimized code, the generated BIN file matches FLASH, but not for optimized code. Specifically:

1) In both cases, BIN file and FLASH are identical up to the end (size of) the BIN file.

2) In non-optimized case, the remaining FLASH is empty (assuming erase before program). Thus, to generate correct CRC on PC side (over BIN file), I'm just padding the BIN file with 0xFF bytes up to FLASH size.

3) In optimized case, the remaining FLASH (past end of original BIN) has extra data in it.

Is this expected? Can anyone explain what these extra bytes do? Or provide a link to some reading material on the topic? I can work around this, in my case, by stopping CRC check once only the BIN contents are read from FLASH, but prefer not to require BIN file size externally. Is there anything in the BIN image that can be parsed out at run time that implies the original BIN size?

For reference, I'm using SystemWorkbench, GCC/G++, -O2 optimization.

Thanks in advance!

[Tesla DeLorean]

>>3) In optimized case, the remaining FLASH (past end of original BIN) has extra data in it. Is this expected? Can anyone explain what these extra bytes do?

I wouldn't expect it, but you might not be determining the length properly, and the extra data is initialization for the statics.

>> Is there anything in the BIN image that can be parsed out at run time that implies the original BIN size?

You can certainly put symbols reflecting the length of the image into things like unused vectors in the vector table. I've demonstrated that in other posts relating to CRC signing of firmware images.

You can compute length, and create symbols in the linker script. Metadata is also something you can pull from the .ELF file.

[Tesla DeLorean]

The search on this forum is still SH*T, here using BING to find my own posts

https://community.st.com/s/question/0D50X0000Awa25qSQA/generated-binary-file-size-in-stm32l4

[RGods.1]

Update: problem solved. Apologies: my tool was not actually erasing FLASH as I thought and so observed data was just leftover from previous image. Thank you clive1 for your rapid and helpful feedback!