search

stlink-org / stlink

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

Unable to flash any Nucleo board #1009

Closed tdjastrzebski closed 3 years ago

tdjastrzebski commented 4 years ago

I am unable to flash any Nucleo board using version 1.6.1 or the current dev version while the same time version 1.6.0 works just fine. Is it possible I screwed up the build? But build is so simple that it is nearly impossible to break anything. The only thing I did differently: I used cmake which comes with VS Studio but I do not see how this could cause a problem. Version 1.6.0 built the same way works fine.

Boards tested: Nucleo-F303K8, Nucleo-F767ZI, Nucleo-F746ZG, DISCO-STM32F769NI Windows 10.0.19041

st-flash 1.6.1
libusb: info [cache_config_descriptors] could not access configuration descriptor 1 (dummy) for 'USB\VID_045E&PID_07C6\000001000000': [31] A device attached to the system is not functioning.
2020-07-28T22:38:40 WARN common.c: unknown chip id! 0x1a
Failed to connect to target
st-flash 1.6.0
2020-07-28T22:36:19 INFO common.c: Loading device parameters....
2020-07-28T22:36:19 INFO common.c: Device connected is: F76xxx device, id 0x10016451
2020-07-28T22:36:19 INFO common.c: SRAM size: 0x80000 bytes (512 KiB), Flash: 0x200000 bytes (2048 KiB) in pages of 2048 bytes
2020-07-28T22:36:19 INFO common.c: Attempting to write 36812 (0x8fcc) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08008000 erasedEraseFlash - Sector:0x1 Size:0x8000 
2020-07-28T22:36:19 INFO common.c: Finished erasing 2 pages of 32768 (0x8000) bytes
2020-07-28T22:36:19 INFO common.c: Starting Flash write for F2/F4/L4
2020-07-28T22:36:19 INFO flash_loader.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 32768
size: 4044
2020-07-28T22:36:20 INFO common.c: Starting verification of write complete
2020-07-28T22:36:20 INFO common.c: Flash written and verified! jolly good!
STM32 ST-LINK CLI v3.5.0.0
STM32 ST-LINK Command Line Interface

ST-LINK SN: 066BFF3035344E5043141238
ST-LINK Firmware version: V2J37M26
Connected via SWD.
SWD Frequency = 4000K.
Target voltage = 3.3 V
Connection mode: Normal
Reset mode: Hardware reset        
Device ID: 0x451 
Device flash Size: 2048 Kbytes
Device family: STM32F76x
Loading file...
Flash Programming:
  File : C:\Test Projects\STM32F767ZI/BUILD/NUCLEO_F767ZI/GCC_ARM-DEBUG/STM32F767ZI.bin
  Address : 0x08000000
Memory programming...
██████████████████████████████████████████████████ 100%
Memory programmed in 1s and 250ms.
Verification...OK
Programming Complete.
Programmed memory Checksum: 0x0034D2E0
Nightwalker-87 commented 4 years ago

We need to find the last good state.

libusb: info [cache_config_descriptors] could not access configuration descriptor 1 (dummy) for 'USB\VID_045E&PID_07C6\000001000000': [31] A device attached to the system is not functioning.

This may be related to the external libusb library used by this toolset. It has been updated to 1.0.23 in v1.6.1. Please check if commit d3ad0c90343d96b8922996d2d951d8afff41d1c7 is in a working state. If so, I suggest to continue with bf39a19d39af91bb508181479897c69440dc853f and ceef1419a4fa3f8e3f3a6617daf6d6c190a23e69.

tdjastrzebski commented 4 years ago

I believe the problem is actually caused by some Windows 10 protection mechanism. For the first time everything works very nice, fast and smoothly. Both flashing and debug. Once the board is disconnected and connected again, the problems start. And it is not only StLink. OpenOCD has similar issues like unknown chip id, usb timeouts, eventually gdb server fails to start at all. Computer restart or shut down does not help.
I have seen this pattern on all three Windows 10 machines I tried - with slightly different Windows versions. It seems that with the new libusb 1.0.23 and STLink 6.1 the problem starts faster and completely disables flash and debug. The problem may also be related to the board type. Nucleo-F746 stops debugging quickly and permanently. Disco-STM32F769 I can still debug but only with STLink 6.0. This may be some new Windows AI-based protection. I have no better clue.

2020-07-30T20:43:14 DEBUG common.c: *** stlink_core_id ***
2020-07-30T20:43:14 DEBUG common.c: core_id = 0x5ba02477
2020-07-30T20:43:14 DEBUG common.c: *** stlink_read_debug32 a05f0000 is 0xe0042000
2020-07-30T20:43:14 WARN common.c: Invalid flash type, please check device declaration
2020-07-30T20:43:14 ERROR gdb-server.c: Unsupported Target (Chip ID is 0000000000, Core ID is 0x5ba02477).
2020-07-30T20:44:25 ERROR common.c: map_file() == -1
stlink_fwrite_flash() == -1
2020-07-30T20:46:40 DEBUG common.c: *** stlink_reset ***
[!] send_recv send request failed: LIBUSB_ERROR_TIMEOUT
[!] send_recv STLINK_DEBUG_RESETSYS

OpenOCD:

Info : device id = 0x00010000
Warn : Cannot identify target as a STM32 family.
Error: auto_probe failed
Nightwalker-87 commented 3 years ago

Is there somebody around with one of the mentioned Nucleo boards who can do some testing on this? I checked the Nucleo boards which I have access to. Unfortunately they are F4 and L4 ones, which will likely not help here...

Nightwalker-87 commented 3 years ago

@tdjastrzebski Can you try commit 6f941b22eb00844eca7d17ebe3168d34276ef6b3? This is the last post-v1.6.0 commit using libusb 1.0.22. It would be helpful to see this is related to a specific libusb version. Also we now have libusb 1.0.24 on current develop now.

Nightwalker-87 commented 3 years ago

@Ant-ON Any idea from your side?

Ant-ON commented 3 years ago

@Nightwalker-87 I think these are problems on the hardware or OS side. It is difficult to say their reason. A similar problem was in the https://github.com/libusb/libusb/issues/442. As far as I understood, the problem could not be found.

tdjastrzebski commented 3 years ago

@Ant-ON @Nightwalker-87 I agree, it seems to me it is a Windows problem. Probably comparing Windows registry content before and after reconnecting the board would shed some light.

Nightwalker-87 commented 3 years ago

I see, but that is obviously noting specifically related to this toolset and it's integrity, so I suggest to close this issue as "unrelated".

tdjastrzebski commented 3 years ago

@Nightwalker-87 I would refrain from jumping into such conclusion. OpenOCD and pyOCD do not reveal such issue. Not to mention STM32CubeProgrammer. Tested with exactly the same hardware/setup.

Nightwalker-87 commented 3 years ago

Have you tried any newer commits (also the mentioned ones)?

tdjastrzebski commented 3 years ago

I have not. If I were to guess, my guess would be stlink sets some board-specific usb properties which Windows remembers and refuses to cooperate after reconnection. I will try the latest stlink build.

tdjastrzebski commented 3 years ago

An attempt to build the current version results in this error:

x VS2017/MS32/dll/libusb-1.0.dll
x VS2017/MS64/dll/libusb-1.0.dll
x VS2019/MS32/dll/libusb-1.0.dll
x VS2019/MS64/dll/libusb-1.0.dll
-- Missing libusb library has been installed
CMake Error at C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:165 (message):
  Could NOT find libusb (missing: LIBUSB_LIBRARY)
Call Stack (most recent call first):
  C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:458 (_FPHSA_FAILURE_MESSAGE)
  cmake/modules/Findlibusb.cmake:138 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  CMakeLists.txt:40 (find_package)

CMake correctly downloads libusb but then it cannot find it. I am not a CMake expert :(

Nightwalker-87 commented 3 years ago

Thx for the note. Please try fe526ec9ebc77224ed3ac0e688e07cd250cd59a0 instead.

Nightwalker-87 commented 3 years ago

@tdjastrzebski The error may have been introduced here: 89a495d169a15f42d8cfd1a68c6738c984d052f8 Nevertheless we should focus on the actual topic and the previous ticket of yours as well, so please stay tuned.

Nightwalker-87 commented 3 years ago

Partial duplicate of #1008.

Nightwalker-87 commented 3 years ago

@slyshykO Can you check on your native windows machine if compilation succeeds? Not sure if there still is an unnoticed problem with a subfolder-path. I can't see this during cross compilation and was not able to check on a VM yet.

slyshykO commented 3 years ago 
[cmake] x VS2017/MS64/dll/libusb-1.0.dll
[cmake] x VS2019/MS32/dll/libusb-1.0.dll
[cmake] x VS2019/MS64/dll/libusb-1.0.dll
[cmake] -- Missing libusb library has been installed
[cmake] CMake Error at C:/Program Files/CMake/share/cmake-3.20/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
[cmake]   Could NOT find libusb (missing: LIBUSB_LIBRARY)
[cmake] Call Stack (most recent call first):
[cmake]   C:/Program Files/CMake/share/cmake-3.20/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
[cmake]   cmake/modules/Findlibusb.cmake:138 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
[cmake]   CMakeLists.txt:40 (find_package)
Nightwalker-87 commented 3 years ago

Is this the latest commit?

slyshykO commented 3 years ago

Is this the latest commit?

yes, it is latest develop

Nightwalker-87 commented 3 years ago

I'll roll libusb back to version 1.0.23 and will not update until a windows contributor is going to do so confirming it is working. I'm fed up with this and won't spent any more time on this issue. I believed to have found a way to let it compile for i386 at least... Check commit 6993491f90b15581668088a6e522b8fb9a3bb84e for verification.

Nightwalker-87 commented 3 years ago

@slyshykO Can you verify this on your windows machine by now (e.g. with a similar board)?

slyshykO commented 3 years ago

now develop compile successfully.

slyshykO commented 3 years ago 
e:\test-st\stlink-git\build\Visual Studio Community 2019 Release - x86-Release\bin>st-info.exe --probe
Found 1 stlink programmers
  version:    V2J37S26
  serial:     066DFF323532543457243257
  flash:      2097152 (pagesize: 131072)
  sram:       131072
  chipid:     0x0450
  descr:      H74x/H75x

e:\test-st\stlink-git\build\Visual Studio Community 2019 Release - x86-Release\bin>st-flash --reset write ./nucleo-h743zi.bin 0x8000000
st-flash 1.6.1-302-g6993491
2021-04-23T02:15:13 INFO common.c: H74x/H75x: 128 KiB SRAM, 2048 KiB flash in at least 128 KiB pages.
file ./nucleo-h743zi.bin md5 checksum: 44fd8f817e9273d9abca8cb54f14353, stlink checksum: 0x002f3f1b
2021-04-23T02:15:13 INFO common.c: Attempting to write 30700 (0x77ec) bytes to stm32 address: 134217728 (0x8000000)
2021-04-23T02:15:14 INFO common.c: Flash page at addr: 0x08000000 erased
2021-04-23T02:15:14 INFO common.c: Finished erasing 1 pages of 131072 (0x20000) bytes
2021-04-23T02:15:14 INFO common.c: Starting Flash write for H7
30700/30700 bytes written
2021-04-23T02:15:15 INFO common.c: Starting verification of write complete
2021-04-23T02:15:15 INFO common.c: Flash written and verified! jolly good!
slyshykO commented 3 years ago

Flash successfully Nucleo-h743, stm32f746-disco can test tomorrow.

slyshykO commented 3 years ago 
e:\test-st\stlink-git\build\Visual Studio Community 2019 Release - x86-Release\bin>st-info.exe --probe
Found 1 stlink programmers
  version:    V2J29S18
  serial:     0672FF485550755187220729
  flash:      1048576 (pagesize: 2048)
  sram:       327680
  chipid:     0x0449
  descr:      F7xx

e:\test-st\stlink-git\build\Visual Studio Community 2019 Release - x86-Release\bin>st-flash --reset write ./nucleo-h743zi.bin 0x8000000
st-flash 1.6.1-302-g6993491
2021-04-23T11:56:51 INFO common.c: F7xx: 320 KiB SRAM, 1024 KiB flash in at least 2 KiB pages.
file ./nucleo-h743zi.bin md5 checksum: 44fd8f817e9273d9abca8cb54f14353, stlink checksum: 0x002f3f1b
2021-04-23T11:56:51 INFO common.c: Attempting to write 30700 (0x77ec) bytes to stm32 address: 134217728 (0x8000000)
EraseFlash - Sector:0x0 Size:0x8000 2021-04-23T11:56:51 INFO common.c: Flash page at addr: 0x08000000 erased
2021-04-23T11:56:51 INFO common.c: Finished erasing 1 pages of 32768 (0x8000) bytes
2021-04-23T11:56:51 INFO common.c: Starting Flash write for F2/F4/F7/L4
2021-04-23T11:56:51 INFO flash_loader.c: Successfully loaded flash loader in sram
2021-04-23T11:56:51 INFO flash_loader.c: Clear DFSR
2021-04-23T11:56:51 INFO common.c: enabling 32-bit flash writes
2021-04-23T11:56:52 INFO common.c: Starting verification of write complete
2021-04-23T11:56:52 INFO common.c: Flash written and verified! jolly good!

Test with stm32f746-disco, it works.

Nightwalker-87 commented 3 years ago

Looking at this, the original issue could not be reproduced in an comparable environment with libusb v1.0.23. In this context and by pointing out https://github.com/stlink-org/stlink/issues/1009#issuecomment-820179753, we can indeed safely assume a local hardware or OS-specific problem, which appears not to be related to this toolset.