stlink: ST-LINK/V2: `st-util` failing second page of write to flash

Thank you for giving feedback to the stlink project.

In order to allow developers and other contributors to isolate and target your respective issue, please take some time to fill out each of the following items appropriate to your specific problem:

  • Programmer/board type: ST-LINK/V2 clone (small aliexpress USB) (e.g Stlink /v1, /v2, /v2-clone, /v2-1)
  • Programmer firmware version: ST-LINK/V2 version V2J37S7 (most recent as of ticket date) (e.g STSW-LINK007 2.27.15)
  • Operating system and version: macOS Catalina 10.15.4 (e.g Linux, Mac OS X, Windows)
  • Stlink tools version and/or git commit hash: 1.6.0 installed from brew and also fd856ddc40f9e9f55f70b76f4429d16081ee5b02 (latest develop head as of ticket date) (e.g v1.1.0/git-c722056)
  • Stlink commandline tool name: st-util (e.g st-info, st-flash, st-util)
  • Target chip (and board if applicable): STM31F103C8 (blue pill) (e.g STM32F402VG)

Futher we kindly ask you to describe the detected problem as detailed as possible and to add debug output if available, by using the following template:

Commandline-Output:

xxxxx@xxxxx-mbp stlink 283 $ st-util -p 4444
st-util 1.6.0
2020-05-26T21:41:48 INFO usb.c: -- exit_dfu_mode
2020-05-26T21:41:48 INFO common.c: Loading device parameters....
2020-05-26T21:41:48 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2020-05-26T21:41:48 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
2020-05-26T21:41:48 INFO gdb-server.c: Chip ID is 00000410, Core ID is  1ba01477.
2020-05-26T21:41:48 INFO gdb-server.c: Listening at *:4444...
2020-05-26T21:41:57 INFO gdb-server.c: Found 6 hw breakpoint registers
2020-05-26T21:41:57 INFO gdb-server.c: GDB connected.
2020-05-26T21:42:03 INFO gdb-server.c: Found 6 hw breakpoint registers
2020-05-26T21:43:21 INFO common.c: Attempting to write 1024 (0x400) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08000000 erased
2020-05-26T21:43:22 INFO common.c: Finished erasing 1 pages of 1024 (0x400) bytes
2020-05-26T21:43:22 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2020-05-26T21:43:22 INFO flash_loader.c: Successfully loaded flash loader in sram

2020-05-26T21:43:22 INFO common.c: Starting verification of write complete
2020-05-26T21:43:22 INFO common.c: Flash written and verified! jolly good!
2020-05-26T21:43:22 INFO common.c: Attempting to write 1024 (0x400) bytes to stm32 address: 134218752 (0x8000400)
Flash page at addr: 0x08000400 erased
2020-05-26T21:43:22 INFO common.c: Finished erasing 1 pages of 1024 (0x400) bytes
2020-05-26T21:43:22 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2020-05-26T21:43:22 INFO flash_loader.c: Successfully loaded flash loader in sram
2020-05-26T21:43:22 ERROR flash_loader.c: write error, count == 511
2020-05-26T21:43:22 ERROR common.c: stlink_flash_loader_run(0x8000400) failed! == -1

Expected/description:

When loading an .elf binary with arm-none-eabi-gdb, the first page of 0x400 bytes of flash erases and rewrites successfully, but the second fails. If the board is erased with st-flash erase, the gdb load will work successfully. I’m experiencing the exact same situation as #579, but even with the latest develop cloned and built with make release, I’m still running into the issue.

NOTICE: This bug report may be closed without further notice, if not enough information is provided!

Thank you for your support.

The stlink project maintainers

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 18 (11 by maintainers)

Most upvoted comments

(working on the develop branch)

It seems like this has been mostly resolved. I can now repeatedly program the board by loading the file through the st-util gdb server. There’s one message in the log that seems kind of incorrect, but I can’t see any side effects from it. But I’m also using a test binary with like no code in it so it’s hard for me to totally verify functionality other than loading the .elf and setting a breakpoint at the beginning of main.

Screen Shot 2021-03-25 at 8 04 47 PM

Note the “cannot recv: -2”. Not sure what that means.

I can also successfully now call st-flash write path-to-binary 0x08000000 multiple times in a row and it will successfully write each time. So it looks pretty good from my end, thanks so much for following up! And huge thanks to @Ant-ON as well, awesome work.