Symptom of fake STM32 boards? Pass Blinky_Test, no longer recognised afterwards

[evoncken]

Hi,

Didn't want to open an issue yet as I'm not sure if this is related to firmware (unlikely?) or to the STM32 boards (fakes?).
I'm on macOS Catalina 10.15.7, using homebrew stlink v1.6.1.

I programmed Blinky_Test v0.26 on several STM32 (purchased from 2 different sources) using a ST-Link v2 clone programmer. All 4 boards passed programming and verification, nicely blinking their green LED.

Next I wanted to reprogram them with GreaseWeazle F1, but now they all fail - the boards aren't recognised anymore (yet they still blink nicely).

$ st-info --probe
[!] send_recv read reply failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_DEBUG_RESETSYS
libusb: error [submit_bulk_transfer] bulk transfer failed (dir = In): pipe is stalled (code = 0xe000404f)
[!] send_recv read reply failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_DEBUG_READCOREID
libusb: error [submit_bulk_transfer] bulk transfer failed (dir = In): pipe is stalled (code = 0xe000404f)
[!] send_recv read reply failed: LIBUSB_ERROR_PIPE
[!] send_recv STLINK_JTAG_READDEBUG_32BIT
Found 1 stlink programmers
serial: 460057000300004e43504d4e
hla-serial: "\x46\x00\x57\x00\x03\x00\x00\x4e\x43\x50\x4d\x4e"
flash: 0 (pagesize: 0)
sram: 0
chipid: 0x0000
descr: unknown device

I had one other board (came with the programmer) that failed flash verification at address 0, so I assumed it to be fake / defective. This is the only board that outputs probe info - so I'm assuming that the programmer is not broken:

$ st-info --probe
Found 1 stlink programmers
serial: 460057000300004e43504d4e
hla-serial: "\x46\x00\x57\x00\x03\x00\x00\x4e\x43\x50\x4d\x4e"
flash: 131072 (pagesize: 1024)
sram: 20480
chipid: 0x0410
descr: F1xx Medium-density

Is this perhaps a known symptom of fake boards? At first glance, all chips except the third looked perfectly fine, based on the pictures in the STM32 Fakes section (unless of course the "F" in "STM32F" stands for fake ;-)).

[keirf]

The problem is the blinky firmware disables swd pins, so the programmer cannot connect. Change the BOOT0 jumper setting and try again (this will run the system bootloader rather than blinky, and hence swd will remain available).

[evoncken]

Thank you for the superfast response! This indeed fixes the issue.
To be honest, it was not clear to me that this process was needed ;-)