STM32CubeIDE and STM32CubeProgrammer produce different results when flashing .elf files

[BPaik]

STM32CubeIDE and STM32CubeProgrammer exhibit different behavior when flashing an MCU. Specifically, "gaps" in memory sections described in the linker script are flashed to a device with 0xFFFF when using the IDE and 0x0000 when using the programmer. For example, this will be the case for the few addresses after ".isr_vector", but before ".text".

I noticed this when programming an STM32G474RE to perform a CRC on its own flash on startup as part of data integrity check. I appeared to get different CRC results depending on whether I had programmed the unit through the IDE or the CubeProgrammer (despite using the same .elf file, ST link, and PCB). Ideally, I think STM32CubeIDE should probably be updated to match the behavior of STM32CubeProgrammer for consistency.

This was done using STM32CubeIDE version 1.13.0, STM32CubeProgrammer version 2.14.0, and STLinkV2.

[TDK]

Doesn't STM32CubeIDE use STM32CubeProgrammer to do the programming? Sure seems like it based on the "Console" tab:

Debugger connected
Waiting for debugger connection...
      -------------------------------------------------------------------
                       STM32CubeProgrammer v2.13.0                  
      -------------------------------------------------------------------



Log output file:   C:\Users\...\AppData\Local\Temp\STM32CubeProgrammer_a36740.log
ST-LINK SN  : ...
ST-LINK FW  : V3J9M3
Board       : STLINK-V3MINI
Voltage     : 3.18V
SWD freq    : 8000 KHz
Connect mode: Under Reset
Reset mode  : Hardware reset
Device ID   : 0x431
Revision ID : Rev A
Device name : STM32F411xC/E
Flash size  : 512 KBytes
Device type : MCU
Device CPU  : Cortex-M4
BL Version  : 0xD0



Memory Programming ...
Opening and parsing file: ST-LINK_GDB_server_a36740.srec
  File          : ST-LINK_GDB_server_a36740.srec
  Size          : 52.64 KB 
  Address       : 0x08000000 


Erasing memory corresponding to segment 0:
Erasing internal memory sectors [0 3]
Download in Progress:


File download complete
Time elapsed during download operation: 00:00:01.268

Maybe a difference in how the ELF is generated vs whatever SREC is generated when you hit the play button.

[BPaik]

Hmm, I didn't notice that before. That makes this even weirder. If you or anyone else want to check this out, program a board with the IDE, then open STM32CubeProgrammer, go to "Memory and File edition", click on the new tab button, and select "Compare memory with file". A popup will appear with a warning that a difference has been detected, and you can scroll to the corresponding row to see the device has 0xFFFF and the .elf file has 0x0000. If you reprogram the board through STM32CubeProgrammer,  and compare the memory with the same .elf file, the locations that were previously 0xFFFF will now be 0x0000, and a popup will appear saying "no differences were detected".

I just repeated this test with an L476RG and it exhibited the same behavior.

[TDK]

If I verify with a HEX file, no differences are detected. If I verify with an ELF file, I get the behavior you describe. So the HEX files has 0xFF's and the ELF has 0's. At least, that's what is displayed in STM32CubeProgrammer when you open them.

If I open the HEX file itself, I can see that the data addresses in question aren't in the HEX file at all. For me, 0x08000198 is the first mismatched memory address, and it's not a part of the program:

:1001800000000000CD260008000000000000000074
:08019000CD260008CD26000871
:1001A00010B5054C237833B9044B13B10448AFF3B1

But it displays in STM32CubeProgrammer like it is, sort of. It's grayed out, but if I do "Verify", it is included in the part of the memory that is checked.

  22:43:54 : Error: Data mismatch found at address  0x08000198 (byte = 0xEF instead of 0xFF)

So at least one bug is:

• Sections of memory that are not part of the HEX file are still checked during the "Verify" check.

But regardless, flashing the HEX file in STM32CubeProgrammer (rather than the ELF) will avoid this issue.

[TDK]

Those bytes are not in the ELF file either.

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .isr_vector       PROGBITS        08000000 010000 000198 00   A  0   0  1
  [ 2] .text             PROGBITS        080001a0 0101a0 00b908 00  AX  0   0 16

 I wonder why there is an 8-byte gap between .isr_vector and .text. There's nothing in the linker to force alignment to 16-bytes.

You can eliminate the problem by changing some  ". = ALIGN(4);" to " . = ALIGN(16);" in your linker file. No doubt there are other solutions as well, and no doubt others have run into this before as well.

This is a similar issue but not quite the same:

https://mcuoneclipse.com/2014/06/23/filling-unused-memory-with-the-gnu-linker/

[BPaik]

Thanks for the additional insights! To summarize everything so far, the memory gaps between sections are not defined in the .elf or .hex files. However, STM32CubeProgrammer sets these undefined sections differently (to 0 or 1) depending on whether an .elf or .hex file was loaded. Additionally, STM32CubeIDE appears to flash the MCU with 1's (like a .hex file in STM32CubeProgrammer), despite the fact that the launch configuration is using the .elf file. I would also summarize the bug list as follows:

1. STM32CubeProgrammer should not write to addresses not specified in the .hex/.elf files. Since flash memory after erasing is 0xFF, STM32CubeProgrammer should not arbitrarily write 0x00 to these locations. This is the most critical issue for me since it causes my ROM CRC to produce different results depending on whether a unit was programmed from STM32CubeIDE, STM32CubeProgrammer, a .elf file, or a .hex file.

2. The verify feature in STM32CubeProgrammer compares undefined memory locations in the .elf/.hex files.

3. This one is more of a curiosity than a bug, but I would like to know why STM32CubeProgrammer behaves differently when be called through STM32CubeIDE versus the standalone application.

I'm going to leave this thread open (despite the provided workarounds) until I get a response/resolution from ST.