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

[second-string]

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

[Nightwalker-87]

@nerdmaennchen: I thought this was fixed in #876...

[Nightwalker-87]

There are several similar issues but that clearly does not help any further...
@dot4qu: Can you test with v1.6.1 as well to have 25d0e56 included? I can't figure out the reason for this issue at the moment, but can do some testing later on.

Who can help with this?

[second-string]

I can give it a test later. The reason I've been so quiet is because OpenOCD has been working great for me, but I'd love to get to the bottom of this if possible

[Nightwalker-87]

Yes, true - we also want to see it working of course.

[second-string]

Still the exact same problem :/.

1. git pulled the latest master and ensured that head commit was tagged 1.6.1
2. make release
3. Run the gdb server with cd build/Release/bin and ./st-util -p 4444
4. Attempt to connect and load .elf, same failure on the second page

Once again, the full erase and reprogram worked, but continued to fail on subsequent loads.

[Nightwalker-87]

ok, good to know. I wonder if this ever worked. Have you tried older versions as well (v1.5.1, 1.5.0, ...)? Note that one needs to use the x.x.x-patch branches here to be able to compile due to a git version tagging problem.

[second-string]

Same thing on 1.5.0 :/

[Nightwalker-87]

Ok, thx for testing, so it is likely not a regression.

[Nightwalker-87]

I was able to do some more testing on this now, but only on a Debian Linux system... (see issue #356)

[second-string]

Interesting, glad you could get a repro. If you'd like me to try anything on macOS specifically let me know.

[Nightwalker-87]

Hi @dot4qu. Thx for the offer 👍
I think we'll focus the thread in #356, as it appears to be the oldest one dealing with this topic.
Looking at your specific findings, it may not even be relevant if there is a write operation to a specific address or a general write operation for the whole flash. At least we can not distinguish between both by now. There might be several side effects that cause other flavours of the observed behaviour as well. For the first it seems to make sense to focus on the core problem.

[second-string]

Alright, feel free to close this to declutter then. Thanks for the help!

[Nightwalker-87]

Our policy is to leave tickets open until a problem is resolved, because we link the issue-addressing PR to all related issues which will then close all by making use of git automation upon merging.

[Nightwalker-87]

@dot4qu After a long wait (sry) there is an update to this now. 😃
As it looks like @Ant-ON has successfully fixed #356, and will likely submit a PR soon.
You may test it against this issue then.
I know this is stlink_flash_loader_run(0x8000400) and thus not exactly the same, but you can give it a try.

[Nightwalker-87]

@dot4qu #1113 is ready for testing.

[second-string]

(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.

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.

[Ant-ON]

@dot4qu Perhaps st-util is runed with the --multi argument. cannot recv: -2 means the connection to the gdb server is closed

[Nightwalker-87]

@dot4qu Very nice to receive your feedback. As it reads we can now safely close this issue as resolved.

Closed by #1113.