search

stlink-org / stlink

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

Attempting to flash to STM32L052K8 corrupts flash memory #681

Closed WRansohoff closed 1 year ago

WRansohoff commented 6 years ago

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 commented 6 years ago

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.

WRansohoff commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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:

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 commented 6 years ago

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 commented 5 years ago

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 commented 4 years ago

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

WRansohoff commented 4 years ago

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.

lapers commented 4 years ago

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

Ant-ON commented 3 years ago

@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.

Nightwalker-87 commented 3 years ago

Anyone else? Indeed there are still a few L-related other tickets as well, so folks with such boards would clearly help.

V1DEOJAMES commented 3 years ago

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

Ant-ON commented 3 years ago

@V1DEOJAMES Can you try https://github.com/Ant-ON/stlink/tree/fl_fix branch?

Nightwalker-87 commented 3 years ago

Ping @V1DEOJAMES

V1DEOJAMES commented 3 years ago

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.

Nightwalker-87 commented 3 years ago

Ok, so your observations were obviously not related to this issue. Thx for the feedback. :+1:

Nightwalker-87 commented 3 years ago

@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.

Nightwalker-87 commented 3 years ago

@gszy Can you help us with this one?

gszy commented 3 years ago

I’m sorry, I don’t have any L0s to test.

Nightwalker-87 commented 3 years ago

I see. However thanks for the feedback. Feel free to take a look at other issues if you fancy to do so. :+1:

Nightwalker-87 commented 2 years ago

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.

Nightwalker-87 commented 2 years ago

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.

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.

BRA1L0R commented 2 years ago

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
Nightwalker-87 commented 1 year ago

@BRA1L0R Your problem is documented in #1203. As far as I can tell it's not related to this issue.

Nightwalker-87 commented 1 year ago

@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.

nemtsov commented 1 year ago

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.

Nightwalker-87 commented 1 year ago

@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.

nemtsov commented 1 year ago

@Nightwalker-87 one other thing I should note (in case this helps) is that I can repro this with different source code. I started that gist with the actual source I'm writing and then slowly changed all instructions to MOV to make the repro source cleaner.

I'm not sure if that's what's happening (or the bug just gives this appearance), but what it feels like is that it isn't so much which instructions that are used but how many of them. It's as if there's a limit on the space for instructions and I can either fill it with 27 MOVs or 15 LDR, MOV, STR, ORR, etc., and adding one more puts it over the edge. Or at least experimentally that's how I'm triggering this issue.

Nightwalker-87 commented 1 year ago

@nemtsov This assembler based approach for testing is very interesting (i've just started to learn avr-asm). We now need the look at the current implementation (may it be implemented well or not) to decide whether it is worth fixing or if an alternative approach is favourable. I currently have no idea on what we will find in this part of the code. :confused:

Mk-arc commented 1 year ago

It seems I have the same problem. Tested with STM32L063R8Tx on a custom made board. So far I have been unable to program this board with st-link.

Flashing works fine with STM32CubeProgrammer and the same st-link probe (V2) or with other probes, e.g. J-Link.

If there is anything I should test, let me know.

Nightwalker-87 commented 1 year ago

@bourou01 / st-util 1.5.0 / Device: STM32F103C8X "Bluepill" --> unrelated issue, board is not detected, see INFO gdb-server.c: Chip ID is 00000000, Core ID is 00000000. Likely related to faulty hardware or faked chip; refer to section "NOTE: Chinese Fake-Chips CKS32F103C8T6 or CS32F103C8T6 being marked as "STM32F103C8T6"" in /doc/tutorial.md for more details.

Nightwalker-87 commented 1 year ago

Time for a summary in order to draw this to a close:

1) @WRansohoff / Release st-flash 1.5.0 / Devices: STM32L052K8 & STM32L082KZ 2) @jakeypoo / st-flash 1.4.0-57-g7651d21 / Device: STM32L151CC 3) @Mk-arc / st-flash 1.7.0 / Device: STM32L063R8Tx 4) @nemtsov / st-flash 1.7.0 / Device: STM32L010F4 5) @mynameisdaniil / st-flash 1.7.0-184-g468b1d2 / Device: STM32L053C8T6 (Feb 2022, #1225)

Findings:

a) @Nightwalker-87 on Jan 6, 2022: --> false bootrom_base hex address for the L0 series. According to the viewed reference manuals the is a missing digit: 0x1ff0000 --> 0x1ff00000 This has been fixed in commit e62b9e1f2a1b6dea7e9ccb053c14c2c6ad0b57d7.

b) @mattgbio on Dec 6, 2021: --> found that commenting-out the following lines in src/common.c:3346 :

if (len > pagesize) {
  if (stm32l1_write_half_pages(sl, addr, base, len, pagesize) == -1) {
    // this may happen on a blank device!
    WLOG("\nwrite_half_pages failed == -1\n");
  } else {
    off = (size_t)(len / pagesize) * pagesize;
  }
}

resolved the issue and served as a temporary workaround (Dec 2021, #1203). These lines have moved to src/flash_loader.c:772 at the time of writing.

Nightwalker-87 commented 1 year ago

Note, that this ticket serves as the main thread for the equal or similar issues: #1203, #1225, #1253, #1289

@Ant-ON Here we have @nemtsov , @Mk-arc and @mynameisdaniil with suitable hardware for testing.

Here is how I'd proceed:

1) Firstly, I recommend volunteers to do some testing with with their hardware based on the latest testing branch (commit: b72f5b5acf8997a299d9eac4d6cc2dfc5322e144) to give an overview of the current state. Ideally this should be done by all involved contributors listed above.

2) Referring to your thoughts in https://github.com/stlink-org/stlink/issues/1225#issuecomment-1596079595 we should then make use of option b). This would give additional info on the resulting effects.

3) Based on the results we shall decide on if to disable half-page-writing for L0/L1 as a interim solution. If this should turn out to be the case, then we'll close this topic for now, and open a new issue in order to to fix the implementation for half-page-writing as a feature-request.

Ant-ON commented 1 year ago

@Nightwalker-87 RM0038 Rev 18 at pg. 65 has warning for Half Page Write:

Warning: Half Page Write is possible only from SRAM, from external memory or from bank 1 to bank 2 and vice versa.

RM0367 Rev 8 at pg. 82 has me a conspicuous warning:

This protocol can be used either through application code running from RAM or through DMA with application code running from RAM or core sleeping.

Therefore, I believe that the code can be disable.

Nightwalker-87 commented 1 year ago

@Ant-ON Thanks for the research. We'll do so then. Nevertheless I'd consider it worthy to follow the proposed steps to see what happens.

Nightwalker-87 commented 1 year ago

@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 commented 1 year ago

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: d4b53b06b6ed8906798201ece463ffd2704051ef

 ./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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

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

Mk-arc commented 1 year ago

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

Nightwalker-87 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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!
``