Programming with STM32CubeProgrammer is fine; STM32CubeIDE gives wrong results

[Pkemarco]

Split from STM32CubeIDE and STM32CubeProgrammer produce different results when flashing .elf files.

---

Hello everyone, and sorry to dig up this thread (as it's been left open).

We're also experiencing this issue, and it's impacting the CRC calculation due to a few 0x00 bytes that, for some unknown reason, are 0xff in Flash (first image below), thus preventing an update from being applied because they're incorrect.

When programming directly with CubeProgrammer, everything goes well (second image below), and we do indeed find the 0x00s. But this means that debug tests will no longer be possible due to the erroneous data in Flash...
I tested on CubeIDE v1.8.1, v1.8 and even the v1.17.0, but the same problem persists. A "monitor flash mass_erase" doesn't fix the problem. Everything seems fine when using CubeIDE v1.15.1 but the generated binary isn't the same.

The incorrectly written data corresponds to the assignment of an ALIGN (third image below), which is enough to distort an entire verification operation, and this is quite annoying since no solution to this problem has been found.

I admit that this difference in behavior between CubeIDE and CubeProgrammer is quite annoying.

The comparison between the compiled binary (left) and what is written in flash (right) :

comparison between the compiled binary (left) and what is written in flash (right)

but when programming from cubeprogrammer it sets the bits to 0 whether with elf or bin :

when programming from cubeprogrammer it sets the bits to 0 whether with elf or bin

 And this is what the erroneous data corresponds to : baseapp(0x8001800) + offset(0x12b78) -> 0x8014378

baseapp(0x8001800) + offset(0x12b78) -> 0x8014378

[JPV]

Maybe you should look at the linker scripts being used to see if they are different. Especially look for a "FILL" command. Also look at the "Output Section Fill" part of the LD linker script documentation. I hope this is helpful.

[TDK]

Not sure there's a magic solution here. Changing one or the other would break someone's workflow.

Adjust the linker file such that these gaps do not exist, or always use the same method for updating.

[MM..1]

You dont detailing info. IDE can use many debug probes drivers with bugs for example ulink jlink stlink

Programmer use one only stlink probe. Default in IDE is Programmer CLI then i dont see diff. But included programmer version in IDE can differ from standalone installed version etc.

Primary create hex or bin file and chcek bytes here.

[Pkemarco]

I tried to use FILL all over the linker script but nothing changed unfortunately.

[Pkemarco]

Everything is fine with the bin (since it's filled with 0x00) but the major issue is when debugging since those gaps aren't filled. During investigation, it's using an srec file from the elf, but I don't see anywhere where I can add a --gap-fill instruction.

[Pkemarco]

I'm currently using Stm32CubeIDE 1.18.1, with STLink GDB Server (default configuration) with ST-LINK/V2-ISOL and inside it's using STM32CubeProgrammer v2.19.0.

When I use the bin or elf with CubeProgrammer, everything is fine, but the probrem is when I'm debugging since it's using an srec I think (.../ST-LINK_GDB_server_a23580.srec) and then the gaps aren't filled with 0x00 but leave like it is (so 0xFF when formating). And I don't see anywhere where I can add a --gap-fill instruction for the srec file. That create a divergence and the CRC algo doesn't work then.

[MM..1]

Simply set debuging without flash loading and preload with script ... 

[Pkemarco · Accepted solution]

I finally resolved what seemed to be the problem by replacing the ALIGN(4) with an ALIGN(16) (as recommended in a previous forum post).

I admit that the previous behavior was strange, but at least that part is fixed. For now, I consider it resolved. I'll probably continue my tests in the coming days.

Thank you very much for your contributions!