Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Attempting to flash to STM32L052K8 corrupts flash memory #681

Closed
6 tasks done
WRansohoff opened this issue Mar 9, 2018 · 56 comments · Fixed by #1330
Closed
6 tasks done

Attempting to flash to STM32L052K8 corrupts flash memory #681

WRansohoff opened this issue Mar 9, 2018 · 56 comments · Fixed by #1330

Comments

@WRansohoff
Copy link
Contributor

  • Programmer/board type: Stlink/v2
  • Programmer firmware version: Unknown; generic St-link module.
  • Operating system: Linux (Ubuntu 16.04)
  • Stlink tools version and/or git commit hash: v1.5.0
  • Stlink commandline tool name: st-util
  • 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.

@xor-gate
Copy link
Member

xor-gate commented Mar 9, 2018

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.

@xor-gate xor-gate added this to the Unplanned (Contributions Welcome) milestone Mar 9, 2018
@WRansohoff
Copy link
Contributor Author

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.

@cstratton
Copy link

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?

@WRansohoff
Copy link
Contributor Author

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!

@WRansohoff
Copy link
Contributor Author

WRansohoff commented Apr 24, 2018

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.

@bourou01
Copy link

bourou01 commented May 4, 2018

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.

@WRansohoff
Copy link
Contributor Author

WRansohoff commented May 12, 2018

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?

@WRansohoff WRansohoff changed the title Attempting to flash to STM32L051K8 corrupts flash memory Attempting to flash to STM32L052K8 corrupts flash memory May 12, 2018
@WRansohoff
Copy link
Contributor Author

WRansohoff commented May 12, 2018

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.

@jakeypoo
Copy link

jakeypoo commented Feb 28, 2019

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

@Nightwalker-87 Nightwalker-87 modified the milestones: Unplanned (Contributions Welcome), Next Feb 19, 2020
@Nightwalker-87 Nightwalker-87 modified the milestones: General, Feedback required Feb 21, 2020
@Nightwalker-87 Nightwalker-87 self-assigned this Feb 21, 2020
@Nightwalker-87
Copy link
Member

@WRansohoff: Please verify if the problem still exists in Release v1.5.1.

@WRansohoff
Copy link
Contributor Author

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.

@Nightwalker-87 Nightwalker-87 removed their assignment Jun 3, 2020
@Nightwalker-87 Nightwalker-87 removed this from the a) Old issues milestone Jul 21, 2020
@Nightwalker-87
Copy link
Member

@WRansohoff @jakeypoo @Mk-arc @nemtsov @mynameisdaniil
Please try to do the tests within the upcoming 2 weeks, if possible, in order to proceed.

@Mk-arc
Copy link

Mk-arc commented Jun 23, 2023

Hi all.

I did some testing. First of all my Setup:

image

CPU: STM32L063R8Tx with following connections:

Debugger:
image

uC:
image

First of all. I double checked that its possible to download my program using a J-Link debugger. Which works fine. Then furthermore, I tested with the ST-Link V2 in the picture above using STM32CubeProgrammer, which also works fine. Thus, I am pretty confident that the Hardware is fine.

Now to st-link:
I checked out: d4b53b0

 ./st-flash --version
v1.7.0-294-gd4b53b0
./st-info  --probe
/usr/local/share//stlink/chips: No such file or directory
Found 1 stlink programmers
version:    V2J29S7
serial:     680056000A0000385134534E
flash:      0 (pagesize: 0)
sram:       0
chipid:     0x417

This is interesting now... It seems to not proberly detect the chip when I run the same with st-link installed from the ubuntu package repository I get different results:

st-info --version
v1.7.0
st-info  --probe
Found 1 stlink programmers
version:    V2J29S7
serial:     680056000A0000385134534E
flash:      65536 (pagesize: 128)
sram:       8192
chipid:     0x0417
descr:      L0x3

Not sure how to continue with the actual flashing test. Since its failing now even earlier?

@Nightwalker-87
Copy link
Member

Nightwalker-87 commented Jun 23, 2023

@Mk-arc I don't see this on the F1, F4, G4 boards when using the same programmer (ST-Link v2 Clone) I have, so it can not be a general problem. However I noticed that your Programmer-Firmware is quite old. You may want to update it with the official STM32CubeProgrammer...

Note also: /usr/local/share//stlink/chips: No such file or directory
You have a corrupted installation. This should not appear. I assume there are leftovers from a previous compile.
Run sudo make uninstall && sudo make clean and check /usr/local/share/ for any leftovers before continuing...

@Mk-arc
Copy link

Mk-arc commented Jun 23, 2023

@Nightwalker-87

Thanks for the quick response. I updated the FW:

Repo-version

st-info  --probe
Found 1 stlink programmers
  version:    V2J40S7
  serial:     680056000A0000385134534E
  flash:      65536 (pagesize: 128)
  sram:       8192
  chipid:     0x0417
  descr:      L0x3

Fresh compiled:

./st-info --probe
/usr/local/share//stlink/chips: No such file or directory
Found 1 stlink programmers
 version:    V2J40S7
 serial:     680056000A0000385134534E
 flash:      0 (pagesize: 0)
 sram:       0
 chipid:     0x417

There is nothing relating to st-link in /usr/local/share. Also make uninstall does not work:

CMake Error at cmake/cmake_uninstall.cmake:2 (message):
  Cannot find install manifest:
  <name>/git/stlink/build/install_manifest.txt


make[3]: *** [CMakeFiles/uninstall.dir/build.make:70: CMakeFiles/uninstall] Error 1
make[2]: *** [CMakeFiles/Makefile2:394: CMakeFiles/uninstall.dir/all] Error 2
make[1]: *** [CMakeFiles/Makefile2:401: CMakeFiles/uninstall.dir/rule] Error 2
make: *** [Makefile:267: uninstall] Error 

@Nightwalker-87
Copy link
Member

Nightwalker-87 commented Jun 23, 2023

@Mk-arc Something is not correct here. Make sure you don't have repo version and compiled variant installed at the same time - this may likely not work. I'd recommend to uninstall the package version, then delete the /build folder in your local project and restart compiling: sudo make clean && sudo make install && sudo make uninstall. Then ensure that there is no folder stlink in /usr/local/share and that there is nothing related left in /usr/local/bin, /usr/local/include and /usr/local/lib. Then run sudo make clean && sudo make install. --> What happens?

@Mk-arc
Copy link

Mk-arc commented Jun 23, 2023

@Nightwalker-87

I uninstalled the package version and did what you recommend.

Now its different but still not okay:

First of all. for some reason I can now not access the device without root.

./st-info --probe
2023-06-23T22:52:31 ERROR usb.c: Could not open USB device 0x0483:0x3748, access error.
Found 0 stlink programmers

And its still not properly detecting the probe.

sudo ./st-info --probe
Found 1 stlink programmers
  version:    V2J40S7
  serial:     680056000A0000385134534E
  flash:      0 (pagesize: 0)
  sram:       0
  chipid:     0x417

@Nightwalker-87
Copy link
Member

Packages libusb-1.0 and libusb-1.0-0-dev are present?

@Mk-arc
Copy link

Mk-arc commented Jun 23, 2023

Yes. I will try tomorrow late evening on another computer. Maybe something is skewed in my system.

@Nightwalker-87
Copy link
Member

Nightwalker-87 commented Jun 23, 2023

Check /doc/compiling.md also --> Section: "Set device access permissions and the role of udev"
and make sure your user is member of the group plugdev.

@Mk-arc
Copy link

Mk-arc commented Jun 24, 2023

@Nightwalker-87 thanks for all the help. I now retried at another computer and there the probe gets detected properly and I can now reproduce the actual problem we are discussing in this issue:

~/git/stlink/build/bin/st-flash write ./STM32L0Breakout.bin 0x08000000
st-flash 1.7.0-11-ge662da0
2023-06-24T14:48:36 INFO common.c: L0x3: 8 KiB SRAM, 64 KiB flash in at least 128 byte pages.
file ./STM32L0Breakout.bin md5 checksum: e730ae43d067d1d3c98cffce13b5f8, stlink checksum: 0x0015e02c
2023-06-24T14:48:36 INFO common.c: Attempting to write 16056 (0x3eb8) bytes to stm32 address: 134217728 (0x8000000)
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08000000 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08000080 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08000100 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08000180 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08000200 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08000280 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08000300 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08000380 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08000400 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08000480 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08000500 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08000580 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08000600 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08000680 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08000700 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08000780 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08000800 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08000880 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08000900 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08000980 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08000a00 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08000a80 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08000b00 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08000b80 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08000c00 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08000c80 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08000d00 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08000d80 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08000e00 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08000e80 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08000f00 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08000f80 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08001000 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08001080 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08001100 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08001180 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08001200 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08001280 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08001300 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08001380 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08001400 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08001480 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08001500 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08001580 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08001600 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08001680 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08001700 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08001780 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08001800 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08001880 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08001900 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08001980 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08001a00 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08001a80 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08001b00 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08001b80 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08001c00 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08001c80 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08001d00 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08001d80 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08001e00 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08001e80 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08001f00 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08001f80 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08002000 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08002080 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08002100 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08002180 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08002200 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08002280 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08002300 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08002380 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08002400 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08002480 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08002500 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08002580 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08002600 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08002680 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08002700 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08002780 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08002800 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08002880 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08002900 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08002980 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08002a00 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08002a80 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08002b00 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08002b80 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08002c00 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08002c80 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08002d00 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08002d80 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08002e00 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08002e80 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08002f00 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08002f80 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08003000 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08003080 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08003100 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08003180 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08003200 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08003280 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08003300 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08003380 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08003400 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08003480 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08003500 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08003580 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08003600 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08003680 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08003700 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08003780 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08003800 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08003880 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08003900 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08003980 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08003a00 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08003a80 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08003b00 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08003b80 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08003c00 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08003c80 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08003d00 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08003d80 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08003e00 erased
2023-06-24T14:48:36 INFO common.c: Flash page at addr: 0x08003e80 erased
2023-06-24T14:48:36 INFO common.c: Finished erasing 126 pages of 128 (0x80) bytes
2023-06-24T14:48:36 INFO common.c: Starting Flash write for L0
2023-06-24T14:48:36 INFO common.c: Starting Half page flash write for STM32L core id
2023-06-24T14:48:36 INFO flash_loader.c: Successfully loaded flash loader in sram
2023-06-24T14:48:36 INFO flash_loader.c: Clear DFSR
2023-06-24T14:48:37 ERROR flash_loader.c: Flash loader run error
2023-06-24T14:48:37 WARN flash_loader.c: Loader state: R2 0x0 R15 0x0
2023-06-24T14:48:37 WARN flash_loader.c: MCU state: DHCSR 0x1080009 DFSR 0x0 CFSR 0x0 HFSR 0x0
2023-06-24T14:48:37 WARN common.c: l1_stlink_flash_loader_run(0x8000000) failed! == -1
2023-06-24T14:48:37 WARN common.c: 
write_half_pages failed == -1

After the last entry the program freezes and has to be terminated.

Interestingly after this the ST-Link V2 clone probe was somehow in a broken state. Even after power cycle it was not being detected properly. Just after reuploading new FW with STM32CubeProgrammer it started working again.

~/git/stlink/build/bin/st-info --probe
Found 1 stlink programmers
  version:    V2J40S7
  serial:     680056000A0000385134534E
  flash:      65536 (pagesize: 128)
  sram:       8192
  chipid:     0x0417
  descr:      L0x3
``

@Nightwalker-87
Copy link
Member

Nightwalker-87 commented Jun 24, 2023

st-flash 1.7.0-11-ge662da0

--> You have checked out the master branch instead of develop.
Run sudo make uninstall && sudo make clean, then switch to develop, and retry...

@Mk-arc
Copy link

Mk-arc commented Jun 24, 2023

tested with develop branch. WITHOUT applying the patch.

~/git/stlink/build/bin/st-flash write ./STM32L0Breakout.bin 0x08000000
st-flash 1.7.0-294-gd4b53b0
2023-06-24T21:14:05 INFO common.c: STM32L0xxx_Cat_3: 8 KiB SRAM, 64 KiB flash in at least 128 byte pages.
file ./STM32L0Breakout.bin md5 checksum: e730ae43d067d1d3c98cffce13b5f8, stlink checksum: 0x0015e02c
2023-06-24T21:14:05 INFO common_flash.c: Attempting to write 16056 (0x3eb8) bytes to stm32 address: 134217728 (0x8000000)
-> Flash page at 0x8003e80 erased (size: 0x80)
2023-06-24T21:14:06 INFO flash_loader.c: Starting Flash write for L0
2023-06-24T21:14:06 INFO flash_loader.c: Successfully loaded flash loader in sram
2023-06-24T21:14:06 INFO flash_loader.c: Clear DFSR
2023-06-24T21:14:06 ERROR flash_loader.c: write_buffer_to_sram() == -1
2023-06-24T21:14:06 WARN flash_loader.c: Failed to use flash loader, fallback to soft write
250/250 halfpages written
2023-06-24T21:14:07 INFO common_flash.c: Starting verification of write complete
2023-06-24T21:14:07 INFO common_flash.c: Flash written and verified! jolly good!
``

@Nightwalker-87
Copy link
Member

Nightwalker-87 commented Jun 24, 2023

@Mk-arc Thanks, we are making progress. 👌
Let me analyse the remaining inconsistency.

Could you re-run the above with the --debug option?
You can either clip the lengthy output or use pastebin.com.
As there is only a temporary need, you may also set an expiry date.

@Nightwalker-87
Copy link
Member

Nightwalker-87 commented Jun 24, 2023

We're looking at common.c L811ff now:

int32_t write_buffer_to_sram(stlink_t *sl, flash_loader_t *fl, const uint8_t *buf, uint32_t size) {
  // write the buffer right after the loader
  int32_t ret = 0;
  uint32_t chunk = size & ~0x3;
  uint32_t rem = size & 0x3;

  if (chunk) {
    memcpy(sl->q_buf, buf, chunk);
    ret = stlink_write_mem32(sl, fl->buf_addr, (uint16_t)chunk);
  }

  if (rem && !ret) {
    memcpy(sl->q_buf, buf + chunk, rem);
    ret = stlink_write_mem8(sl, (fl->buf_addr) + chunk, (uint16_t)rem);
  }

  return (ret);
}

...asking ourselves under which circumstances this function would return an error: ret == -1 🤔

... which is the case for (read_write.c L49ff):

int32_t stlink_write_mem32(stlink_t *sl, uint32_t addr, uint16_t len) {
  DLOG("*** stlink_write_mem32 %u bytes to %#x\n", len, addr);

  if (len % 4 != 0) {
    ELOG("Data length doesn't have a 32 bit alignment: +%d byte.\n", len % 4);
    return (-1);
  }

  return (sl->backend->write_mem32(sl, addr, len));
}

@Ant-ON is this really a bug? What's your say on this implementation/handling?
The ELOG message did not show up in the output above though, so there must be a different cause.

@mynameisdaniil
Copy link

mynameisdaniil commented Jun 27, 2023

@Nightwalker-87 just tested current testing branch (8fad9be) and develop (d4b53b0). Release bulds on linux@amd64, libusb 1.0.23. STM32L152CCT (detected as STM32L0xxx_Cat_3) onboard stlink V2J21S5 (stm32l0538-disco board). I was unable to successfully flash this chip.

st-flash 1.7.0-294-gd4b53b0
2023-06-28T01:34:01 INFO common.c: STM32L0xxx_Cat_3: 8 KiB SRAM, 64 KiB flash in at least 128 byte pages.
file ./firmware.bin md5 checksum: 637a2ffa8845e9c902741fcb869ac4b, stlink checksum: 0x000f74f0
2023-06-28T01:34:01 INFO common_flash.c: Attempting to write 10728 (0x29e8) bytes to stm32 address: 134217728 (0x8000000)
-> Flash page at 0x8002980 erased (size: 0x80)
2023-06-28T01:34:02 INFO flash_loader.c: Starting Flash write for L0
2023-06-28T01:34:02 INFO flash_loader.c: Successfully loaded flash loader in sram
2023-06-28T01:34:02 INFO flash_loader.c: Clear DFSR
2023-06-28T01:34:02 ERROR flash_loader.c: Flash loader run error
2023-06-28T01:34:02 WARN flash_loader.c: Loader state: R2 0x21000003 R15 0x21000003
2023-06-28T01:34:02 WARN flash_loader.c: MCU state: DHCSR 0x1080009 DFSR 0x0 CFSR 0x0 HFSR 0x0
2023-06-28T01:34:02 WARN flash_loader.c: Failed to use flash loader, fallback to soft write
167/167 halfpages written
2023-06-28T01:34:03 ERROR common_flash.c: Invalid flash address
stlink_fwrite_flash() == -1

And here's full debug output: https://pastebin.com/5NP1Q6Te

BTW I've noticed that you've dropped support for Mac OS, is there an objective reason? Would you mind a pull request that brings it back? Mac is my main machine for the time being and it would be nice if I can use stlink without VM.

UPD:
I have two of this boards. And another one produces different error:

2023-06-28T01:42:21 INFO common.c: STM32L0xxx_Cat_3: 8 KiB SRAM, 64 KiB flash in at least 128 byte pages.
file ./firmware.bin md5 checksum: 637a2ffa8845e9c902741fcb869ac4b, stlink checksum: 0x000f74f0
2023-06-28T01:42:21 INFO common_flash.c: Attempting to write 10728 (0x29e8) bytes to stm32 address: 134217728 (0x8000000)
-> Flash page at 0x8002980 erased (size: 0x80)
2023-06-28T01:42:22 INFO flash_loader.c: Starting Flash write for L0
2023-06-28T01:42:22 INFO flash_loader.c: Successfully loaded flash loader in sram
2023-06-28T01:42:22 INFO flash_loader.c: Clear DFSR
2023-06-28T01:42:23 ERROR flash_loader.c: Flash loader run error
2023-06-28T01:42:23 WARN flash_loader.c: Loader state: R2 0x16FEF800 R15 0x0
2023-06-28T01:42:23 WARN flash_loader.c: MCU state: DHCSR 0x1080009 DFSR 0x0 CFSR 0x0 HFSR 0x0
2023-06-28T01:42:23 WARN flash_loader.c: Failed to use flash loader, fallback to soft write
167/167 halfpages written
2023-06-28T01:42:23 ERROR common_flash.c: Flash memory contains a non-erased value
2023-06-28T01:42:23 INFO common.c: Go to Thumb mode
stlink_fwrite_flash() == -1

(https://pastebin.com/suG0ybvc)

UPD2:
Debug build gives ERROR common_flash.c: Invalid flash address for both boards.

@eschoker
Copy link

@mynameisdaniil same issue here. I was running into another one all day. After cleaning everyone and re cloning the current main repo I run to

2023-07-19T15:57:19 ERROR common_flash.c: Invalid flash address
2023-07-19T15:57:19 INFO common.c: Go to Thumb mode
stlink_fwrite_flash() == -1

I have tested on only one board so far the Nucleo-L031K6. Below is the full output

st-flash --reset write build/stm32l0xxTemplate.bin 0x8000000
st-flash 1.7.0-296-gf7fb0a6
2023-07-19T15:57:19 INFO common.c: STM32L0xxx_Cat_2: 8 KiB SRAM, 32 KiB flash in at least 128 byte pages.
file build/stm32l0xxTemplate.bin md5 checksum: efc4df8973afd432b9aebe6cd4dd143, stlink checksum: 0x0006ff84
2023-07-19T15:57:19 INFO common_flash.c: Attempting to write 5212 (0x145c) bytes to stm32 address: 134217728 (0x8000000)
-> Flash page at 0x8001400 erased (size: 0x80)
2023-07-19T15:57:19 INFO flash_loader.c: Starting Flash write for L0
2023-07-19T15:57:19 INFO flash_loader.c: Successfully loaded flash loader in sram
2023-07-19T15:57:19 INFO flash_loader.c: Clear DFSR
2023-07-19T15:57:19 ERROR flash_loader.c: Flash loader run error
2023-07-19T15:57:19 WARN flash_loader.c: Loader state: R2 0xB8548D00 R15 0x55F7
2023-07-19T15:57:19 WARN flash_loader.c: MCU state: DHCSR 0x1080009 DFSR 0x0 CFSR 0x0 HFSR 0x0
2023-07-19T15:57:19 WARN flash_loader.c: Failed to use flash loader, fallback to soft write
 81/ 81 halfpages written
2023-07-19T15:57:19 ERROR common_flash.c: Invalid flash address
2023-07-19T15:57:19 INFO common.c: Go to Thumb mode
stlink_fwrite_flash() == -1

@chrisgjohnson
Copy link

chrisgjohnson commented Jul 27, 2023

On my Nucleo-L031K6 I have similar problems from the latest testing commit:

2023-07-27T01:12:39 INFO common.c: STM32L0xxx_Cat_2: 8 KiB SRAM, 32 KiB flash in at least 128 byte pages.
file /home/chris/projects/stm32/own/wireless_thermometer_receiver/main.bin md5 checksum: 135fd01736fa864fc8c4b7f5f2d5119, stlink checksum: 0x002a15e7
2023-07-27T01:12:39 INFO common_flash.c: Attempting to write 31664 (0x7bb0) bytes to stm32 address: 134217728 (0x8000000)
-> Flash page at 0x8007b80 erased (size: 0x80)
2023-07-27T01:12:41 INFO flash_loader.c: Starting Flash write for L0
2023-07-27T01:12:41 INFO flash_loader.c: Successfully loaded flash loader in sram
2023-07-27T01:12:41 INFO flash_loader.c: Clear DFSR
2023-07-27T01:12:41 ERROR flash_loader.c: Flash loader run error
2023-07-27T01:12:41 WARN flash_loader.c: Loader state: R2 0x41000003 R15 0x41000003
2023-07-27T01:12:41 WARN flash_loader.c: MCU state: DHCSR 0x1080009 DFSR 0x0 CFSR 0x0 HFSR 0x0
2023-07-27T01:12:41 WARN flash_loader.c: Failed to use flash loader, fallback to soft write
494/494 halfpages written
2023-07-27T01:12:43 ERROR common_flash.c: Flash memory contains a non-erased value
stlink_fwrite_flash() == -1

This file is flashed successfully on the same hardware with st-flash 1.6.0

@Nightwalker-87
Copy link
Member

@chrisgjohnson The codebase has undergone major and very useful refactoring work with lots of improvements and fixes since then. Thus there can be no easy rollback to the previous state. Also by then there were some obscure implementations without any (proper) documentation on their functionality. This is why some users have taken action and have rewritten some parts of the code for flashing.
As to my knowledge however a coexistence of old and new sections remain up to the latest state.

Thus one would need to debug the latest code likely without any comparison to the previous state.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.