CRC mismatch between STM32CubeProgrammer CLI and STM32F4 hardware CRC in X-Cube-ClassBF4

[NafiurRahman]

I’m using the Class B Flash self‑test on an STM32F407. My post‑build step injects CRCs with:

STM32_Programmer_CLI -sl Firmware.elf 0x08000000 0x08100000 0x400

I Inspected the CRC of the first section via

arm-none-eabi-objdump -s -j "CRCs area" Firmware.elf | head -n2

After this I re‑computed the CRC to verify which method it used. I used srec_cat and I used the following method:

arm-none-eabi-objcopy -O binary Firmware.elf full_flash.bin
dd if=full_flash.bin of=region.bin bs=1 count=1024

srec_cat region.bin -Binary \
  -CRC32_Little_Endian 0x400 \
  -crop 0x400 0x404 \
  -output - -binary \
| hexdump -e '1/4 "CRC32: 0x%08X\n"'

After this I figured out that the CRC checksum stored in the memory for the first 0x400 section matched with the srec_cat output.

However at runtime, when STL_SCH_RunFlashTM() (compiled with both -DSTL_SW_CRC and without it) computes the CRC over the exact same 0x400 bytes which is different than the expected value. As a result, StlFlashStatus returns STL_Failed I end up in the FailSafe_Handler with error code 13. 

Key finding:
The built‑in STM32F4 CRC peripheral has no bit reflections, initial bit is 0xFFFFFFFF, no final XOR. Whereas -CRC32_Little_endian (same as STM_Programmer_CLI) uses reflected input and output, consistent with the standard CRC-32 definition. A final XOR of 0xFFFFFFFF is applied always injects the reflected CRC32 (input+output bit‑reversal), so the two algorithms cannot match on F4 hardware.

The whole method of CRC calculation seems unusual to me. Maybe it's my lack of knowledge too. Any guidance or best‑practice example for aligning the runtime CRC with the CLI‑injected table on STM32F4 would be greatly appreciated.

[NafiurRahman]

Hi @giubacchio , unfortunately no. I had a working 2.2.0 version so didn’t investigate too much time on this. 

[giubacchio]

Hello @NafiurRahman,
could you clarify what you mean by a working 2.2.0 version? Thank you very much in advance for any additional information you can share.

I performed some additional tests: in a few rare cases the generated executable reports an STL_PASSED result when calling the STL_SCH_RunFlashTM() function on certain specific sectors. This makes me think the issue might be related to padding or incorrect alignment in the produced binary code.
However, I programmed the STM32H5 using STM32CubeProgrammer - as suggested in this same topic together with this and that - while keeping the alignment settings from the official ST linker script.

Since I am trying to run the official ST Functional Safety Package tests, I believe it would be valuable for ST to provide some clarification on how to properly address this issue.
@Petr Sladecek @Amel NASRI: any help would be greatly appreciated.

Thank you,
Giulio