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.
