Error: Data mismatch found at address (byte = 0x00 instead of 0xFF)

[ynat]

Hi, I am working with STM32L072 microcontroller. I programmed it without any validation or checksum issues, but after reading the firmware and verifying, a mismatch was found in a few flash cells.
For downloading firmware I tried STM32CubeProgrammer v2.13.0 and older, also tried STM32 ST-LINK Utility v4.6.0.0 (STLinkUSBDriver.dll v5.1.2.0, ST-LINK_CLI.exe v3.6.0.0 if needed), STM32CubeIDE 1.17.0 and the problem was the same [Error: data mismatch detected at address 0x800FF3C (byte = 0x00 instead of 0xFF)]
I try other levels of code optimization, the problem persists, but the corrupted cell positions change.
I try to manually change these cells with STM32CubeProgrammer, but after writing to the corrupted cell, the other cells around were also corrupted.
This problem exists on all my L072 processors. 
ST-Link FW : V2J43S7

[AScha.3]

Hi,

Only use cube programmer, actual version.

Try: first do: full chip erase, then flash with verify ON .

What then? Still not erased cells?

 

[ynat]

I downloaded the lastest version of cube programmer v2.18.0.
Tried via DFU and ST-LINK on 5kHz, 100kHz and 4000kHz.
Tried with STM32L072KZU7 and STM32L072RBT6

 

DFU, STM32L072RBT6, simple load and verifying

DFU, STM32L072RBT6, erasing & programming and read again
PS: when i tried full chip erase over dfu, usb disconects and cube programmer stuck

 

ST-LINK, STM32L072RBT6, simple load and verifying

 

ST-LINK, STM32L072RBT6, erasing & programming and read again

 

STM32L072KZU7, other ST-LINK, simple load and verifying

I can't show dfu on STM32L072KZU7 because on board no usb connector

 

 

 

[ynat]

With tab Erasing & Programming corrupted another cells [sorry, it was a different hex file, please ignore this message, I replaced the screenshots above with the correct ones]

[ynat]

I’ve encountered a similar issue on the STM32L072RBT6 with a different firmware and, accordingly, different corrupted cells. However, in that case, the firmware occupied 85% of the flash memory. I thought the problem was related to this and resolved it by setting the optimization level to O3.
But in this case, the firmware occupies less than 45% of the flash memory.

[ynat]

In all my projects I use hex files to download the firmware
I tried loading the elf and bin files and no problem with the validation, the problem remains only with the hex, maybe the STM32CubeIDE is generating it wrong?

[ynat]

I load bin firmware [L072_led_drv.bin] via DFU, and save it as hex file via cube programmer [L072_dump.hex]

Compairing dump and bin file:

 

Compairing saved hex and generated by cubeIDE firmware hex

The file generated by cubeIDE also has a different format than the file saved by the cube programmer

 

[MM..1]

You mix issues, how is real size for target MCU flash? ST-Utility is obsolete and programmer have buggy versions. Try other. Plus fw in STLink latest now is V45 your V43 etc. Too USB cable quality is important plus SWD connection speed .

[ynat]

I tried two STLinks with fw v43 and v45, also tried DFU, this problem only with the hex file created by STM32CubeIDE
I found a solution for myself - using bin files to store the firmware, but I think there is a bug in STM32CubeIDE with the generation of the hex file

[Tesla DeLorean]

The width is more of an asethetic one, 16-bytes width is most typical and keeps line width more constrained.

The 32-byte wide is more efficient. Different tools have different export/import limitations, you can code tools to address this, or use SRecords, etc.

The .HEX output by the linker allows for voids (gaps), and out-of-order addresses. Some of the STM32 have alignment, and minimum word sizes for FLASH lines.

The fill character for voids is often 0xFF, but doesn't have to be, the erased state of the memory on the IC being the most ideal in most situations.

For the most consistency, and for summing or signing, the .BIN format is often more desirable