stlink icon indicating copy to clipboard operation
stlink copied to clipboard

Published 20 hours ago • verified publisher icon stlink-org

[STM32F3xxx] 'unknown chip id' with STLINK V2-clone, flashable with a V2.1

Open domingguss opened this issue 3 years ago • 10 comments

  • [x] I made serious effort to avoid creating duplicate or nearly similar issue
  • [x] Programmer/board type: [V2-clone and V2.1 broken from nucleo board]
  • [x] Operating system an version: [V2-clone does not work on Linux, V2.1 works on macOS in Eclipse]
  • [x] stlink tools version and/or git commit hash: [1.5.1-patch, but 1.6.0 and 1.7.0 fail also]
  • [x] stlink commandline tool name: [st-flash]
  • [x] Target chip (and board, if applicable): [STM32F303RCTx]

So, I am trying to flash a STM32 F3 device. Let's call this device A.

Commandline output:

`st-flash --serial 523f6d06713f555041241067 write firmware.bin 0x8008000`

Expected/description:

I expect a successful flash. Instead it says WARN common.c: unknown chip id! 0x5fa0004

st-info --probe only returns 'Found 1 stlink programmers', but no details about the chip.

If I connect my V2.1 ST-Link on my macOS and flash the firmware from Eclipse, the board is successfully flashed.

If I hook up a different F3 device, from macOS, I can successfully flash it using V2-clone and V2.1 From Linux, I can flash it only with the V2-clone ST-Link

Where is the problem? I would say the F3 is broken, but I still can flash it with the newer V2.1, so I don't know what...

domingguss avatar Dec 21 '21 17:12 domingguss

Please use the latest version of this toolset. v1.6.0 is no longer supported. See https://github.com/stlink-org/stlink/security/policy for details.

Nightwalker-87 avatar Dec 21 '21 21:12 Nightwalker-87

Sorry, I used 1.6.0 on a test-setup for this issue (where this also occurs), but the bug happens on our CI/CD which runs v1.5.1-patch.

I actually tried 1.6.0 and 1.7.0 but these cannot even flash other boards (F3 and F7) which we need in our CI/CD setup before we can even try to flash the board mentioned in TS. The v1.5.1-patch seems to be having the least failures (until INPUT_5, device A in TS).

Our setup: a Intel NUC running as a Gitlab Runner which has 7 stlink v2-clones connected to one F7 board (SENIOR) and 6 F3 boards (including device A (from TS) which below is actually JUNIOR_INPUT(5)). We use docker to automate flashing and testing our source code.

This is a part of the dockerfile that we use:

FROM ubuntu
[..]

RUN cd $HOME  && \
	git clone --single-branch --branch v1.5.1-patch https://github.com/stlink-org/stlink.git && \
	cd stlink && \
    make clean && \
	make release && \
	cd build/Release && make install DESTDIR=/ && \
	echo "export PATH=\$PATH:$HOME/stlink/build/Release/_install/usr/local/bin" >> $HOME/.bashrc && \
	echo "export LD_LIBRARY_PATH=\$LD_LIBRARY_PATH:$HOME/stlink/build/Release/_install/usr/local/lib" >> $HOME/.bashrc
RUN echo "export PATH=\$PATH:$HOME/stlink/build/Release/_install/usr/local/bin" >> /etc/profile && \
	echo "export LD_LIBRARY_PATH=\$LD_LIBRARY_PATH:$HOME/stlink/build/Release/_install/usr/local/lib" >> /etc/profile
RUN echo $HOME && \
	cat /etc/profile
ENV PATH $PATH:$HOME/stlink/build/Release/_install/usr/local/bin
ENV LD_LIBRARY_PATH "/usr/local/lib"
RUN echo $PATH
RUN mkdir -p /etc/udev/rules.d
RUN echo "KERNEL==\"ttyUSB[0-9]*\",MODE=\"0666\"" >> /etc/udev/rules.d/99-serial.rules
RUN echo "KERNEL==\"bus/usb/001/*\",MODE=\"0666\"" >> /etc/udev/rules.d/99-serial.rules

This is a part of the gitlab.yml CI/CD script we use:

[...]
    - echo "flashing JUNIOR_POWER(1)..."
    - st-flash --serial 262403013212354d434b4e00 write Junior.bin 0x8008000
    - echo "flashing SENIOR (254)..."
    - st-flash --serial 303636434646333133373332353234 write Senior.bin 0x8010000
    - echo "flashing JUNIOR_INPUT(5)..."
    - st-flash --serial 523f6d06713f555041241067 write Junior.bin 0x8008000
    - echo "flashing JUNIOR_OUTPUT(7)..."
    - st-flash --serial 1a2d050232123853354b4e00 write Junior.bin 0x8008000
    - echo "flashing JUNIOR_OUTPUT(2)..."
    - st-flash --serial 0d3d040232123853354b4e00 write Junior.bin 0x8008000
    - echo "flashing JUNIOR_MOTOR(3)..."
    - st-flash --serial 563f6f06703f575335552367 write Junior.bin 0x8008000
    - echo "flashing JUNIOR_MOTOR(4)..."
    - st-flash --serial 244503023212354d434b4e00 write Junior.bin 0x8008000
 [...]

1.5.1-patch When we use 1.5.1-patch we get the farthest (until INPUT_5)

$ echo "flashing JUNIOR_POWER(1)..."
flashing JUNIOR_POWER(1)...
$ st-flash --serial 262403013212354d434b4e00 write Junior.bin 0x8008000
2021-12-23T12:33:53 INFO common.c: Loading device parameters....
2021-12-23T12:33:53 INFO common.c: Device connected is: F3 device, id 0x10036422
2021-12-23T12:33:53 INFO common.c: SRAM size: 0xa000 bytes (40 KiB), Flash: 0x40000 bytes (256 KiB) in pages of 2048 bytes
2021-12-23T12:33:53 INFO common.c: Attempting to write 107057 (0x1a231) bytes to stm32 address: 134250496 (0x8008000)
2021-12-23T12:33:53 WARN common.c: unaligned len 0x1a231 -- padding with zero
st-flash 1.5.1-1-gffa986c
Flash page at addr: 0x08022000 erased2021-12-23T12:33:54 INFO common.c: Finished erasing 53 pages of 2048 (0x800) bytes
2021-12-23T12:33:54 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2021-12-23T12:33:54 INFO flash_loader.c: Successfully loaded flash loader in sram
 52/53 pages written2021-12-23T12:33:59 INFO common.c: Starting verification of write complete
 53/53 pages written2021-12-23T12:34:00 INFO common.c: Flash written and verified! jolly good!
$ echo "flashing SENIOR (254)..."
flashing SENIOR (254)...
$ st-flash --serial 303636434646333133373332353234 write Senior.bin 0x8010000
2021-12-23T12:34:00 INFO common.c: Loading device parameters....
2021-12-23T12:34:00 INFO common.c: Device connected is: F76xxx device, id 0x10016451
2021-12-23T12:34:00 INFO common.c: SRAM size: 0x80000 bytes (512 KiB), Flash: 0x200000 bytes (2048 KiB) in pages of 2048 bytes
2021-12-23T12:34:00 INFO common.c: Attempting to write 534185 (0x826a9) bytes to stm32 address: 134283264 (0x8010000)
2021-12-23T12:34:00 WARN common.c: unaligned len 0x826a9 -- padding with zero
EraseFlash - Sector:0x2 Size:0x8000 st-flash 1.5.1-1-gffa986c
Flash page at addr: 0x08080000 erased2021-12-23T12:34:05 INFO common.c: Finished erasing 5 pages of 262144 (0x40000) bytes
2021-12-23T12:34:05 INFO common.c: Starting Flash write for F2/F4/L4
2021-12-23T12:34:05 INFO flash_loader.c: Successfully loaded flash loader in sram
2021-12-23T12:34:13 INFO common.c: Starting verification of write complete
2021-12-23T12:34:18 INFO common.c: Flash written and verified! jolly good!
enabling 32-bit flash writes
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 9898
$ echo "flashing JUNIOR_INPUT(5)..."
flashing JUNIOR_INPUT(5)...
$ st-flash --serial 3c2503013212354d434b4e00 write Junior.bin 0x8008000
2021-12-23T12:34:27 WARN usb.c: Couldn't find any ST-Link/V2 devices
st-flash 1.5.1-1-gffa986c

1.6.0 If I use 1.6.0, it fails to flash the F7 device (SENIOR (254))

$ echo "flashing JUNIOR_POWER(1)..."
flashing JUNIOR_POWER(1)...
$ st-flash --serial 262403013212354d434b4e00 write Junior.bin 0x8008000
st-flash 1.6.0
2021-12-23T12:30:58 INFO common.c: Loading device parameters....
2021-12-23T12:30:58 INFO common.c: Device connected is: F3 device, id 0x10036422
2021-12-23T12:30:58 INFO common.c: SRAM size: 0xa000 bytes (40 KiB), Flash: 0x40000 bytes (256 KiB) in pages of 2048 bytes
2021-12-23T12:30:58 INFO common.c: Attempting to write 107057 (0x1a231) bytes to stm32 address: 134250496 (0x8008000)
2021-12-23T12:30:58 WARN common.c: unaligned len 0x1a231 -- padding with zero
Flash page at addr: 0x08021800 erased2021-12-23T12:30:59 INFO common.c: Finished erasing 53 pages of 2048 (0x800) bytes
2021-12-23T12:30:59 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
Flash page at addr: 0x08022000 erased
2021-12-23T12:30:59 INFO flash_loader.c: Successfully loaded flash loader in sram
 53/53 pages written
2021-12-23T12:31:03 INFO common.c: Starting verification of write complete
2021-12-23T12:31:04 INFO common.c: Flash written and verified! jolly good!
$ echo "flashing SENIOR (254)..."
flashing SENIOR (254)...
$ st-flash --serial 303636434646333133373332353234 write Senior.bin 0x8010000
2021-12-23T12:31:04 WARN usb.c: Couldn't find any ST-Link/V2 devices
st-flash 1.6.0

1.7.0 When I use 1.7.0, it cannot even flash the first F3 device, JUNIOR_POWER(1)

$ echo "flashing JUNIOR_POWER(1)..."
flashing JUNIOR_POWER(1)...
$ st-flash --serial 262403013212354d434b4e00 write Junior.bin 0x8008000
st-flash 1.7.0-126-gcb0f91a
2021-12-23T12:22:59 WARN usb.c: Couldn't find any ST-Link devices

What's strange is, is that I now get a different WARN than earlier mentioned in TS (WARN common.c: unknown chip id! 0x5fa0004)

So, we actually have multiple issues on multiple versions 😞

domingguss avatar Dec 23 '21 13:12 domingguss

okay, so apparantly the serial id numbers changed when I switched from 1.5.1-patch to 1.7.0: 523f6d06713f555041241067 changed into 52FF6D067189555041241067

So now only the JUNIOR_INPUT(5) still refuses to be flashed by 1.7.0:

$ st-flash --connect-under-reset --debug --serial 52FF6D067189555041241067 write Junior.bin 0x8008000
st-flash 1.7.0
2021-12-23T16:02:33 DEBUG common.c: *** looking up stlink version
[!] send_recv read reply failed: LIBUSB_ERROR_TIMEOUT
[!] send_recv STLINK_GET_VERSION
2021-12-23T16:02:36 DEBUG common.c: stlink current mode: mass
2021-12-23T16:02:36 DEBUG usb.c: JTAG/SWD freq set to 0
2021-12-23T16:02:36 DEBUG common.c: *** set_swdclk ***
2021-12-23T16:02:36 DEBUG common.c: *** stlink_jtag_reset ***
2021-12-23T16:02:36 DEBUG common.c: stlink current mode: mass
2021-12-23T16:02:36 DEBUG common.c: *** stlink_enter_swd_mode ***
2021-12-23T16:02:36 DEBUG common.c: *** stlink_force_debug_mode ***
[!] send_recv read reply failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_JTAG_WRITEDEBUG_32BIT
[!] send_recv read reply failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_JTAG_READDEBUG_32BIT
2021-12-23T16:02:36 DEBUG common.c: *** stlink_jtag_reset ***
[!] send_recv read reply failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_JTAG_READDEBUG_32BIT
2021-12-23T16:02:36 WARN common.c: NRST is not connected
2021-12-23T16:02:36 DEBUG common.c: *** stlink_soft_reset (halt) ***
2021-12-23T16:02:36 DEBUG common.c: *** stlink_write_debug32 0xa05f0003 to 0xe000edf0
[!] send_recv read reply failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_JTAG_WRITEDEBUG_32BIT
2021-12-23T16:02:36 DEBUG common.c: *** stlink_write_debug32 0x01000501 to 0xe000edfc
[!] send_recv read reply failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_JTAG_WRITEDEBUG_32BIT
2021-12-23T16:02:36 DEBUG common.c: *** stlink_write_debug32 0x00000008 to 0xe000ed30
[!] send_recv read reply failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_JTAG_WRITEDEBUG_32BIT
[!] send_recv read reply failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_JTAG_READDEBUG_32BIT
2021-12-23T16:02:36 DEBUG common.c: *** stlink_write_debug32 0x05fa0004 to 0xe000ed0c
[!] send_recv read reply failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_JTAG_WRITEDEBUG_32BIT
2021-12-23T16:02:36 ERROR common.c: Soft reset failed: error write to AIRCR
[!] send_recv read reply failed: LIBUSB_ERROR_TIMEOUT
[!] send_recv STLINK_GET_CURRENT_MODE
2021-12-23T16:02:39 DEBUG common.c: stlink mode: unknown!
2021-12-23T16:02:39 DEBUG common.c: *** stlink_enter_swd_mode ***
2021-12-23T16:02:39 DEBUG common.c: Loading device parameters....
2021-12-23T16:02:39 DEBUG common.c: *** stlink_core_id ***
[!] send_recv read reply failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_DEBUG_READCOREID
2021-12-23T16:02:39 ERROR common.c: Failed to read core_id
[!] send_recv read reply failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_JTAG_READDEBUG_32BIT
2021-12-23T16:02:39 ERROR common.c: Can not connect to target. Please use 'connect under reset' and try again
Failed to connect to target

domingguss avatar Dec 23 '21 15:12 domingguss

This appears to be an issue the external library libusb which is not part of the project. It is commonly known that the latest libusb versions are working together seamlessly with the stlink toolset on a clean installation according to the project documentation. Please refer to the libusb-project (https://github.com/libusb/libusb) regarding this issue in order to ensure that the library is working properly and as intended.

Nightwalker-87 avatar Dec 23 '21 18:12 Nightwalker-87

It is commonly known that the latest libusb versions are working together seamlessly with the stlink toolset on a clean installation according to the project documentation.

In the Dockerfile, we explicitly install libusb-1.0.0-dev so that would be pretty 'latest' right? can you be a bit more specific how to further look into this issue? i updated the host and the docker image to ubuntu20.4 but no noticable change

Commands below are directly on the host (so not even from within a priviliged docker container) More info:

$ dpkg -l libusb-1.0*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                   Version          Architecture Description
+++-======================-================-============-===================================================
ii  libusb-1.0-0:amd64     2:1.0.23-2build1 amd64        userspace USB programming library
ii  libusb-1.0-0-dev:amd64 2:1.0.23-2build1 amd64        userspace USB programming library development files
ii  libusb-1.0-doc         2:1.0.23-2build1 all          documentation for userspace USB programming
$ st-info --probe
[!] send_recv read reply failed: LIBUSB_ERROR_TIMEOUT
[!] send_recv STLINK_GET_VERSION
[!] send_recv read reply failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_JTAG_READDEBUG_32BIT
[!] send_recv read reply failed: LIBUSB_ERROR_TIMEOUT
[!] send_recv STLINK_JTAG_DRIVE_NRST
[!] send_recv read reply failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_DEBUG_RESETSYS
[!] send_recv read reply failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_DEBUG_READCOREID
[!] send_recv read reply failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_JTAG_READDEBUG_32BIT
Found 1 stlink programmers
  version:    V2
  serial:     52FF6D067189555041241067
  flash:      0 (pagesize: 0)
  sram:       0
  chipid:     0x0000
  descr:      unknown device
$ st-info --version
v1.7.0

i tried flashing the faulty f3, but didn't work:

$ st-flash --serial 52FF6D067189555041241067 --debug --connect-under-reset  write Junior.bin 0x8008000
st-flash 1.7.0
2021-12-30T16:15:40 DEBUG common.c: *** looking up stlink version
[!] send_recv read reply failed: LIBUSB_ERROR_TIMEOUT
[!] send_recv STLINK_GET_VERSION
2021-12-30T16:15:43 DEBUG common.c: stlink current mode: mass
2021-12-30T16:15:43 DEBUG usb.c: JTAG/SWD freq set to 0
2021-12-30T16:15:43 DEBUG common.c: *** set_swdclk ***
2021-12-30T16:15:43 DEBUG common.c: *** stlink_jtag_reset ***
2021-12-30T16:15:43 DEBUG common.c: stlink current mode: mass
2021-12-30T16:15:43 DEBUG common.c: *** stlink_enter_swd_mode ***
2021-12-30T16:15:43 DEBUG common.c: *** stlink_force_debug_mode ***
[!] send_recv read reply failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_JTAG_WRITEDEBUG_32BIT
[!] send_recv read reply failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_JTAG_READDEBUG_32BIT
2021-12-30T16:15:43 DEBUG common.c: *** stlink_jtag_reset ***
[!] send_recv read reply failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_JTAG_READDEBUG_32BIT
2021-12-30T16:15:43 WARN common.c: NRST is not connected
2021-12-30T16:15:43 DEBUG common.c: *** stlink_soft_reset (halt) ***
2021-12-30T16:15:43 DEBUG common.c: *** stlink_write_debug32 0xa05f0003 to 0xe000edf0
[!] send_recv read reply failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_JTAG_WRITEDEBUG_32BIT
2021-12-30T16:15:43 DEBUG common.c: *** stlink_write_debug32 0x01000501 to 0xe000edfc
[!] send_recv read reply failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_JTAG_WRITEDEBUG_32BIT
2021-12-30T16:15:43 DEBUG common.c: *** stlink_write_debug32 0x00000008 to 0xe000ed30
[!] send_recv read reply failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_JTAG_WRITEDEBUG_32BIT
[!] send_recv read reply failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_JTAG_READDEBUG_32BIT
2021-12-30T16:15:43 DEBUG common.c: *** stlink_write_debug32 0x05fa0004 to 0xe000ed0c
[!] send_recv read reply failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_JTAG_WRITEDEBUG_32BIT
2021-12-30T16:15:43 ERROR common.c: Soft reset failed: error write to AIRCR
[!] send_recv read reply failed: LIBUSB_ERROR_TIMEOUT
[!] send_recv STLINK_GET_CURRENT_MODE
2021-12-30T16:15:46 DEBUG common.c: stlink mode: unknown!
2021-12-30T16:15:46 DEBUG common.c: *** stlink_enter_swd_mode ***
2021-12-30T16:15:46 DEBUG common.c: Loading device parameters....
2021-12-30T16:15:46 DEBUG common.c: *** stlink_core_id ***
[!] send_recv read reply failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_DEBUG_READCOREID
2021-12-30T16:15:46 ERROR common.c: Failed to read core_id
[!] send_recv read reply failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_JTAG_READDEBUG_32BIT
2021-12-30T16:15:46 ERROR common.c: Can not connect to target. Please use 'connect under reset' and try again
Failed to connect to target

i now installed a new st-link from source and tried it on the F7, same:

$ st-flash --debug --connect-under-reset write Senior.bin 0x8010000
st-flash 1.7.0-11-ge662da0
2021-12-30T16:42:49 DEBUG common.c: *** looking up stlink version
2021-12-30T16:42:49 DEBUG common.c: st vid         = 0x0483 (expect 0x0483)
2021-12-30T16:42:49 DEBUG common.c: stlink pid     = 0x374b
2021-12-30T16:42:49 DEBUG common.c: stlink version = 0x2
2021-12-30T16:42:49 DEBUG common.c: jtag version   = 0x25
2021-12-30T16:42:49 DEBUG common.c: swim version   = 0x1a
2021-12-30T16:42:49 DEBUG common.c: stlink current mode: debug (jtag or swd)
2021-12-30T16:42:49 DEBUG usb.c: JTAG/SWD freq set to 0
2021-12-30T16:42:49 DEBUG common.c: *** set_swdclk ***
2021-12-30T16:42:49 DEBUG common.c: *** stlink_jtag_reset ***
2021-12-30T16:42:49 DEBUG common.c: stlink current mode: debug (jtag or swd)
2021-12-30T16:42:49 DEBUG common.c: *** stlink_force_debug_mode ***
2021-12-30T16:42:49 DEBUG common.c: *** stlink_read_debug32 0000000000 at 0xe000edf0
2021-12-30T16:42:49 DEBUG common.c: *** stlink_jtag_reset ***
2021-12-30T16:42:49 DEBUG common.c: *** stlink_read_debug32 0000000000 at 0xe000edf0
2021-12-30T16:42:49 WARN common.c: NRST is not connected
2021-12-30T16:42:49 DEBUG common.c: *** stlink_soft_reset (halt) ***
2021-12-30T16:42:49 DEBUG common.c: *** stlink_write_debug32 0xa05f0003 to 0xe000edf0
2021-12-30T16:42:49 DEBUG common.c: *** stlink_write_debug32 0x01000501 to 0xe000edfc
2021-12-30T16:42:49 DEBUG common.c: *** stlink_write_debug32 0x00000008 to 0xe000ed30
2021-12-30T16:42:49 DEBUG common.c: *** stlink_read_debug32 0000000000 at 0xe000edf0
2021-12-30T16:42:49 DEBUG common.c: *** stlink_write_debug32 0x05fa0004 to 0xe000ed0c
2021-12-30T16:42:49 DEBUG common.c: *** stlink_read_debug32 0000000000 at 0xe000edf0
2021-12-30T16:42:49 DEBUG common.c: *** stlink_read_debug32 0000000000 at 0xe000ed30
2021-12-30T16:42:49 DEBUG common.c: *** stlink_read_debug32 0000000000 at 0xe000edf0
2021-12-30T16:42:49 DEBUG common.c: *** stlink_read_debug32 0000000000 at 0xe000ed30
2021-12-30T16:42:49 DEBUG common.c: *** stlink_read_debug32 0000000000 at 0xe000edf0
2021-12-30T16:42:49 DEBUG common.c: *** stlink_read_debug32 0000000000 at 0xe000ed30
2021-12-30T16:42:49 DEBUG common.c: *** stlink_read_debug32 0000000000 at 0xe000edf0
2021-12-30T16:42:49 DEBUG common.c: *** stlink_read_debug32 0000000000 at 0xe000ed30
2021-12-30T16:42:49 DEBUG common.c: *** stlink_read_debug32 0000000000 at 0xe000edf0
2021-12-30T16:42:49 DEBUG common.c: *** stlink_read_debug32 0000000000 at 0xe000ed30

[..]

2021-12-30T16:42:50 DEBUG common.c: *** stlink_read_debug32 0000000000 at 0xe000ed30
2021-12-30T16:42:50 DEBUG common.c: *** stlink_write_debug32 0x0000001f to 0xe000ed30
2021-12-30T16:42:50 ERROR common.c: Soft reset failed: timeout
2021-12-30T16:42:50 DEBUG common.c: stlink current mode: debug (jtag or swd)
2021-12-30T16:42:50 DEBUG common.c: Loading device parameters....
2021-12-30T16:42:50 DEBUG common.c: *** stlink_core_id ***
2021-12-30T16:42:50 DEBUG common.c: core_id = 0xffffffff
2021-12-30T16:42:50 DEBUG common.c: *** stlink_read_debug32 0000000000 at 0xe000ed00
2021-12-30T16:42:50 ERROR common.c: Can not connect to target. Please use 'connect under reset' and try again
Failed to connect to target

domingguss avatar Dec 30 '21 15:12 domingguss 

$ lsusb -d 0483:374b -v | grep iSerial
  iSerial                 3 066CFF313732524E43024945
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
$ lsusb -d 0483:3748 -v | grep iSerial
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
  iSerial                 3 Rÿmq‰UPA$g

the libusb also returns a corrupted serial for the F3 (not F7)

domingguss avatar Dec 30 '21 16:12 domingguss

In the Dockerfile, we explicitly install libusb-1.0.0-dev so that would be pretty 'latest' right?

The version of the library is not found in the package name, but from your additional info we find it to be v1.0.23.

can you be a bit more specific how to further look into this issue?

To be honest not really, as there are several possible reasons for that to happen reaching from (partly) faulty programmer hardware over (thermal redundant) electrical problems on the physical layer, configuration issues on the local system, up to buggy libraries and maybe there even is a slight chance that the toolset may still show some buggy behaviour somewhere.

However as learned from previous attempts one may only take action if the is a very precise hint on where to look at with the risk it breaks something else e.g. timing related settings which currently appear to work for quite a few other boards (went through this before).

Looking at this I recommend you to rule out everything else on a best effort approach and maybe someone else also has the chance to test with the same hardware and comes up with a specific finding on where to look at. Otherwise the chance appears to be low that any change will happen to the toolset regarding this particular issue.

Please also consider in general: Should you intend to use this toolset for commercial purposes however I strongly recommend you to look for another commercial tool with official support instead of an open source tool as we can not give any guarantee for functionality or support.

Nightwalker-87 avatar Dec 30 '21 23:12 Nightwalker-87

So I (TS) yesterday had the chance to be able to test with a borrowed original STLINK from Mouser, and can confirm that it worked. So it seems that the lifespan of a cheap STLINK V2-CLONE is quite short... I think this has happpened to more people here. Maybe we should warn people that the stlink clones aren't reliable, as this has been taking a lot of energy and effort of all of us...

domingguss avatar Jan 07 '22 19:01 domingguss

Note: Closing of tickets is solely done through maintenance.

Nightwalker-87 avatar Jan 08 '22 15:01 Nightwalker-87

Can someone else run an additional HW-test with a F3-series board to verify functionality?

Nightwalker-87 avatar Jan 11 '22 23:01 Nightwalker-87

So I (TS) yesterday had the chance to be able to test with a borrowed original STLINK from Mouser, and can confirm that it worked. So it seems that the lifespan of a cheap STLINK V2-CLONE is quite short... I think this has happened to more people here. Maybe we should warn people that the stlink clones aren't reliable, as this has been taking a lot of energy and effort of all of us...

Yes, as already mentioned in our documentation /doc/tutorial.md, we do not recommend the use of Chinese STM32 clone devices [mainly GD (Giga Device), CKS (China Key Systems)], neither as target devices nor a STLink programmers. As experienced in this issue neither results nor any device durability are predictable.

Nightwalker-87 avatar Dec 28 '22 23:12 Nightwalker-87