2024-12-28 03:40 PM
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
Solved! Go to Solution.
2024-12-29 08:01 AM
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
2024-12-29 12:31 AM
Hi,
Only use cube programmer, actual version.
Try: first do: full chip erase, then flash with verify ON .
What then? Still not erased cells?
2024-12-29 04:07 AM - edited 2024-12-29 05:51 AM
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
2024-12-29 04:10 AM - edited 2024-12-29 05:56 AM
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]
2024-12-29 04:21 AM
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.
2024-12-29 05:00 AM
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?
2024-12-29 06:03 AM - edited 2024-12-29 06:07 AM
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
2024-12-29 06:38 AM
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 .
2024-12-29 08:01 AM
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