search

stlink-org / stlink

Open source STM32 MCU programming toolset
BSD 3-Clause "New" or "Revised" License
4.41k stars 1.24k forks source link

[regression] Unable to flash with latest revision of master - STM32F2/F4/L4 #761

Closed michaelsobczak-qeexo closed 4 years ago

michaelsobczak-qeexo commented 5 years ago

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.

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

Output:

Release$ st-flash write ~/data/input/st-ces/lib/qxostlib-datalog-20190104112820-ed73f5.bin 0x8000000 st-flash 1.4.0-58-g6a9d390
2019-01-14T16:35:23 INFO common.c: Loading device parameters.... 
2019-01-14T16:35:23 INFO common.c: Device connected is: L4 device, id 0x10076415
2019-01-14T16:35:23 INFO common.c: SRAM size: 0x18000 bytes (96 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes
2019-01-14T16:35:23 INFO common.c: Attempting to write 109160 (0x1aa68) bytes to stm32 address: 134217728 (0x8000000) Flash page at addr: 0x0801a800 erasedEraseFlash - Page:0x35 Size:0x800
2019-01-14T16:35:24 INFO common.c: Finished erasing 54 pages of 2048 (0x800) bytes 
2019-01-14T16:35:24 INFO common.c: Starting Flash write for F2/F4/L4
2019-01-14T16:35:24 INFO flash_loader.c: Successfully loaded flash loader in sram size: 32768 2019-01-14T16:35:27 ERROR flash_loader.c: flash loader run error
2019-01-14T16:35:27 ERROR common.c: stlink_flash_loader_run(0x8000000) failed! == -1 stlink_fwrite_flash() == -1

Expected/description: When we revert to ae717b945de revision the command goes back to working, for some reason it doesn't work on master

Thank you, The stlink project maintainers

xor-gate commented 5 years ago

This is the diff between those two versions: https://github.com/texane/stlink/compare/ae717b945de...master. I think https://github.com/texane/stlink/compare/ae717b945de...master#diff-df7217cd8a3907646570c002cf509f32R1439 this broke the flash loader which was introduced in PR #751. Ping @dhylands ?

dhylands commented 5 years ago

The latest master seems to be working for me. This is on an NUCLEO-L476RG. I was flashing Micropython which is split into 2 files due to the way the filesystem works.

715 >./st-flash write firmware0.bin 0x08000000
2019-01-17T10:46:23 INFO src/stlink-common.c: Loading device parameters....
2019-01-17T10:46:23 INFO src/stlink-common.c: Device connected is: L4 device, id 0x10076415
2019-01-17T10:46:23 INFO src/stlink-common.c: SRAM size: 0x18000 bytes (96 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes
2019-01-17T10:46:23 INFO src/stlink-common.c: Attempting to write 14752 (0x39a0) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08003800 erased
2019-01-17T10:46:23 INFO src/stlink-common.c: Finished erasing 8 pages of 2048 (0x800) bytes
2019-01-17T10:46:23 INFO src/stlink-common.c: Starting Flash write for F2/F4/L4
2019-01-17T10:46:23 INFO src/stlink-common.c: Successfully loaded flash loader in sram
size: 14752
2019-01-17T10:46:24 INFO src/stlink-common.c: Starting verification of write complete
2019-01-17T10:46:24 INFO src/stlink-common.c: Flash written and verified! jolly good!

716 >./st-flash --reset write firmware1.bin 0x08004000
2019-01-17T10:46:53 INFO src/stlink-common.c: Loading device parameters....
2019-01-17T10:46:53 INFO src/stlink-common.c: Device connected is: L4 device, id 0x10076415
2019-01-17T10:46:53 INFO src/stlink-common.c: SRAM size: 0x18000 bytes (96 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes
2019-01-17T10:46:53 INFO src/stlink-common.c: Attempting to write 302908 (0x49f3c) bytes to stm32 address: 134234112 (0x8004000)
Flash page at addr: 0x0804d800 erased
2019-01-17T10:47:00 INFO src/stlink-common.c: Finished erasing 148 pages of 2048 (0x800) bytes
2019-01-17T10:47:00 INFO src/stlink-common.c: Starting Flash write for F2/F4/L4
2019-01-17T10:47:00 INFO src/stlink-common.c: Successfully loaded flash loader in sram
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 7996
2019-01-17T10:47:06 INFO src/stlink-common.c: Starting verification of write complete
2019-01-17T10:47:09 INFO src/stlink-common.c: Flash written and verified! jolly good!

This is the hash I tested today:

commit 6a9d390a729f381ecec45f212354bfe98e27790f (HEAD -> master, origin/master, origin/HEAD)
Author: WRansohoff <WRansohoff@users.noreply.github.com>
Date:   Sun Jan 13 00:04:21 2019 -0800

    Update STM32F3xx chip ID that covers a few different devices. (#758)

My developement machine is ruinning ubuntu 18.10

michaelsobczak-qeexo commented 5 years ago

Thanks for looking into this. I'm also using L476RG to flash, i can try with latest changes and make sure I can reproduce. Mac OS X Mojave is our development environment

kmfarley11 commented 5 years ago

I can confirm the same behaviour on STM32F4 Discovery. A flash attempt from master resulted in the same "flash loader run error", but reverting to ae717b945de worked for me.

Edit: Note that my OS was actually Linux Ubuntu 16.04 LTS. But the same behaviour and resolution as noted.

dhylands commented 5 years ago

I tried my F4 Discovery board and I was getting intermittent failures. For my first test I was using a201d3e which happens to be the system installed version of stlink (on my machine). Once I got the error mentioned above, mostly I got an unrecognized chip id unless I used --reset on the command line to st-flash.

When it failed, I had to power cycle the board to get it to work again.

My F4 had the V2J14S0 version of stlink. I updated it to V2J28S0 and I didn't get any further failures with the latest master or with version a201d3e

dhylands commented 5 years ago

For completeness, my NUCLEO-L476RG had stlink firmware V2J27M15. Since I had the stlink updater tool running I upgraded to the latest (V2J28M16) and the L476 continued to work with master and a201d3e

kmfarley11 commented 5 years ago

Interesting. My F4 discovery was at V2J25M14. So i got the latest (V2J32M22) from ST's website.

Even after updating my board with that, I still get the flash error when on master. I did pinpoint that 7651d21 seems to be the first commit where I get the error though. All prior work fine (i.e. 358a913 worked). for reference, my exact error from master:

$ st-flash --format ihex write ch.hex
st-flash 1.4.0-58-g6a9d390
2019-01-17T13:45:33 INFO common.c: Loading device parameters....
2019-01-17T13:45:33 INFO common.c: Device connected is: F4 device, id 0x10076413
2019-01-17T13:45:33 INFO common.c: SRAM size: 0x30000 bytes (192 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 16384 bytes
2019-01-17T13:45:33 INFO common.c: Attempting to write 40532 (0x9e54) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08008000 erasedEraseFlash - Sector:0x2 Size:0x4000 
2019-01-17T13:45:34 INFO common.c: Finished erasing 3 pages of 16384 (0x4000) bytes
2019-01-17T13:45:34 INFO common.c: Starting Flash write for F2/F4/L4
2019-01-17T13:45:34 INFO flash_loader.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 32768
2019-01-17T13:45:42 ERROR flash_loader.c: flash loader run error
2019-01-17T13:45:42 ERROR common.c: stlink_flash_loader_run(0x8000000) failed! == -1
stlink_fwrite_flash() == -1
kmfarley11 commented 5 years ago

Also to clarify, it happens every flash attempt and not intermittently. It either works (pre 7651d21), or doesn't. Looking at the code for that commit, not sure why it would be causing any issues. Just reporting observations. ¯\(ツ)/¯

michaelsobczak-qeexo commented 5 years ago

@kmfarley11 same experience, it has 100% failure rate when on the broken revision or later

dmitrystu commented 5 years ago

I have made some compatibility test for the st-flash 1.5.1-12-g30de1b3 (Linux) and some STM boars. Here is a result (32F103 and 32L433 is a bluepill-based boards)

Board ST-LINK FW-VERION SELF STM32F103C8 STM32L433CC
NUCLEO-F303RE V2J28M17 OK OK unknown chip id! 0x5fa0004
NUCLEO-L476RG V2J32M22 flash loader run error OK Invalid flash type
STM32L100C-DISCO V2J32S0 OK OK Invalid flash type

There is no problems when using STM32Cube Programmer software for any combination.

ashesman commented 5 years ago

I have the same issue. Upgraded to latest revision and can no longer flash. It seems to freeze at flashing the first block. It is OK on revision 3eab7b960ff180df5f3678def13dceb4cf7ced93 (1.4.0-49-g3eab7b9). Using custom hardware on ST-Link V2. Sorry I cannot provide any more useful debug information.

Output from latest revision (note, uses a script to erase then flash several binaries): st-flash erase st-flash 1.5.1-12-g30de1b3 2019-02-07T10:24:51 INFO common.c: Loading device parameters.... 2019-02-07T10:24:51 INFO common.c: Device connected is: L4 device, id 0x10076415 2019-02-07T10:24:51 INFO common.c: SRAM size: 0x18000 bytes (96 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes Mass erasing st-flash write build/target/bootloader/platform-12/bootloader.bin 0x08000000 st-flash 1.5.1-12-g30de1b3 2019-02-07T10:24:51 INFO common.c: Loading device parameters.... 2019-02-07T10:24:51 INFO common.c: Device connected is: L4 device, id 0x10076415 2019-02-07T10:24:51 INFO common.c: SRAM size: 0x18000 bytes (96 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes 2019-02-07T10:24:51 INFO common.c: Attempting to write 58348 (0xe3ec) bytes to stm32 address: 134217728 (0x8000000) Flash page at addr: 0x0800e000 erasedEraseFlash - Page:0x1c Size:0x800 2019-02-07T10:24:51 INFO common.c: Finished erasing 29 pages of 2048 (0x800) bytes 2019-02-07T10:24:51 INFO common.c: Starting Flash write for F2/F4/L4 2019-02-07T10:24:51 INFO flash_loader.c: Successfully loaded flash loader in sram size: 32768 2019-02-07T10:24:55 ERROR flash_loader.c: flash loader run error 2019-02-07T10:24:55 ERROR common.c: stlink_flash_loader_run(0x8000000) failed! == -1 stlink_fwrite_flash() == -1 Makefile:23: recipe for target 'install' failed make: *** [install] Error 255

Output from working revision: st-flash erase st-flash 1.4.0-49-g3eab7b9 2019-02-07T10:25:47 INFO common.c: Loading device parameters.... 2019-02-07T10:25:47 INFO common.c: Device connected is: L4 device, id 0x10076415 2019-02-07T10:25:47 INFO common.c: SRAM size: 0x18000 bytes (96 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes Mass erasing st-flash write build/target/bootloader/platform-12/bootloader.bin 0x08000000 st-flash 1.4.0-49-g3eab7b9 2019-02-07T10:25:47 INFO common.c: Loading device parameters.... 2019-02-07T10:25:47 INFO common.c: Device connected is: L4 device, id 0x10076415 2019-02-07T10:25:47 INFO common.c: SRAM size: 0x18000 bytes (96 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes 2019-02-07T10:25:47 INFO common.c: Attempting to write 58348 (0xe3ec) bytes to stm32 address: 134217728 (0x8000000) Flash page at addr: 0x0800e000 erasedEraseFlash - Page:0x1c Size:0x800 2019-02-07T10:25:47 INFO common.c: Finished erasing 29 pages of 2048 (0x800) bytes 2019-02-07T10:25:47 INFO common.c: Starting Flash write for F2/F4/L4 2019-02-07T10:25:47 INFO flash_loader.c: Successfully loaded flash loader in sram size: 32768 size: 25580 2019-02-07T10:25:49 INFO common.c: Starting verification of write complete 2019-02-07T10:25:49 INFO common.c: Flash written and verified! jolly good! st-flash write build/target/hardwaretest/platform-12/hardwaretest.bin 0x08020000 st-flash 1.4.0-49-g3eab7b9 2019-02-07T10:25:49 INFO common.c: Loading device parameters.... 2019-02-07T10:25:49 INFO common.c: Device connected is: L4 device, id 0x10076415 2019-02-07T10:25:49 INFO common.c: SRAM size: 0x18000 bytes (96 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes 2019-02-07T10:25:49 INFO common.c: Attempting to write 97564 (0x17d1c) bytes to stm32 address: 134348800 (0x8020000) Flash page at addr: 0x08037800 erasedEraseFlash - Page:0x6f Size:0x800 2019-02-07T10:25:50 INFO common.c: Finished erasing 48 pages of 2048 (0x800) bytes 2019-02-07T10:25:50 INFO common.c: Starting Flash write for F2/F4/L4 2019-02-07T10:25:50 INFO flash_loader.c: Successfully loaded flash loader in sram size: 32768 size: 32768 size: 32028 2019-02-07T10:25:53 INFO common.c: Starting verification of write complete 2019-02-07T10:25:53 INFO common.c: Flash written and verified! jolly good! st-flash write build/target/application/default/platform-12/application_default.bin 0x08040000 st-flash 1.4.0-49-g3eab7b9 2019-02-07T10:25:54 INFO common.c: Loading device parameters.... 2019-02-07T10:25:54 INFO common.c: Device connected is: L4 device, id 0x10076415 2019-02-07T10:25:54 INFO common.c: SRAM size: 0x18000 bytes (96 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes 2019-02-07T10:25:54 INFO common.c: Attempting to write 201636 (0x313a4) bytes to stm32 address: 134479872 (0x8040000) Flash page at addr: 0x08071000 erasedEraseFlash - Page:0xe2 Size:0x800 2019-02-07T10:25:56 INFO common.c: Finished erasing 99 pages of 2048 (0x800) bytes 2019-02-07T10:25:56 INFO common.c: Starting Flash write for F2/F4/L4 2019-02-07T10:25:56 INFO flash_loader.c: Successfully loaded flash loader in sram size: 32768 size: 32768 size: 32768 size: 32768 size: 32768 size: 32768 size: 5028 2019-02-07T10:26:00 INFO common.c: Starting verification of write complete 2019-02-07T10:26:02 INFO common.c: Flash written and verified! jolly good!

st-flash write build/target/data/device_data/platform-12/data_device_data.bin 0x080?????

st-flash write build/target/data/pan1740_firmware/platform-12/bluetooth_firmware_midb.bin 0x08018000 st-flash 1.4.0-49-g3eab7b9 2019-02-07T10:26:02 INFO common.c: Loading device parameters.... 2019-02-07T10:26:02 INFO common.c: Device connected is: L4 device, id 0x10076415 2019-02-07T10:26:02 INFO common.c: SRAM size: 0x18000 bytes (96 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes 2019-02-07T10:26:02 INFO common.c: Attempting to write 18144 (0x46e0) bytes to stm32 address: 134316032 (0x8018000) Flash page at addr: 0x0801c000 erasedEraseFlash - Page:0x38 Size:0x800 2019-02-07T10:26:02 INFO common.c: Finished erasing 9 pages of 2048 (0x800) bytes 2019-02-07T10:26:02 INFO common.c: Starting Flash write for F2/F4/L4 2019-02-07T10:26:02 INFO flash_loader.c: Successfully loaded flash loader in sram size: 18144 2019-02-07T10:26:03 INFO common.c: Starting verification of write complete 2019-02-07T10:26:03 INFO common.c: Flash written and verified! jolly good! st-flash reset st-flash 1.4.0-49-g3eab7b9 2019-02-07T10:26:03 INFO common.c: Loading device parameters.... 2019-02-07T10:26:03 INFO common.c: Device connected is: L4 device, id 0x10076415 2019-02-07T10:26:03 INFO common.c: SRAM size: 0x18000 bytes (96 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes

xor-gate commented 5 years ago

Dear all, I would like you to help out and skim through multiple revisions since latest release so we can pinpoint the exact PR which causes the problem.

https://github.com/texane/stlink/compare/v1.5.1...master

Git bisect could be used for finding the regression:

https://git-scm.com/docs/git-bisect https://git-scm.com/docs/git-bisect-lk2009.html

Thanks all for the feedback, and sorry for the inconvenience latest master is broken. Never ever expect latest develop to work. Releases should 😃

dhylands commented 5 years ago

It was commit 7651d211 which caused the problem. The issue is that the chip ID for the F401 is 0x2ba01477 which appears to be the same as the CS32_CORE_ID and this causes the incorrect flash loader to be loaded onto the F4.

While looking into this I noticed that the code which prints which flash type was detected: https://github.com/texane/stlink/blob/b9c315d990abfde3008a917e767c63d2c1c1ddf2/src/common.c#L1944 uses different logic from the code which actually does the flashing: https://github.com/texane/stlink/blob/b9c315d990abfde3008a917e767c63d2c1c1ddf2/src/flash_loader.c#L253 so it says it's flashing an F4 but it loads the flash loader for the VL

rojer commented 5 years ago

@dhylands thank you very much! i don't know what this CS32 thing is but it breaks flashing of STM32F2.

VictorLamoine commented 5 years ago

Sorry about the trouble. What should be done to support both the CS32 and the STM32F2 / F401 if they share the same chip id but don't require the same flashing method?

rojer commented 5 years ago

@VictorLamoine i don't have the slightest idea. please revert the change to fix the regression, then figure it out.

VictorLamoine commented 5 years ago

You can revert the commit locally on your machine: git revert 7651d2116fd74c7803ea00ab1da7cf3d00faf44c.

I'm not a maintainer so I can't revert on the repository.

ag88 commented 5 years ago

i'd like to suggest that the manufacturer be made available as a command line option if possible. i.e. the default would be stm32 and that to flash cs32 a manufacturer option would be necessary the reasoning is that stm32 'clones' may detour from being 'fully compatible' with stm32 as things evolves

xor-gate commented 5 years ago

@ag88 totaly agree, the texane/stlink project aims to support ST Microelectronics products and to be compatible with clones without breaking existing things. The problem with clones on the same IDs with different flash handling etcetera involves a lot of hacking. Also the current implementation is also not very clean (compared to flexible OpenOCD tcl scripts). There are a lot of conditional checks all around the flash loader code for different scenarios which could be simplified (eg look at pystlink)

xor-gate commented 5 years ago

Hi all,

I have reverted the CS32 commit. Could you verify it works again?

Kind regards, Jerry

michaelsobczak-qeexo commented 5 years ago

@xor-gate works for me now on the latest master. Thank you everyone for the help!

xor-gate commented 5 years ago

@michaelsobczak-qeexo thanks for verify! Sorry for the long delays and inconvenience.

VictorLamoine commented 5 years ago

It's not very clear whether this CS32 chip is an illegal clone or a partnership between ST and the CSK Chinese manufacturing company. Discussion here: http://stm32duino.com/viewtopic.php?f=3&t=4522, article here https://www.cnx-software.com/2019/02/10/cs32-mcu-stm32-clone-bluepill-board/

xor-gate commented 5 years ago

Thanks all, i'm closing this issue now because it has been fixed by reverting commit 7651d2116fd74c7803ea00ab1da7cf3d00faf44c

xor-gate commented 5 years ago

If we still want support for CS32 microcontrollers we must find a more reliable solution, feel free to file an issue if we want to.

Nightwalker-87 commented 4 years ago

Fixed in the following commits: 1st fix: 3295ab4e5cf05cb546856414f1d40b5deedcf219, 2nd fix: f5d0454ab0a18f209ad5b7d0d51f3945b27dd892 (master-branch) and b40c2436b68a35544a1eae10f4b6a3de7648a566 (develop-branch) .

michaelsobczak-qeexo commented 4 years ago

Thanks!