cancel
Showing results for 
Search instead for 
Did you mean: 

Programming with STM32CubeProgrammer is fine; STM32CubeIDE gives wrong results

Pkemarco
Associate II

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)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 binwhen 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) -> 0x8014378baseapp(0x8001800) + offset(0x12b78) -> 0x8014378

0 REPLIES 0