Stlink: Attempting to flash to STM32L052K8 corrupts flash memory

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.

@WRansohoff: Any update on this?

Hi, i have the same issue with STM32L433RC.
I'm using st-util 1.6.1

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