STM32CubeProgrammer SREC behaviour

[Mvan .31]

Hi,

I recently stumbled on a issue.

For a project we developed a bootloader which checks the programs CRC if it matches and halts if not. The CRC is calculated after linking and is placed in front of the application.

I found out that there is a difference between the compiled binary (.bin) file and the programmed target when programming through STM32CubeIDE. This makes the CRC calculation fail.

The difference seems to be in the blank (unprogrammed) areas.

STM32CubeIDE uses STM32CubeProgrammer CLI to program an SREC format file.

This SREC format may contain areas which aren't programmed.

ARM GCC converts an ELF to binary and fills unused areas with 0x00.

STM32CubeProgrammer 'fills' unused areas with 0xFF.

Attached are simple examples.

We have an reproduce.srec which writes the ASCII 'test' multiple times. Address 3D, 3E and 3F are not programmed.

When converting reproduce.srec to gccoutput.bin with ARM GCC:

arm-none-eabi-objcopy.exe --input-target=srec --output-target=binary .\reproduce.srec .\reproduce.bin

This results in 3D, 3E and 3F filled with 0x00.

I than programmed an STM32 with:

STM32_Programmer_CLI.exe --connect port=SWD mode=UR reset=hwRst --download "reproduce.srec" --verify --quietmode

I then dumped the programmed target with ST-Link Utility (contents are in programmed.bin).

The result is that 3D, 3E and 3F are 0xFF.

This makes calculating an CRC on the host difficult because the programmed target doesn't match our compiled binary.

Is there a way to solve this issue by either an STM32CubeIDE configuration or is this a bug?

Thanks.

Melvin

[Tesla DeLorean]

0xFF is the standard for unwritten EPROM ​and FLASH, and typically used as the fill byte for slack space. Been so for many decades.

When you process file to generate CRC, output a normalize HEX file, filling in the slack​ bytes.

[Mvan .31 · Accepted solution]

Yes I know. A bit can only go low once before needing an erase again.

I fixed the issue by using

arm-none-eabi-objcopy.exe  --gap-fill 0xFF

That makes the bin the same as the actual FLASH.

Thanks anyway!:grinning_face: