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

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.

  • Programmer/board type: stlink/v2
  • Programmer firmware version: Not sure
  • Operating system: Mac OS X
  • Stlink tools version and/or git commit hash: 6a9d390a729f381ecec45f212354bfe98e27790f
  • Stlink commandline tool name: st-flash
  • Target chip (and optional board): STM32L476JG (STSW-STLKT01V1)

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

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 27 (17 by maintainers)

Commits related to this issue

Most upvoted comments

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

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/

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