BIN vs. ELF File Uploads - CRC Mismatch

JR2963 · ‎2024-08-07

Hi,

I'm currently trying to figure out how to properly upload a program to an STM32. I'm using VS Code with the STM32 Extension. I've noticed an issue where uploading the program using either a .elf file or a .bin file results in different values in a specific location in the FLASH memory. In one case, I get 0xFF and in the other 0x00. Although this doesn't seem to affect the program's execution, it causes a problem when calculating CRC for program integrity, as I get different results.

Additionally, if I upload the program using the Debugging mode directly in VSCode, it again writes 0xFF at that location instead of 0x00.

I'm calculating the CRC using a Python script, which reads from the generated .bin file. This CRC value is then uploaded alongside the program into the flash memory, and I check it to ensure it matches the CRC calculated by the script. The 4-byte area where the discrepancy occurs is not at the end of the program but relatively close to the beginning.

I'm puzzled because I calculate the CRC from the .bin file, yet paradoxically, if I then upload the .bin file to flash, the CRC check fails. However, if I upload the .elf file, the CRC check passes.

This is causing significant issues for me, as I rely on CRC checks for code integrity, and the mismatches are problematic.

Does anyone have any insights or suggestions on how to resolve this discrepancy in memory values between .elf and .bin uploads?

Andrew Neil · ‎2024-08-07

@JR2963 wrote:
In one case, I get 0xFF and in the other 0x00.

An ELF file can be "sparse" (ie, can have gaps where nothing is programmed), so can leave unprogrammed areas - they would stay at the erased state of FF.

A BIN can't have gaps.

When creating a BIN, there's usually an option for what value goes in as a default - change it to FF ?

JR2963 · ‎2024-08-08

Thank you, but I think problem is somewhere else:

Im having trouble with uploading programs from VSCode to an STM32 microcontroller. In my code, there is a 4-byte section that remains unused, likely due to memory alignment. When I generate a .bin or .elf file, I see 0x00000000 at that location (for example, when I open the .bin file in STM32CubeProgrammer).

If I upload the .elf file using CubeProgrammer and then read it back from memory, I again see 0x00000000 at that spot. However, if I upload the program using the debug mode in VSCode, I see 0xFFFFFFFF at the same location when I read it back.

It seems that during the debugging process, this area is "skipped," and the flash retains 0xFFFFFFFF because the flash must have been erased beforehand.

I'm not sure how to resolve this issue. The problem arises because I calculate the CRC over this memory area, and the CRC results differ when the values are sometimes 0x00000000 and other times 0xFFFFFFFF. Does anyone know how to solve this problem?