stlink: STM32F1/F4/L0/L4: flash loader run error

NOTICE: The issue may be closed without notice when not enough information is provided!

Thank you for giving feedback to the stlink project. Take some time to fill out check boxes with a X in the following items so developers and other people can try to to find out what is going on. And add/remove what is appropriate to your problem.

When submitting a feature request, try to reuse the list and add/remove what is appropriate. Place a X between the brackets [X] to mark the list item.

[stlink/v2 ] Programmer/board type: e.g Stlink/v1, Stlink/v2, Stlink/v2-onboard
[lastest from ST ] Programmer firmware version: e.g STSW-LINK007 2.27.15
[ mac] Operating system: e.g Linux, Mac OS X, Windows (with specific version)
[today ] Stlink tools version and/or git commit hash: e.g v1.1.0/git-c722056
[ st-flash] Stlink commandline tool name: e.g st-info, st-flash, st-util
[ STM32F446x] Target chip (and optional board): e.g STM32F402VG (STM32Fxxx Discovery)

A as-detailed description possible of the problem with debug output when available.

Output: Dougs-MacBook-Pro:bin dyeager$ ./st-flash write out.bin 0x8000000 st-flash 1.3.0 2017-06-20T18:28:52 INFO /Users/jerry/Downloads/stlink-master/src/common.c: Loading device parameters… 2017-06-20T18:28:52 INFO /Users/jerry/Downloads/stlink-master/src/common.c: Device connected is: F446 device, id 0x10006421 2017-06-20T18:28:52 INFO /Users/jerry/Downloads/stlink-master/src/common.c: SRAM size: 0x20000 bytes (128 KiB), Flash: 0x80000 bytes (512 KiB) in pages of 131072 bytes 2017-06-20T18:28:52 INFO /Users/jerry/Downloads/stlink-master/src/common.c: Attempting to write 16536 (0x4098) bytes to stm32 address: 134217728 (0x8000000) Flash page at addr: 0x08004000 erasedEraseFlash - Sector:0x1 Size:0x4000 2017-06-20T18:28:53 INFO /Users/jerry/Downloads/stlink-master/src/common.c: Finished erasing 2 pages of 16384 (0x4000) bytes 2017-06-20T18:28:53 INFO /Users/jerry/Downloads/stlink-master/src/common.c: Starting Flash write for F2/F4/L4 2017-06-20T18:28:53 INFO /Users/jerry/Downloads/stlink-master/src/flash_loader.c: Successfully loaded flash loader in sram enabling 32-bit flash writes size: 16536 2017-06-20T18:28:57 ERROR /Users/jerry/Downloads/stlink-master/src/flash_loader.c: flash loader run error 2017-06-20T18:28:57 ERROR /Users/jerry/Downloads/stlink-master/src/common.c: stlink_flash_loader_run(0x8000000) failed! == -1 stlink_fwrite_flash() == -1

OUTPUT/ERROR of the commandline tool(s)

Expected/description: short description of the expected value

Thank you, The stlink project maintainers

About this issue

Original URL
State: closed
Created 7 years ago
Comments: 52 (14 by maintainers)

Most upvoted comments

I was able to compile and use an older version until this bug is fixed. 1.4.0 seems to work fine. Here is how to build it if you are under ubuntu and were able to build the currently broken version:

cd ~/stlink # or wherever your stlink clone sits
git checkout 1.4.0-53-ga201d3e
make
cd build/Release
sudo make install

cdrews on Feb 8, 2019

I also have the same problem.

2018-07-16T19:24:46 ERROR flash_loader.c: flash loader run error 2018-07-16T19:24:46 ERROR common.c: stlink_flash_loader_run(0x8000000) failed! == -1 Flash page at addr: 0x08051000 erased size: 32768 stlink_fwrite_flash() == -1 make: *** [stflash] Error 255

I can resolve it by unplugging/replugging the usb cable of the st-link, but that isn’t really a solution

PDAJ-MM on Jul 16, 2018

So after using this tool a couple of hundred times for flashing we have noticed that when mcu is new (unflashed), flashing always succeeds the first time. But if we have already flashed it, tool always fails 1. time and succeeds 2. time.

Erol444 on Oct 9, 2020

This obviously appears to be an evergreen… 🌵 Unfortunately I have no clue what makes this happen. 😕 Is there anybody who is more familiar with this part of the code? Any help is appreciated.

To me it seems to make sense to refactor the whole connection & flash procedure including proper resets. From general maintenance I have the impression that we find ourselves in a continuous circle of bugreports regarding this procedure (though most of them appear solvable with a workaround). However this is not very nice indeed…

Nightwalker-87 on Sep 21, 2020

I too am interested in this issue. We were using v1.3.0 and STLINK V2 until now… Currently testing to upgrade to STLINK V3 and ST-link utilities v1.6.1… The st-flash (new version v.1.6.1) works just fine with STLINK V2. But it doesn’t with V3. I am to probe. But on running st-flash with a ihex format I get the following errors:

$ st-flash --reset --format=ihex write ./hex/XXX.hex
st-flash 1.6.1
2020-09-20T18:30:25 INFO usb.c: Unable to match requested speed 1800 kHz, using 1000 kHz
2020-09-20T18:30:25 INFO common.c: F76xxx: 512 KiB SRAM, 2048 KiB flash in at least 2 KiB pages.
2020-09-20T18:30:25 INFO common.c: Attempting to write 130108 (0x1fc3c) bytes to stm32 address: 134217728 (0x8000000)
EraseFlash - Sector:0x0 Size:0x8000 2020-09-20T18:30:25 INFO common.c: Flash page at addr: 0x08000000 erased
EraseFlash - Sector:0x1 Size:0x8000 2020-09-20T18:30:25 INFO common.c: Flash page at addr: 0x08008000 erased
EraseFlash - Sector:0x2 Size:0x8000 2020-09-20T18:30:26 INFO common.c: Flash page at addr: 0x08010000 erased
EraseFlash - Sector:0x3 Size:0x8000 2020-09-20T18:30:26 INFO common.c: Flash page at addr: 0x08018000 erased
2020-09-20T18:30:26 INFO common.c: Finished erasing 4 pages of 32768 (0x8000) bytes
2020-09-20T18:30:26 INFO common.c: Starting Flash write for F2/F4/L4
2020-09-20T18:30:26 INFO flash_loader.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 32768
2020-09-20T18:30:27 ERROR flash_loader.c: flash loader run error
2020-09-20T18:30:27 ERROR common.c: stlink_flash_loader_run(0x8000000) failed! == -1
stlink_fwrite_flash() == -1

Tried power-cycling by unplugging and plugging. Also doing full erase and firmware upgrade as well… Both of which completes successfully.

abasu0713 on Sep 20, 2020

Oh, actually, the commit right before all the merged commits, f8ef21cd130c2ad6460c375747be5987112c4703, is already bad. Bisection between v1.6.0 and it gives the following (with a caveat):

09ea99aea51f741ce9c8c0e2ad755d40b3d86021 is the first bad commit
commit 09ea99aea51f741ce9c8c0e2ad755d40b3d86021
Author: Miklós Márton <martonmiklosqdev@gmail.com>
Date:   Mon Feb 24 21:34:36 2020 +0100

    Add support for STLink V3
    Flash programming is broken

:040000 040000 2f5f4fa46e447157e5634f8c473969e6bc9be8b0 f7847c064a61f307f89ce0525c0c2b0652689188 M      incl
:040000 040000 a0eaa0236358d2b9c3b2bc1fe8b88a7eddb19a5b 13b6e1a01f5c90f85650bf104f3ff893549b744e M      src

The caveat is that 442ade88ddce1fc8ce4d36c856b57c24ee76aa12, which I marked as “bad” while bisecting, has is only 50% chance of failure, with a curious pattern of alternation of “jolly good!” and this error:

2020-07-26T13:35:14 ERROR flash_loader.c: flash loader run error
2020-07-26T13:35:14 ERROR common.c: stlink_flash_loader_run(0x8000000) failed! == -1
stlink_fwrite_flash() == -1
libusb: warning [libusb_exit] application left some devices open
make: *** [Makefile:69: flash] Error 255

I.e. each time after it failed, the next attempt will succeed, and the one after it will fail again. FWIW, I’m testing it on an STM32F401C-DISCO board. Also FWIW, here’s the full git bisect log, where each “bad” behaves in the above mentioned alternating-failure pattern:

# bad: [f8ef21cd130c2ad6460c375747be5987112c4703] Fix issue 958, move F0 flashloader nops to assembly
# good: [393310fc9925907c239f0ad7fac1e8d0565d65c0] Release v1.6.0
git bisect start 'f8ef21cd130c2ad6460c375747be5987112c4703' 'v1.6.0'
# good: [99a8aaab253a1cda634291b6a975d1560bb89c0a] General Project Update
git bisect good 99a8aaab253a1cda634291b6a975d1560bb89c0a
# good: [8e69625531ec8f6def7a50a60a21f2aeffcd272a] write option byte: final refactor
git bisect good 8e69625531ec8f6def7a50a60a21f2aeffcd272a
# good: [090c4d3e8825feefcf1a1428688cf788b1da6ac1] Fix size issues in stm32f4lv.s and stm32f7lv.s
git bisect good 090c4d3e8825feefcf1a1428688cf788b1da6ac1
# good: [c7d12714b3dbc41393dbeb5ad93dd0e05ed7ee4c] Merge pull request #951 from tardate/fix/readme_links
git bisect good c7d12714b3dbc41393dbeb5ad93dd0e05ed7ee4c
# good: [4c1f5b9575a90178a9f8fd29b64ccbbb00953ec9] Update issue templates
git bisect good 4c1f5b9575a90178a9f8fd29b64ccbbb00953ec9
# bad: [442ade88ddce1fc8ce4d36c856b57c24ee76aa12] Merge branch 'add_stlink_v3_support' of git://github.com/martonmiklos/stlink into develop
git bisect bad 442ade88ddce1fc8ce4d36c856b57c24ee76aa12
# good: [82ac5381982cb635336d0cdb26eabf50d9c53fea] Merge remote-tracking branch 'origin/master' into add_stlink_v3_support
git bisect good 82ac5381982cb635336d0cdb26eabf50d9c53fea
# bad: [0a91936b263f3fd09a42fb1ec32a72a06d9a39d6] Merge remote-tracking branch 'upstream/develop' into add_stlink_v3_support
git bisect bad 0a91936b263f3fd09a42fb1ec32a72a06d9a39d6
# bad: [09ea99aea51f741ce9c8c0e2ad755d40b3d86021] Add support for STLink V3 Flash programming is broken
git bisect bad 09ea99aea51f741ce9c8c0e2ad755d40b3d86021
# first bad commit: [09ea99aea51f741ce9c8c0e2ad755d40b3d86021] Add support for STLink V3 Flash programming is broken

10110111 on Jul 26, 2020

I’m seeing this pretty regularly with STLinkv2. Steps to reproduce:

Disconnect target and try to flash; flash will fail. Reconnect target. Attempt to flash; flash will fail with error:

2018-06-29T11:27:50 ERROR flash_loader.c: flash loader run error
2018-06-29T11:27:50 ERROR common.c: stlink_flash_loader_run(0x8000000) failed! == -1
stlink_fwrite_flash() == -1

Disconnecting STLinkv2 from USB and reconnecting, essentially doing a power cycle, resolves the issue.

ARizzo35 on Jun 29, 2018