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

Question

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

dougyeager opened this issue 7 years ago · 52 comments

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

Answer 1 · 2017-06-21T18:04:29.000Z

i meant to add that this is repeatable. it happens every time when i program (not sometimes). read and erase seem to work ok. when in debug mode, i get this for a long time and then the timeout happens and error's out. i'm not sure why my core is not going to HALT state. i don't think it is the reset line hardware as some have suggested, but i suppose it could be...:
2017-06-20T17:14:57 DEBUG /Users/jerry/Downloads/stlink-master/src/common.c: core status: running
2017-06-20T17:14:57 DEBUG /Users/jerry/Downloads/stlink-master/src/common.c: *** stlink_status ***
2017-06-20T17:14:57 DEBUG /Users/jerry/Downloads/stlink-master/src/common.c: core status: running
2017-06-20T17:14:57 DEBUG /Users/jerry/Downloads/stlink-master/src/common.c: *** stlink_status ***
2017-06-20T17:14:57 DEBUG /Users/jerry/Downloads/stlink-master/src/common.c: core status: running

Answer 2 · 2017-11-03T09:21:48.000Z

I'm getting the exact same behavior on my Ugly board.

Answer 3 · 2017-11-03T09:34:04.000Z

Ok get this
I did a cold reset on the ST-LINK and the Ugly by unplugging both from USB and now it works. ¯_(ツ)_/¯

Answer 4 · 2018-06-29T18:29:00.000Z

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.

Answer 5 · 2018-07-16T18:26:59.000Z

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

Answer 6 · 2018-08-25T21:51:05.000Z

I experience the very same issue with an ST-LINK (part of a "discovery" board). Connected to it is a RobotDyn STM32 mini. Flashing works the first time, but the second time it fails:

(...)
2018-08-25T23:43:57 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2018-08-25T23:43:57 INFO flash_loader.c: Successfully loaded flash loader in sram
15/15 pages written
2018-08-25T23:43:58 INFO common.c: Starting verification of write complete
2018-08-25T23:43:58 INFO common.c: Flash written and verified! jolly good!

$ st-flash --reset --format ihex write somefile.hex
st-flash 1.4.0-47-gae717b9
2018-08-25T23:46:08 INFO common.c: Loading device parameters....
2018-08-25T23:46:08 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2018-08-25T23:46:08 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
2018-08-25T23:46:08 INFO common.c: Attempting to write 14932 (0x3a54) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08003800 erased
2018-08-25T23:46:09 INFO common.c: Finished erasing 15 pages of 1024 (0x400) bytes
2018-08-25T23:46:09 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2018-08-25T23:46:09 INFO flash_loader.c: Successfully loaded flash loader in sram
2018-08-25T23:46:12 ERROR flash_loader.c: flash loader run error
2018-08-25T23:46:12 ERROR common.c: stlink_flash_loader_run(0x8000000) failed! == -1
stlink_fwrite_flash() == -1

Unplugging and re-plugging the device fixes the issue, but just for a single time.

The hardware is fine, at least it works without the "unplugging" fix with ST-Link running in a VirtualBox VM with WIn7.

Answer 7 · 2018-12-03T19:33:23.000Z

I am too interested in reason of this problem. As @PDAJ-MM noticed - unplug and plug works as temporary solution.

Answer 8 · 2019-01-07T14:59:01.000Z

Same here for me.

Answer 9 · 2019-01-11T05:20:46.000Z

mine:

2019-01-11T18:03:23 DEBUG common.c: stlink current mode: mass
2019-01-11T18:03:23 DEBUG common.c: stlink current mode: mass
2019-01-11T18:03:23 DEBUG common.c: *** stlink_enter_swd_mode ***
2019-01-11T18:03:23 DEBUG common.c: *** looking up stlink version
2019-01-11T18:03:23 DEBUG common.c: st vid = 0x0483 (expect 0x0483)
2019-01-11T18:03:23 DEBUG common.c: stlink pid = 0x3748
2019-01-11T18:03:23 DEBUG common.c: stlink version = 0x2
2019-01-11T18:03:23 DEBUG common.c: jtag version = 0x11
2019-01-11T18:03:23 DEBUG common.c: swim version = 0x4
2019-01-11T18:03:23 DEBUG common.c: *** stlink_jtag_reset ***
2019-01-11T18:03:23 DEBUG common.c: *** stlink_reset ***
2019-01-11T18:03:23 DEBUG common.c: *** stlink_write_debug32 5fa0004 to 0xe000ed0c
2019-01-11T18:03:23 INFO common.c: Loading device parameters....
2019-01-11T18:03:23 DEBUG common.c: *** stlink_core_id ***
2019-01-11T18:03:23 DEBUG common.c: core_id = 0x2ba01477
2019-01-11T18:03:23 DEBUG common.c: *** stlink_read_debug32 20036410 is 0xe0042000
2019-01-11T18:03:23 DEBUG common.c: *** stlink_read_debug32 ffff0080 is 0x1ffff7e0
2019-01-11T18:03:23 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2019-01-11T18:03:23 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 1024 bytes
2019-01-11T18:03:23 DEBUG common.c: *** set_swdclk ***
2019-01-11T18:03:23 DEBUG common.c: stlink current mode: debug (jtag or swd)
2019-01-11T18:03:23 DEBUG common.c: stlink current mode: debug (jtag or swd)
2019-01-11T18:03:23 DEBUG common.c: *** stlink_force_debug_mode ***
2019-01-11T18:03:23 DEBUG common.c: *** stlink_status ***
2019-01-11T18:03:23 DEBUG common.c: core status: halted
2019-01-11T18:03:23 INFO common.c: Attempting to write 14292 (0x37d4) bytes to stm32 address: 134231040 (0x8003400)
2019-01-11T18:03:23 DEBUG common.c: *** stlink_core_id ***
2019-01-11T18:03:23 DEBUG common.c: core_id = 0x2ba01477
2019-01-11T18:03:23 DEBUG common.c: *** stlink_read_debug32 0 is 0x4002200c
2019-01-11T18:03:23 DEBUG common.c: *** stlink_read_debug32 80 is 0x40022010
2019-01-11T18:03:23 DEBUG common.c: *** stlink_write_debug32 45670123 to 0x40022004
2019-01-11T18:03:23 DEBUG common.c: *** stlink_write_debug32 cdef89ab to 0x40022004
2019-01-11T18:03:23 DEBUG common.c: *** stlink_read_debug32 0 is 0x40022010
2019-01-11T18:03:23 DEBUG common.c: Successfully unlocked flash
2019-01-11T18:03:23 DEBUG common.c: *** stlink_write_debug32 2 to 0x40022010
2019-01-11T18:03:23 DEBUG common.c: *** stlink_write_debug32 8003400 to 0x40022014
2019-01-11T18:03:23 DEBUG common.c: *** stlink_read_debug32 2 is 0x40022010
2019-01-11T18:03:23 DEBUG common.c: *** stlink_write_debug32 42 to 0x40022010
2019-01-11T18:03:23 DEBUG common.c: *** stlink_read_debug32 10 is 0x4002200c
2019-01-11T18:03:23 DEBUG common.c: *** stlink_read_debug32 2 is 0x40022010
2019-01-11T18:03:23 DEBUG common.c: *** stlink_write_debug32 82 to 0x40022010
2019-01-11T18:03:23 DEBUG common.c: *** stlink_read_debug32 10 is 0x4002200c
2019-01-11T18:03:23 DEBUG common.c: *** stlink_read_debug32 82 is 0x40022010
2019-01-11T18:03:23 DEBUG common.c: *** stlink_write_debug32 45670123 to 0x40022004
2019-01-11T18:03:23 DEBUG common.c: *** stlink_write_debug32 cdef89ab to 0x40022004
2019-01-11T18:03:23 DEBUG common.c: *** stlink_read_debug32 2 is 0x40022010
2019-01-11T18:03:23 DEBUG common.c: Successfully unlocked flash

... skip similar:

2019-01-11T18:03:23 DEBUG common.c: Successfully unlocked flash
2019-01-11T18:03:23 DEBUG common.c: *** stlink_write_debug32 2 to 0x40022010
2019-01-11T18:03:23 DEBUG common.c: *** stlink_write_debug32 8006800 to 0x40022014
2019-01-11T18:03:23 DEBUG common.c: *** stlink_read_debug32 2 is 0x40022010
2019-01-11T18:03:23 DEBUG common.c: *** stlink_write_debug32 42 to 0x40022010
2019-01-11T18:03:23 DEBUG common.c: *** stlink_read_debug32 10 is 0x4002200c
2019-01-11T18:03:23 DEBUG common.c: *** stlink_read_debug32 2 is 0x40022010
2019-01-11T18:03:23 DEBUG common.c: *** stlink_write_debug32 82 to 0x40022010
2019-01-11T18:03:23 INFO common.c: Finished erasing 14 pages of 1024 (0x400) bytes
2019-01-11T18:03:23 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2019-01-11T18:03:23 DEBUG common.c: *** stlink_write_mem32 40 bytes to 0x20000000
2019-01-11T18:03:23 INFO flash_loader.c: Successfully loaded flash loader in sram
2019-01-11T18:03:23 DEBUG common.c: *** stlink_read_debug32 82 is 0x40022010
2019-01-11T18:03:23 DEBUG common.c: *** stlink_write_debug32 45670123 to 0x40022004
2019-01-11T18:03:23 DEBUG common.c: *** stlink_write_debug32 cdef89ab to 0x40022004
2019-01-11T18:03:23 DEBUG common.c: *** stlink_read_debug32 2 is 0x40022010
2019-01-11T18:03:23 DEBUG common.c: Successfully unlocked flash
2019-01-11T18:03:23 DEBUG common.c: *** stlink_read_debug32 2 is 0x40022010
2019-01-11T18:03:23 DEBUG common.c: *** stlink_write_debug32 1 to 0x40022010
2019-01-11T18:03:23 DEBUG common.c: Finished unlocking flash, running loader!
2019-01-11T18:03:23 DEBUG flash_loader.c: Running flash loader, write address:0x8003400, size: 1024
2019-01-11T18:03:23 DEBUG common.c: *** stlink_write_mem32 1024 bytes to 0x20000028
2019-01-11T18:03:23 DEBUG common.c: *** stlink_write_reg
2019-01-11T18:03:23 DEBUG common.c: *** stlink_write_reg
2019-01-11T18:03:23 DEBUG common.c: *** stlink_write_reg
2019-01-11T18:03:23 DEBUG common.c: *** stlink_write_reg
2019-01-11T18:03:23 DEBUG common.c: *** stlink_write_reg
2019-01-11T18:03:23 DEBUG common.c: *** stlink_run ***
2019-01-11T18:03:23 DEBUG common.c: *** stlink_status ***
2019-01-11T18:03:23 DEBUG common.c: core status: running
2019-01-11T18:03:23 DEBUG common.c: *** stlink_status ***
2019-01-11T18:03:23 DEBUG common.c: core status: running
2019-01-11T18:03:23 DEBUG common.c: *** stlink_status ***
2019-01-11T18:03:23 DEBUG common.c: core status: running

that loops a fair few times:

2019-01-11T18:03:26 DEBUG common.c: *** stlink_status ***
2019-01-11T18:03:26 DEBUG common.c: core status: running
2019-01-11T18:03:26 DEBUG common.c: *** stlink_status ***
2019-01-11T18:03:26 DEBUG common.c: core status: running
2019-01-11T18:03:26 ERROR flash_loader.c: flash loader run error
2019-01-11T18:03:26 ERROR common.c: stlink_flash_loader_run(0x8003400) failed! == -1
2019-01-11T18:03:26 DEBUG common.c: *** stlink_read_debug32 0 is 0x8003400
2019-01-11T18:03:26 DEBUG common.c: *** stlink_write_reg
2019-01-11T18:03:26 DEBUG common.c: *** stlink_read_debug32 0 is 0x8003404
2019-01-11T18:03:26 DEBUG common.c: *** stlink_write_reg
2019-01-11T18:03:26 DEBUG common.c: *** stlink_run ***
2019-01-11T18:03:26 DEBUG common.c: *** stlink_exit_debug_mode ***
2019-01-11T18:03:26 DEBUG common.c: *** stlink_write_debug32 a05f0000 to 0xe000edf0
2019-01-11T18:03:26 DEBUG common.c: *** stlink_close ***

Answer 10 · 2019-02-01T09:30:17.000Z

I also got this problem on STM32F4 Discovery board. But plugging/unplugging does not solve. Hardware runs well on Windows with stlink v2 utility. :|

Answer 11 · 2019-02-04T16:22:55.000Z

Same here. (STM32L052). Works after plugging/unplugging.

Answer 12 · 2019-02-07T15:51:23.000Z

I got the same behavior as @rvowles under ubuntu linux with the stm32f4 discover board and st-flash

Answer 13 · 2019-02-07T21:47:31.000Z

The F4 flashing is currently broken. See #766

Answer 14 · 2019-02-08T00:03:23.000Z

Seems that L4 flashing is broken as well.
I get the same error when attempting to flash STM32L496AGI6 on a Discovery kit board. Plugging / unplugging the board doesn't help. Flashing the same binary to a F7 chip works fine (STM32F767ZIT6).
My OS is Linux Mint 18 64-bit.

st-flash write original_demo.bin.bkp 0x08000000
st-flash 1.5.1
2019-02-08T01:49:01 INFO common.c: Loading device parameters....
2019-02-08T01:49:01 INFO common.c: Device connected is: L496x/L4A6x device, id 0x20006461
2019-02-08T01:49:01 INFO common.c: SRAM size: 0x40000 bytes (256 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes
2019-02-08T01:49:01 INFO common.c: Ignoring 488 bytes of 0xff at end of file
2019-02-08T01:49:01 INFO common.c: Attempting to write 1048088 (0xffe18) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x080ff800 erasedEraseFlash - Page:0x1ff Size:0x800
2019-02-08T01:49:15 INFO common.c: Finished erasing 512 pages of 2048 (0x800) bytes
2019-02-08T01:49:15 INFO common.c: Starting Flash write for F2/F4/L4
2019-02-08T01:49:15 INFO flash_loader.c: Successfully loaded flash loader in sram
size: 32768
2019-02-08T01:49:19 ERROR flash_loader.c: flash loader run error
2019-02-08T01:49:19 ERROR common.c: stlink_flash_loader_run(0x8000000) failed! == -1
stlink_fwrite_flash() == -1

Answer 15 · 2019-02-08T05:48:18.000Z

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

Answer 16 · 2019-02-08T16:36:46.000Z

not working with latest stlink and latest mac. Same problem still exists.

Answer 17 · 2019-02-09T10:16:03.000Z

We should continue in #761 for issues with latest master version. This issue is really old. Closing this for not recycling this inappropriate. Thanks all for the comments.

Answer 18 · 2020-06-26T19:34:35.000Z

Still running into this, board: STM32L476RG Nucleo

2020-06-26T21:32:17 INFO common.c: Finished erasing 20 pages of 2048 (0x800) bytes
2020-06-26T21:32:17 INFO common.c: Starting Flash write for F2/F4/L4
2020-06-26T21:32:17 INFO flash_loader.c: Successfully loaded flash loader in sram
size: 32768
2020-06-26T21:32:17 ERROR flash_loader.c: flash loader run error
2020-06-26T21:32:17 ERROR common.c: stlink_flash_loader_run(0x8000000) failed! == -1
stlink_fwrite_flash() == -1

❯ st-flash --version
v1.6.1

Tried using the develop branch directly, same error

Commenting here, because the other one is locked

Answer 19 · 2020-06-26T21:44:01.000Z

@ForsakenHarmony: Thx for reporting.
Indeed this is not a recycling of an old topic as this issue had been attached to the wrong PR.

Answer 20 · 2020-06-28T23:09:33.000Z

Just a note, not sure if it helps with anything

I can flash it fine with openocd

Answer 21 · 2020-06-28T23:20:11.000Z

Yeah, well I think that doesn't really help, as we can't do a sort of copy paste here (licensing).
We would need to find the reason in the implementation of our toolset. 😐

Answer 22 · 2020-07-01T06:49:23.000Z

I was facing the exact same issue with a STM32F030f4 chip. However, I was able to program the chip every other time, which was a bit painful. After some investigation, it appears that the programmer is not able to halt the microcontroller.
What worked for me is to reset the chip in order to program it successfuly every time using the --reset switch:
st-flash --reset write firmware.bin 0x8000000
I hope this will help.
Maybe it would be nice to make st-flash output an informative message with such a hint when it is unable to halt the target.

Answer 23 · 2020-07-01T17:21:19.000Z

I actually think this may be related to the other unsolved "reset"-Problems we have seen so far.
It looks like we can not ensure proper handling yet to correctly halt/reset the MCUs and make that really reproducible.
I'm not really satisfied with the current state. This is should be one of the main points to address in the next release.
However we should look at the oldest issue related to improper resetting (could be #62) and then begin to work through all following reports. There are likely some duplicates on this way.

Answer 24 · 2020-07-21T22:36:16.000Z

Have the same issue with stlink 1.6.1
No problems with stlink 1.6.0

Device connected is: L4Rx device

uname -r
5.4.52-1-MANJARO

Answer 25 · 2020-07-25T19:16:43.000Z

git bisect gives me the following result:

da68271a03b10f07b4a643024e5541bc80d86561 is the first bad commit

Looks like a bad merge:

commit da68271a03b10f07b4a643024e5541bc80d86561
Merge: 273e798 5fc02ab
Author: nightwalker-87 <15526941+Nightwalker-87@users.noreply.github.com>
Date:   Tue May 19 16:38:34 2020 +0200

    Merge pull request #955 from stlink-org/dist
    
    Update for package distribution & refactoring of build settings

I've double-checked to confirm this finding: git checkout da68271a gives a broken build, while git checkout da68271a^ works fine.

Answer 26 · 2020-07-25T21:13:05.000Z

Thx for the feedback. I'll try to find the specific cause within this commit ASAP.

Answer 27 · 2020-07-26T09:33:43.000Z

@10110111: I am not able to verify this currently (apart from reviewing changes in the codebase) as I am without any hardware in reach. Can you bisect into the merged-in branch downwards from 5fc02ab as well? The issue is probably related to a false cmake setting, but yet hard to allocate. However going through that branch would help.

Answer 28 · 2020-07-26T09:59:32.000Z

Both ce6ffe7 and 5fc02ab (the borders of the range of commits in #955) by themselves are good. So nothing to bisect there.

There might be an invisible (to git) conflict that appeared while merging. The difference between last good and first bad commits (i.e. between the merge commit and its parent) is quite large:

$ git diff --stat 5fc02abf33722fbf27996e955b2cc3017368e45a..da68271a03b10f07b4a643024e5541bc80d86561
 .../ISSUE_TEMPLATE/bug-report--only-valid-if-template-is-reused--.md |  38 ++
 .github/ISSUE_TEMPLATE/bug-report.md                                 |   6 +-
 README.md                                                            |   2 +-
 doc/flashloaders.md                                                  |  54 +++
 doc/tutorial.md                                                      | 160 ++------
 flashloaders/Makefile                                                |  38 ++
 flashloaders/cleanroom.md                                            | 233 +++++++++++
 flashloaders/linker.ld                                               |   9 +
 flashloaders/stm32f0.s                                               | 105 +++--
 flashloaders/stm32f4.s                                               |  54 +--
 flashloaders/stm32f4lv.s                                             |  69 ++--
 flashloaders/stm32f7.s                                               |  66 +--
 flashloaders/stm32f7lv.s                                             |  73 ++--
 flashloaders/stm32l0x.s                                              |  76 +---
 flashloaders/stm32l4.s                                               |  61 ++-
 flashloaders/stm32lx.s                                               |  72 +---
 include/stlink.h                                                     | 486 ++++++++++++----------
 include/stlink/commands.h                                            |  49 ++-
 include/stlink/tools/flash.h                                         |   5 +-
 src/common.c                                                         |  52 +--
 src/flash_loader.c                                                   | 300 +++++++-------
 src/logging.c                                                        |   2 +-
 src/mingw/mingw.h                                                    |  14 +-
 src/sg.c                                                             |  20 +-
 src/st-util/gdb-server.c                                             |   6 +-
 src/stlink-gui/gui.c                                                 |   2 +-
 src/stlink-gui/stlink-gui.desktop                                    |   2 +-
 src/tools/flash.c                                                    |   8 +-
 src/tools/flash_opts.c                                               | 166 ++++++--
 src/tools/info.c                                                     |   2 +-
 src/usb.c                                                            | 665 +++++++++++++++++--------------
 src/usb.h                                                            |   2 +-
 tests/flash.c                                                        |  79 +++-
 tests/usb.c                                                          |   2 +-
 34 files changed, 1772 insertions(+), 1206 deletions(-)

Answer 29 · 2020-07-26T10:41:38.000Z

Oh, actually, the commit right before all the merged commits, f8ef21c, 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 442ade8, 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

Answer 30 · 2020-07-26T11:02:19.000Z

I can remember there was quite some trouble with the branch merged in a98b094. As it failed to keep track of changes in the develop branch at that time. So there were some attempts to fix that before merging. Well possible that the reported issue was accidentally introduced in this context.

To me the changes in the following functions in common.c appear relevant:

bool stlink_is_core_halted(stlink_t *sl)
void stlink_core_stat(stlink_t *sl)

Answer 31 · 2020-09-08T07:43:39.000Z

FYI - I am using ubuntu 20 and I got errors with v1.6.1 of stlink flashing an L4 device. I saw someone said that v1.5.0 of stlink would work, but this version would not succesfully make the release folder for me. Due to some Cmake issue that I could not resolve.

But I tried flashing a L4 with the 1.6.0 release of stlink by Texane and it works.

Answer 32 · 2020-09-16T13:12:24.000Z

I'm using st-flash version v1.6.1-95-gba5c679, with st-link v2. I have STM32F072. I am flashing from RPI4 (raspbian). As far as I can tell, every second time it will throw error

INFO common.c: Flash page at addr: 0x0801f000 erased
INFO common.c: Flash page at addr: 0x0801f800 erased
INFO common.c: Finished erasing 64 pages of 2048 (0x800) bytes
INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
INFO flash_loader.c: Successfully loaded flash loader in sram
ERROR flash_loader.c: flash loader run error
ERROR common.c: stlink_flash_loader_run(0x8000000) failed! == -1
stlink_fwrite_flash() == -1

and every second time it will succeed.

Answer 33 · 2020-09-16T16:54:45.000Z

I actually think this may be related to the other unsolved "reset"-Problems we have seen so far.

I was having this problem with an L443. I put an oscope probe on the reset line to try to get an idea of what was going on, and the problem disappeared. Assuming the added capacitance from the probe was helping, I added some debounce hardware (low-pass RC filter) to the reset line and haven't had any issues since.

Answer 34 · 2020-09-16T19:47:18.000Z

On Wed, Sep 16, 2020 at 09:55:19AM -0700, Brian Bove wrote: I added some debounce hardware (low-pass RC filter) to the reset line and haven't had any issues since.

Programmers with electronics skills for the win. Yes, I have respect for it.

Answer 35 · 2020-09-20T23:06:35.000Z

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.

Answer 36 · 2020-09-21T21:10:40.000Z

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

Answer 37 · 2020-10-08T21:16:31.000Z

I was playing around with this today on an L4 Nucleo board. I tried both the latest STLink firmware (2.37.26) and the oldest one available on the ST website (2.32.22). Both had the same behavior.

What I noticed that was that the errors were printed to the terminal 100% of the time, even though flashing actually worked about 50% of the time (flashes once, next time fails (red LED present), reset the board, flashes again). Perhaps the error message is just a red herring.

Answer 38 · 2020-10-09T18:14:45.000Z

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.

Answer 39 · 2020-10-10T17:45:14.000Z

I'm also getting this with an Stm32 NulceoF767ZI:

Of note, I am also using a Raspi4 like an earlier comment.

pi@raspberrypi:~ $ st-flash --reset  --format=ihex write fw.hex
st-flash 1.6.1-98-gd819a4a
2020-10-10T03:17:45 INFO common.c: F76xxx: 512 KiB SRAM, 2048 KiB flash in at least 2 KiB pages.
2020-10-10T03:17:45 INFO common.c: Attempting to write 255304 (0x3e548) bytes to stm32 address: 134217728 (0x8000000)
EraseFlash - Sector:0x0 Size:0x8000 2020-10-10T03:17:45 INFO common.c: Flash page at addr: 0x08000000 erased
EraseFlash - Sector:0x1 Size:0x8000 2020-10-10T03:17:45 INFO common.c: Flash page at addr: 0x08008000 erased
EraseFlash - Sector:0x2 Size:0x8000 2020-10-10T03:17:46 INFO common.c: Flash page at addr: 0x08010000 erased
EraseFlash - Sector:0x3 Size:0x8000 2020-10-10T03:17:46 INFO common.c: Flash page at addr: 0x08018000 erased
EraseFlash - Sector:0x4 Size:0x20000 2020-10-10T03:17:47 INFO common.c: Flash page at addr: 0x08020000 erased
2020-10-10T03:17:47 INFO common.c: Finished erasing 5 pages of 131072 (0x20000) bytes
2020-10-10T03:17:47 INFO common.c: Starting Flash write for F2/F4/F7/L4
2020-10-10T03:17:47 INFO flash_loader.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 32768
2020-10-10T03:17:48 ERROR flash_loader.c: flash loader run error
2020-10-10T03:17:48 ERROR common.c: stlink_flash_loader_run(0x8000000) failed! == -1
stlink_fwrite_flash() == -1

Answer 40 · 2020-10-10T18:02:27.000Z

For what it's worth going to tag v1.6.0 results in a working config on an Stm32F767zi Nucleo with a Raspi4

Answer 41 · 2020-12-18T13:47:19.000Z

st-flash 1.6.1 with STM32F373CCTx:
command:

st-flash --reset write <folderPath>/Drivecontroller/MainController/build/MainController.bin 0x8000000

output:

st-flash 1.6.1
2020-12-18T14:38:38 INFO common.c: F3xx: 40 KiB SRAM, 256 KiB flash in at least 2 KiB pages.
file <folderPath>/MainController/build/MainController.bin md5 checksum: 9f5e7fe1c654e9183f3e116cd745ea12, stlink checksum: 0x0004f76c
2020-12-18T14:38:38 INFO common.c: Attempting to write 3372 (0xd2c) bytes to stm32 address: 134217728 (0x8000000)
2020-12-18T14:38:38 INFO common.c: Flash page at addr: 0x08000000 erased
2020-12-18T14:38:38 INFO common.c: Flash page at addr: 0x08000800 erased
2020-12-18T14:38:38 INFO common.c: Finished erasing 2 pages of 2048 (0x800) bytes
2020-12-18T14:38:38 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2020-12-18T14:38:38 INFO flash_loader.c: Successfully loaded flash loader in sram
2020-12-18T14:38:38 ERROR flash_loader.c: flash loader run error
2020-12-18T14:38:38 ERROR common.c: stlink_flash_loader_run(0x8000000) failed! == -1
stlink_fwrite_flash() == -1
The terminal process "/bin/bash '-c', 'st-flash write <folderPath>/MainController/build/MainController.bin 0x8000000'" terminated with exit code: 255.

It works on every second run

Hint: replaced the real path with <folderPath>

Answer 42 · 2020-12-18T14:42:18.000Z

@ploedige Can you try st-flash built from the develop branch?

Answer 43 · 2020-12-18T15:52:30.000Z

I'm not very familiar with the st-link utility, yet. What develop branch are you referring to?

Answer 44 · 2020-12-18T16:06:25.000Z

Sorry. I think I know what you mean.
The develop branch has the same problem:

st-flash 1.6.1-194-ga66557a
2020-12-18T17:04:20 INFO common.c: F3xx: 40 KiB SRAM, 256 KiB flash in at least 2 KiB pages.
<folderPath>/MainController/build/MainController.bin md5 checksum: 9f5e7fe1c654e9183f3e116cd745ea12, stlink checksum: 0x0004f76c
2020-12-18T17:04:21 INFO common.c: Attempting to write 3372 (0xd2c) bytes to stm32 address: 134217728 (0x8000000)
2020-12-18T17:04:21 INFO common.c: Flash page at addr: 0x08000000 erased
2020-12-18T17:04:21 INFO common.c: Flash page at addr: 0x08000800 erased
2020-12-18T17:04:21 INFO common.c: Finished erasing 2 pages of 2048 (0x800) bytes
2020-12-18T17:04:21 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL
2020-12-18T17:04:21 INFO flash_loader.c: Successfully loaded flash loader in sram
2020-12-18T17:04:21 ERROR flash_loader.c: Flash loader run error (R2 0x41000000 R15 0x41000000 DHCSR 0x01090001 DFSR 0x00000009)
2020-12-18T17:04:21 ERROR common.c: stlink_flash_loader_run(0x8000000) failed! == -1
2020-12-18T17:04:21 INFO common.c: Go to Thumb mode
stlink_fwrite_flash() == -1
The terminal process "/bin/bash '-c', 'st-flash --reset write <folderPath>/MainController/build/MainController.bin 0x8000000'" terminated with exit code: 255.

Answer 45 · 2020-12-21T05:38:12.000Z

@ploedige The ARM core in lockup state. Most likely the bootloader (or the core of some reason before bootloader runs) falls into the hardfault.
Based on current information, it is difficult to say why this is happening. You may extend information in src/stlink-lib/flash_loader.c by cheinging stlink_flash_loader_run:

    uint32_t dhcsr, dfsr;

change to

    uint32_t dhcsr, dfsr, cfsr, hfsr;

and

    dhcsr = dfsr = 0;
    stlink_read_debug32(sl, STLINK_REG_DHCSR, &dhcsr);
    stlink_read_debug32(sl, STLINK_REG_DFSR, &dfsr);

change to

    dhcsr = dfsr = cfsr = hfsr = 0;
    stlink_read_debug32(sl, STLINK_REG_DHCSR, &dhcsr);
    stlink_read_debug32(sl, STLINK_REG_DFSR, &dfsr);
    stlink_read_debug32(sl, 0xE000ED28, &cfsr);
    stlink_read_debug32(sl, 0xE000ED2C, &hfsr);
    ELOG("CFSR 0x%08X HFSR 0x%08X\n", cfsr, hfsr);

Answer 46 · 2021-01-08T11:40:45.000Z

Instruction (Ubuntu 20.04) to avoid the error:

First, we are going to install the necessary libraries and build tools:

sudo apt-get install git make cmake libusb-1.0-0-dev
sudo apt-get install gcc build-essential
Now, we will download and build the ST-Link utilities:

cd ~myusername
mkdir stm32
cd stm32
git clone https://github.com/stlink-org/stlink
git checkout v1.6.1
cd stlink
cmake .
make

~~Now we copy the built binaries to their place:~~

cd bin
~~sudo cp st-* /usr/local/bin~~
cd ../lib
~~sudo cp .so /lib32~~

then udev rules:

~~sudo cp stlink/config/udev/rules.d/49-stlinkv* /etc/udev/rules.d/~~

Answer 47 · 2021-01-08T12:52:38.000Z

❗ No, this is no good approach, one should not manually copy files to other locations.
This also breaks the implemented uninstall routine.
Use sudo make install for correct installation to the appropriate paths or follow our compilation tutorial.

Answer 48 · 2021-01-12T12:27:32.000Z

I'm having the same issue, even with v1.6.1, and power cycling does not fix it.

$ st-flash --reset --format ihex write test_app_v1_00.hex   
st-flash 1.6.1
2021-01-12T13:25:30 INFO common.c: F4xx: 192 KiB SRAM, 1024 KiB flash in at least 16 KiB pages.
2021-01-12T13:25:30 INFO common.c: Attempting to write 32528 (0x7f10) bytes to stm32 address: 134217728 (0x8000000)
EraseFlash - Sector:0x0 Size:0x4000 2021-01-12T13:25:30 INFO common.c: Flash page at addr: 0x08000000 erased
EraseFlash - Sector:0x1 Size:0x4000 2021-01-12T13:25:30 INFO common.c: Flash page at addr: 0x08004000 erased
2021-01-12T13:25:30 INFO common.c: Finished erasing 2 pages of 16384 (0x4000) bytes
2021-01-12T13:25:30 INFO common.c: Starting Flash write for F2/F4/L4
2021-01-12T13:25:30 INFO flash_loader.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 32528
2021-01-12T13:25:31 ERROR flash_loader.c: flash loader run error
2021-01-12T13:25:31 ERROR common.c: stlink_flash_loader_run(0x8000000) failed! == -1
stlink_fwrite_flash() == -1

Answer 49 · 2021-01-14T16:49:34.000Z

Ok, so I actually found a fix in my situation. Turns out the write protection was activated on part of the flash. Unfortunately, setting option bytes via st-flash is not supported for the STM32F4, but using the STM32CubeProgrammer, I managed to completely erase everything on the flash:

./STM32_Programmer.sh -c port=SWD -ob WRP0=1 WRP1=1 WRP2=1 WRP3=1 -e all

After this, flashing with st-flash worked again!

Answer 50 · 2021-01-17T18:58:26.000Z

Yes, that may be, but does not help us to fix the problem properly in this toolset. 😕

Answer 51 · 2021-01-18T19:26:01.000Z

Yeah, I guess it's impossible to do unless writing to the option bytes area is supported, see #458.

Answer 52 · 2021-03-09T21:37:32.000Z

Feel free to check the known good commits listed in #356 on the reported bugs you have faced within this topic, but report the results here. Please avoid cross-posting between issues.
We need to distinguish different outputs of "flash loader run errors" precisely as they are likely to have several causes.