2025-03-16 11:18 AM - edited 2025-03-16 11:19 AM
Hi all,
I recently purchased a Nucleo-64 board with a STM32F401 and started programming it, while doing so, I accidentally re-configured PA14 & PA13 used for SWD and used by the ST-Link to program the MCU to be GPIO pins. To fix this, I thought of re-flashing the MCU with updated firmware where SWD is enabled again over UART. I tried this by pulling BOOT0 high, a USB-Serial adapter on PA10 & PA9, and doing a power cycle on the board. The USB connection is exposed as COM11 on Windows, so I tried to connect to it using CubeProgrammer but got the following error:
"Error: Activating device: KO".
I have set the baud rate to 115200, parity to even and the stop bit to 1 - But no dice. I then tried to use Realterm to send raw HEX (0x7F) to the MCU but got no response. I figured the issue might be my USB-Serial adapter, but a simple loopback test proved the adapter to be working. Worth pointing out, maybe, is that my adapter is 5V - But my MCU's datasheet states that PA10 & PA9 are FT so 5V tolerant, so that shouldn't be an issue if I'm not mistaken.
Am I missing something?
Thanks!
2025-03-16 11:33 AM
Pulling BOOT0 HIGH should be sufficient to stop your code running, to the point where the ST-LINK connection should be able to erase the part, unless there's an electrical issue. So via the SWD connection, or drag-n-drop of a binary to the USB MSC
2025-03-16 11:40 AM
I have pulled BOOT0 high and connected the board to my PC through the micro USB connector on the ST-Link part of the board as you said, but it still fails to connect:
19:38:08 : UR connection mode is defined with the HWrst reset mode
19:38:09 : ST-LINK SN : 0672FF333041383043202759
19:38:09 : ST-LINK FW : V2J46M31
19:38:09 : Board : NUCLEO-F401RE
19:38:09 : Voltage : 3.26V
19:38:09 : Error: Unable to get core ID
19:38:09 : Error: No STM32 target found! If your product embeds Debug Authentication, please perform a discovery using Debug Authentication
I believe this approach wouldn't work if I disabled SWD on my firmware - Or is it that SWD gets re-enabled when using the built-in bootloader? If it is the latter, I think my board has some electrical problems I have to look into, but I hope not :).
2025-03-16 11:53 AM
Check the jumper pair (CN2) on the NUCLEO, that connect the SWDIO/SWCLK pins to the local target (F401)
Make sure the board is not on a conductive surface (foam or mat)
2025-03-16 12:12 PM
I have removed the jumper pair CN2 and LD1 on the ST-Link part of the board is green. The user manual states the following:
• Green LED On: after a successful target communication initialization
But I still get this error in CubeProgrammer:
Error: No STM32 target found! If your product embeds Debug Authentication, please perform a discovery using Debug Authentication
Whether the jumper pair on CN2 is removed or not doesn't seem to have any effect for me.
2025-03-16 3:17 PM
With USB already connected and CN2 jumpers in place, wire BOOT0 to 3V3, then press and release the (black) reset button, and connect over STM32CubeProgrammer over SWD as normal.
If that doesn't work, chip is damaged or there is some other miswiring configuration.
Is LD1 red immediately after plugging in USB? If not something is likely wrong.
2025-03-17 10:22 AM - edited 2025-03-17 10:47 AM
LD1 is red after plugging in the USB, and the board gets power through the USB. I have wired BOOT0 to VDD and pressed the reset button, then tried to connect over SWD in CubeProgrammer but still "no STM32 target found". There is no other wiring setup on the board other than BOOT0 to VDD. I also tried wiring BOOT0 to 3V3, but same result.
This problem only occurred after I re-assigned PA14 & PA13 and disabled SWD through CubeIDE, and then flashed the chip (on accident).
The Hardware Layout for my Nucleo board also states that ST-Link is only available over SWD. Could it be that the system bootloader doesn't actually start SWD?
In AN2606 I don't see any mention of SWD being available in sys bootloader:
If useful, here is my setup:
Thanks in advance for any insight!!
2025-03-17 1:29 PM
> LD1 on the ST-Link part of the board is green.
At what point does the LED turn green? That would indicate it is connected.
> Could it be that the system bootloader doesn't actually start SWD?
No, SWD is part of the cortex core, not the bootloader. The only way to disable it would be to set RDP 2.
2025-03-17 1:40 PM - edited 2025-03-17 2:00 PM
LD1 turns green irregularly, but when it does and I try to connect using CubeProgrammer I just get an error: “No debug probe detected”.
I haven’t actually changed anything physically on the board, i.e jumpers or solder bridges, and this issue has only started after disabling SWD in CubeIDE, so I find it hard to believe the chip or board are damaged..
I’m out of ideas though, my last idea would be to check UART1 pins with a logic analyzer to see if the MCU actually runs the bootloader?
EDIT: It might be worth pointing out that when I connect the board over USB, I can open the FAIL file which contains the following: "The interface firmware FAILED to reset/halt the target MCU".
2025-03-17 3:13 PM
If LD1 is turning green that indicates the ST-Link is in use by a program and has connected to the chip. Perhaps something running in the background. Since it's in use by something else, "no debug probe detected" is the expected response.