Connected STLink to BluePill

[manter84]

Hello!!! I am testing script on BluePill with STM32F103C8T6. I Installed WSL2 and Ubuntu on Windows 10. I connected Pico as shown in the diagram and run the script. The script reached the step: "Waiting for debug probe (e.g. ST-Link) to be connected...". Do I need to connect to BluePill ST-Link without 3.3V (only connected SWIO. SWCLK and GND)? If yes, then I do it but nothing happens.

[CTXz]

The 3.3V line is optional and should not make a difference whether it is connected or not. If the script is stuck at the Waiting for debug probe (e.g. ST-Link) to be connected... prompt, it hints that openocd is not reporting a successful connection. Check if you can use openocd and see if it reports anything weird.

I haven't tested the exploit in a WSL environment, so I can't guarantee its functionality in that context.

[deividAlfa]

OpenOCD uses libusb to communicate with the ST-Link. Have you installed it with sudo apt install libusb-1.0 -y ?

@CTXz Maybe this should be added to the dependency list?

[manter84]

Did not help(((

[deividAlfa]

Why are you running Openocd 0.11 when in the Readme it's clearly stated that must be 0.12 or newer?

[manter84]

In readme write Openocd 0.11 or newer. Now I use v 0.12 and when i check connection i have this error: usr/share/openocd-code/tcl/target$ openocd -f interface/stlink.cfg -c "transport select hla_swd" -f target/stm32f1x.cfg Open On-Chip Debugger 0.12.0+dev-00553-gdd1758272 (2024-04-03-02:32) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html hla_swd Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD Info : Listening on port 6666 for tcl connections Info : Listening on port 4444 for telnet connections Info : clock speed 1000 kHz Error: libusb_open() failed with LIBUSB_ERROR_ACCESS Error: open failed

[deividAlfa]

Ah, sorry, must be a typo. Does sudo openocd ... make any difference?

[manter84]

Does sudo openocd ... make any difference? No. libusb version: libusb-1.0-0-dev: Installed: 2:1.0.25-1ubuntu2 Candidate: 2:1.0.25-1ubuntu2 Version table: *** 2:1.0.25-1ubuntu2 500 500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages 100 /var/lib/dpkg/status 2:1.0.25-1ubuntu1 500 500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages

[deividAlfa]

Try: https://github.com/FreeRDP/FreeRDP/issues/6651

[manter84]

Yes. I solved the problem with Error: libusb_open() failed with LIBUSB_ERROR_ACCESS by running the command with sudo: sudo openocd -f interface/stlink.cfg -c "transport select hla_swd" -f target/stm32f1x.cfg. But now there is a new problem. When checking, the script is not executed completely and freezes: Open On-Chip Debugger 0.12.0+dev-00553-gdd1758272 (2024-04-03-02:32) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html hla_swd Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD Info : Listening on port 6666 for tcl connections Info : Listening on port 4444 for telnet connections Info : clock speed 1000 kHz Info : STLINK V2J43S7 (API v2) VID:PID 0483:3748 Info : Target voltage: 3.125546 Info : [stm32f1x.cpu] Cortex-M3 r1p1 processor detected Info : [stm32f1x.cpu] target has 6 breakpoints, 4 watchpoints Info : [stm32f1x.cpu] Examination succeed Info : starting gdb server for stm32f1x.cpu on 3333 Info : Listening on port 3333 for gdb connections That's all.

[deividAlfa]

That's not the script, just an openocd session, it's working and it's waiting for incoming comands through telnet/ssh. Don't use openocd anymore, now try running the actual script with sudo python3 dump.py

[manter84]

Ooohhh. I understand!!! Thank you very much!!!!

[manter84]

I checked everything now. Everything works!!!

Thank you, deividAlfa!!!!

[deividAlfa]

Nice! Remember to close the issue if solved.