stlink-org
Attempting to flash to STM32L052K8 corrupts flash memory
- [X] Programmer/board type: Stlink/v2
- [X] Programmer firmware version: Unknown; generic St-link module.
- [X] Operating system: Linux (Ubuntu 16.04)
- [X] Stlink tools version and/or git commit hash: v1.5.0
- [X] Stlink commandline tool name: st-util
- [X] Target chip (and optional board): STM32L051K8
Attempting to flash a .elf to the chip results in a series of errors indicating an STM32L1 loader is being used (quoted further down), and subsequent connections fail with the following strange error message:
2018-03-08T23:04:41 WARN common.c: Invalid flash type, please check device declaration
2018-03-08T23:04:41 INFO gdb-server.c: Chip ID is 00000000, Core ID is 0bc11477.
That state persists until the chip is 'fixed' by connecting to it during a hardware reset via ST's ST-Link Utility on a Windows machine. Here is the output that st-util gives during the problematic flashing operation:
st-util 1.5.0
2018-03-08T23:04:03 INFO usb.c: -- exit_dfu_mode
2018-03-08T23:04:03 INFO common.c: Loading device parameters....
2018-03-08T23:04:03 INFO common.c: Device connected is: L0x3 device, id 0x10386417
2018-03-08T23:04:03 INFO common.c: SRAM size: 0x2000 bytes (8 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 128 bytes
2018-03-08T23:04:03 INFO gdb-server.c: Chip ID is 00000417, Core ID is 0bc11477.
2018-03-08T23:04:03 INFO gdb-server.c: Listening at *:4242...
2018-03-08T23:04:13 INFO gdb-server.c: Found 4 hw breakpoint registers
2018-03-08T23:04:13 INFO gdb-server.c: GDB connected.
2018-03-08T23:04:14 INFO common.c: Attempting to write 128 (0x80) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08000000 erased
2018-03-08T23:04:14 INFO common.c: Finished erasing 1 pages of 128 (0x80) bytes
2018-03-08T23:04:14 INFO common.c: Starting Half page flash write for STM32L core id
2018-03-08T23:04:14 INFO flash_loader.c: Successfully loaded flash loader in sram
2018-03-08T23:04:17 ERROR flash_loader.c: flash loader run error
2018-03-08T23:04:17 WARN common.c: l1_stlink_flash_loader_run(0x8000000) failed! == -1
2018-03-08T23:04:17 WARN common.c:
write_half_pages failed == -1
0/ 1 pages written
2018-03-08T23:04:17 INFO common.c: Starting verification of write complete
2018-03-08T23:04:17 INFO common.c: Flash written and verified! jolly good!
2018-03-08T23:04:17 INFO common.c: Attempting to write 128 (0x80) bytes to stm32 address: 134217856 (0x8000080)
Flash page at addr: 0x08000080 erased
2018-03-08T23:04:17 INFO common.c: Finished erasing 1 pages of 128 (0x80) bytes
2018-03-08T23:04:17 INFO common.c: Starting Half page flash write for STM32L core id
2018-03-08T23:04:17 INFO flash_loader.c: Successfully loaded flash loader in sram
2018-03-08T23:04:20 ERROR flash_loader.c: flash loader run error
2018-03-08T23:04:20 WARN common.c: l1_stlink_flash_loader_run(0x8000080) failed! == -1
2018-03-08T23:04:20 WARN common.c:
write_half_pages failed == -1
0/ 1 pages written
2018-03-08T23:04:21 INFO common.c: Starting verification of write complete
2018-03-08T23:04:21 INFO common.c: Flash written and verified! jolly good!
[ ... repeats a few times ... ]
Expected/description: The program should flash susccessfully. But despite reporting success, when I try to step through it in GDB, the chip jumps directly from the reset location to 0x20000010. So I gotta figure that something went wrong somewhere.
Thats a weird problem, I could not immediate tell what causes the problem. I think the L1 loader is compatible with the L0 chips as they are almost the same.
It does seem a little strange - let me know if there are any debug flags or something that I should turn on to provide more information.
Try flashing a flat binary with st-flash rather than an elf.
Try reading back the flash to a file and comparing, or examining it with gdb, or example x/32x 0x8000000
You should see the start of your vector table... Where did your binary come from, and how do you know it is good?
Also given that your address seems to be in RAM, what is the state of your BOOT pin?
I'll take a look - I've been meaning to learn how to flash .bin files instead of uploading .elf's with a debugger, anyways.
The code was one of ST's examples, but I'll take another look at where the vector table is located.
The BOOT0 pin is pulled to ground, so I don't think it should be booting into RAM.
I'll get back on those questions within a day or two - thank you for the advice!
Alright, I tried flashing the L0 test program (specifically, ST's LSI initialization example) to an L031K6 Nucleo-32 board, and that works fine.
On the L051K8, however, I still observe the issue. The main difference is that I am using a generic USB dongle to program the L051K8 board, and the onboard ST-Link/V2-1 debugger for the L031K6 Nucleo board. I tried updating the firmware on the USB debugger, but that didn't help.
I verified that the vector table is correctly placed with arm-eabi-none-nm in both cases: 08000000 R g_pfnVectors
Flashing a .bin file to the L051K8 with st-flash write main.bin 0x08000000 throws an error but still reports success. Connecting to the chip afterwards shows that the program is stuck at 0xFFFFFFFE, though.
Here is the output from st-flash:
st-flash 1.5.0
2018-04-23T23:26:42 INFO common.c: Loading device parameters....
2018-04-23T23:26:42 INFO common.c: Device connected is: L0x3 device, id 0x10386417
2018-04-23T23:26:42 INFO common.c: SRAM size: 0x2000 bytes (8 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 128 bytes
2018-04-23T23:26:42 INFO common.c: Ignoring 4 bytes of 0x00 at end of file
2018-04-23T23:26:42 INFO common.c: Attempting to write 18404 (0x47e4) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08004780 erased
2018-04-23T23:26:43 INFO common.c: Finished erasing 144 pages of 128 (0x80) bytes
2018-04-23T23:26:43 INFO common.c: Starting Half page flash write for STM32L core id
2018-04-23T23:26:43 INFO flash_loader.c: Successfully loaded flash loader in sram
2018-04-23T23:26:46 ERROR flash_loader.c: flash loader run error
2018-04-23T23:26:46 WARN common.c: l1_stlink_flash_loader_run(0x8000000) failed! == -1
2018-04-23T23:26:46 WARN common.c:
write_half_pages failed == -1
142/143 pages written
2018-04-23T23:27:03 INFO common.c: Starting verification of write complete
2018-04-23T23:27:04 INFO common.c: Flash written and verified! jolly good!
But looking at the Flash memory with ST's GUI utility, I do see the .bin file's hex starting at 0x08000000; it looks like the vector table at the start of the program. And the written memory looks like it ends at 0x080047E0, which seems right for the size of the program.
I dunno - if this isn't something that anyone else can replicate, I suppose that it could be the chips or boards that I'm using.
Hi,
Same issue with blue-pill board (STM32F103C8X) After every program with 'arm-none-eabi-gdb', I got successful, the program run well in the board but when I try to program it again I got theses issues:
st-util
[abdullatif@Host-001 ~]$ st-util st-util 1.5.0 2018-05-04T23:47:27 INFO common.c: Loading device parameters.... 2018-05-04T23:47:27 WARN common.c: Invalid flash type, please check device declaration 2018-05-04T23:47:27 INFO gdb-server.c: Chip ID is 00000000, Core ID is 00000000. 2018-05-04T23:47:27 INFO gdb-server.c: Listening at *:4242... 2018-05-04T23:47:40 INFO gdb-server.c: Found 0 hw breakpoint registers 2018-05-04T23:47:40 INFO gdb-server.c: GDB connected.
gdb
[abdullatif@Host-001 build]$ arm-none-eabi-gdb Stm32blink.elf GNU gdb (GDB) 8.1 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-pc-linux-gnu --target=arm-none-eabi". Type "show configuration" for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from Stm32blink.elf...done. (gdb) target extended-remote :4242 Remote debugging using :4242 0x00000000 in ?? () (gdb) load Loading section .isr_vector, size 0x10c lma 0x8000000 Load failed (gdb)
I have to flash the bootloader with 'st-flash' if I what the board to work again.
I'm not convinced that that F103 issue is the same as what I've been seeing; it seems fairly well-supported by this tool, and the L0 issue occurs even on a blank chip.
The original title of this issue was incorrect, sorry; the behavior occurs on the following two devices:
-
STM32L052K8
-
STM32L082KZ
I looked at src/chipid.c and saw that only the reference manuals for L0x1 and L0x3 chips were referenced for the settings; could L0x2 chips have any major differences?
The following diff appears to completely resolve this issue for me (with an STM32L052K8), but I am guessing that it is not an ideal solution:
diff --git a/src/common.c b/src/common.c
index b9b7382..7d2480d 100644
--- a/src/common.c
+++ b/src/common.c
@@ -1647,7 +1647,8 @@ int stlink_erase_flash_page(stlink_t *sl, stm32_addr_t flashaddr)
}
int stlink_erase_flash_mass(stlink_t *sl) {
- if (sl->flash_type == STLINK_FLASH_TYPE_L0) {
+ //if (sl->flash_type == STLINK_FLASH_TYPE_L0) {
+ if (sl->chip_id == STLINK_CHIPID_STM32_L0_CAT2 || sl->chip_id == STLINK_CHIPID_STM32_L0_CAT5) {
/* erase each page */
int i = 0, num_pages = (int) sl->flash_size/sl->flash_pgsz;
for (i = 0; i < num_pages; i++) {
That change removes the L0-specific behavior for mass-erasing from chips that are identified with the generic L0x3 label associated with ID 0x0417.
I don't know why the L0-specific logic might be causing issues with these 'Category-3' L0x2 chips; it seems to work fine with an STM32L031 Nucleo board, where the chip has an ID of 0x0425 which identifies as a 'Category-2' device.
Having Similar issues with an STM32L151CC. It throws the same error and fails on verification step. Validating the memory manually with ST-Link Utility shows the flash is written correctly. No read/write protection is set on the device.
st-flash --reset write 'build/bin'/uartbridge-mbiot.bin 0x08000000
st-flash 1.4.0-57-g7651d21
2019-02-28T09:33:08 INFO common.c: Loading device parameters....
2019-02-28T09:33:08 INFO common.c: Device connected is: L1 Medium-Plus-density device, id 0x10f86427
2019-02-28T09:33:08 INFO common.c: SRAM size: 0x8000 bytes (32 KiB), Flash: 0x40000 bytes (256 KiB) in pages of 256 bytes
2019-02-28T09:33:08 INFO common.c: Attempting to write 14376 (0x3828) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08003800 erased
2019-02-28T09:33:08 INFO common.c: Finished erasing 57 pages of 256 (0x100) bytes
2019-02-28T09:33:08 INFO common.c: Starting Half page flash write for STM32L core id
2019-02-28T09:33:08 INFO flash_loader.c: Successfully loaded flash loader in sram
2019-02-28T09:33:12 ERROR flash_loader.c: flash loader run error
2019-02-28T09:33:12 WARN common.c: l1_stlink_flash_loader_run(0x8000000) failed! == -1
2019-02-28T09:33:12 WARN common.c:
write_half_pages failed == -1
55/ 56 pages written
2019-02-28T09:33:25 INFO common.c: Starting verification of write complete
2019-02-28T09:33:25 ERROR common.c: Verification of flash failed at offset: 0
stlink_fwrite_flash() == -1
@WRansohoff: Please verify if the problem still exists in Release v1.5.1.
Sure, happy to check whether this still happens with STM32L0 category-2 chips.
Most of my boards are in storage atm though, so I probably won't be able to do it until I finish moving in May. Sorry about that.
Try to erase flash of your MCU Use this article: https://electronics.stackexchange.com/questions/204996/stm32-st-link-cannot-connect-to-mcu-after-successful-programming
Maybe you forgot to mark SWD /JTAG pins at STM32Cube
@Nightwalker-87 Sorry, I have no boards with L series chip. The problem here is strange, a quick look at the code and reading the documentation did not give any results.
Anyone else? Indeed there are still a few L-related other tickets as well, so folks with such boards would clearly help.
I'm also experiencing an issue when trying to flash many boards using st-flash 1.6.1.
Seems to default to very slow page write. ERROR flash_loader.c: flash loader run error WARN common.c: l1_stlink_flash_loader_run(0x8000000) failed! == -1 WARN common.c: write_half_pages failed == -1 452/453 pages written
@V1DEOJAMES Can you try https://github.com/Ant-ON/stlink/tree/fl_fix branch?
Apologies, my issue ended up being unrelated and was solved by using a different programming board (previous one was damaged by a bad USB hub). I did test the branch at the time but it made no difference for me.
Ok, so your observations were obviously not related to this issue. Thx for the feedback. :+1:
@wolsty7 Can you try to reproduce this issue with your hardware using older versions of the toolset if you find some time? We are still trying to figure out if this issue has been fixed already and where... As far as I'm concerned we were limited on hardware from the L-series needed for testing. Any help would be greatly appreciated.
I see. However thanks for the feedback. Feel free to take a look at other issues if you fancy to do so. :+1:
I have spotted a false bootrom_base hex address for the L0 series.
According to the viewed reference manuals the is a missing digit: 0x1ff0000 --> 0x1ff00000
This appears to affect other L0-chips as well. Please check chipid.c.
DEVICE: NUCLEO-H7A3ZI-Q
Reproduction st-util -v99
st-util 1.7.0-186-gc4762e6-dirty
Failed to parse flash type or unrecognized flash type
2022-05-06T21:34:59 DEBUG common.c: *** looking up stlink version
2022-05-06T21:34:59 DEBUG common.c: st vid = 0x0483 (expect 0x0483)
2022-05-06T21:34:59 DEBUG common.c: stlink pid = 0x374e
2022-05-06T21:34:59 DEBUG common.c: stlink version = 0x3
2022-05-06T21:34:59 DEBUG common.c: jtag version = 0x9
2022-05-06T21:34:59 DEBUG common.c: swim version = 0x0
2022-05-06T21:34:59 DEBUG common.c: stlink current mode: mass
Resolution Running "st-flash --connect-under-reset erase 0x08000000 0x2000" and then and restarting device. Note: uploading new elf with --connect-under-reset did not help.
The culprit that appeared to cause this was the "Examples/FLASH/FLASH_EraseProgram" project in the nucleo repo area.
I have spotted a false
bootrom_basehex address for the L0 series. According to the viewed reference manuals the is a missing digit:0x1ff0000-->0x1ff00000This appears to affect other L0-chips as well. Please checkchipid.c.
In order to finally resolve this issue in this context it would be great to verify this with the L052K8 however. Well possible that there were several reasons for this to appear.
I am having this same issue on an STM32L072CZ flashed through another nucleo's ST-Link.
When I try to start st-util --no-reset I get:
Unsupported Target (Chip ID is 0000000000, Core ID is 0x0bc11477).
But when I try the same command without --no-reset it works just fine.
Also, when I try loading an elf cortex-debug (a vscode extension) I get this error:
2022-10-17T19:16:41 INFO common.c: Starting Flash write for L0
2022-10-17T19:16:41 INFO gdb-server.c: flash_do: block 08000000 -> c400
2022-10-17T19:16:41 INFO gdb-server.c: flash_do: page 08000000
2022-10-17T19:16:41 INFO common.c: Starting Half page flash write for STM32L core id
2022-10-17T19:16:41 INFO flash_loader.c: Successfully loaded flash loader in sram
2022-10-17T19:16:41 INFO flash_loader.c: Clear DFSR
2022-10-17T19:16:42 ERROR flash_loader.c: Flash loader run error
2022-10-17T19:16:42 WARN flash_loader.c: Loader state: R2 0x0 R15 0x8006674
2022-10-17T19:16:42 WARN flash_loader.c: MCU state: DHCSR 0x1080009 DFSR 0x0 CFSR 0x0 HFSR 0x0
2022-10-17T19:16:42 WARN common.c: l1_stlink_flash_loader_run(0x8000000) failed! == -1
2022-10-17T19:16:42 WARN common.c:
write_half_pages failed == -1
@BRA1L0R Your problem is documented in #1203. As far as I can tell it's not related to this issue.
@chenguokai Hi there. I've reviewed this issue and found that the observed behaviour is related to the flash-loader implementation you contributed in 2020 (which I believe is a very valuable contribution to this project). Would you be interested to look into this topic and some obviously related issues? I'd also appreciate to get in touch with you to find out more regarding the technical background of your implementation.
I'm seeing possibly the same issue on my STM32L010F4 MCU. I'm debugging it through a NUCLEO-L010RB (with the STLINK programmer broken off) on a mac 13.3.1, with stlink v1.7.0 installed via Homebrew.
Here's a minimal repro in a gist along with the terminal output. When the final MOV is commented out everything works and I get the Flash written and verified! jolly good! in the end of the st-flash --format ihex write minimal.hex command. If the 28th MOV is uncommented, I can reliably get the Flash loader run error.
This happens with the BOOT0 pin in both 0 and 1 configuration (since someone asked above). And, importantly, if I take the failing minimal.hex and use the STM32CubeProgrammer to flash it there are no issues. Happy to try things out on this hardware.
@nemtsov Thanks for the helpful feedback. I'll look into this in more detail during the following weekend. It may be a good advice to locate the lines of interest in the source code, starting from the received output message in order to trace it back to the root.