So I recently bought the STM32F103C8T6 "black pill" dev board along with the ST-LINK/V2 dongle (more probably a Chinese clone). After much struggling I figured out that I need to hold down the dev board's reset button for the dongle to detect the MCU but then when I connected the dongle to my STM32F429 Discovery board, it detected the F429 without having to hold down reset.

I know the connection process has a "Connect with reset" option where you connect a reset pin to the board and the dongle does the hard reset for you, but I monitored the pin and it doesn't do the reset (probably a Chinese flaw?).

It's not the end of the world, it's just weird that the 103 needs to be in reset to connect, but the 429 doesn't. The 103's SWD pins aren't assigned other functions so that's not the issue. Any insight would be greatly appreciated.

Why do I need to have the 103 in reset and not the 429?

  • \$\begingroup\$ You haven't got a question in there. Hit the edit link ... \$\endgroup\$
    – Transistor
    Jul 19, 2019 at 17:45
  • \$\begingroup\$ I'm also seeing similar behaviour (Both STLink and JTAGICE3 dongles no longer detect the chip unless reset is pressed), but for me this started happening when I flashed in the stm32duino bootloader from github.com/rogerclarkmelbourne/STM32duino-bootloader). Without a bootloader (and with the hid bootloader I used previously) I could connect through SWD without having to press reset. Looking at the bootloader sources, I can't quite figure out what it is that disables SWD, though... \$\endgroup\$ Mar 25, 2020 at 16:35
  • \$\begingroup\$ As a workaround, for me it worked to jumper BOOT0 HIGH and reset (which starts the system bootloader, not the Stm32duino-bootloader) and then it works as expected without needing to keep reset pressed. \$\endgroup\$ Mar 25, 2020 at 16:38

3 Answers 3


A key driver of your problem is likely that the overwhelming majority of the compact little unofficial "ST-LINK" dongles do not actually drive their labeled reset pin, as the pin is connected to a different GPIO than wherever whatever firmware they are runnings thinks it is. You can verify this while watching the pin with a storage scope triggered on it. As they say, "you get what you pay for"

As a result, they won't work in a situation where you need to actually assert the target's actual reset line automatically. Substitute an actual ST-LINK or use a Discovery or Nucleo board recent enough to be able to drive the reset (the early ones could not do that either)

  • \$\begingroup\$ You still should be able to software resent the chip, eh? \$\endgroup\$
    – Voltage Spike
    Jul 19, 2019 at 20:39
  • \$\begingroup\$ @VoltageSpike - a soft reset is only possible when it is responding to the SWD, so when the original problem is that it isn't responding to that, you can't issue it an SWD command to reset. The fact in many cases you don't need to do an explicit hardware reset is probably how these dongles shipped with such a PCB vs. firmware mismatch - they work until you hit a situation where you actually need to assert the reset. \$\endgroup\$ Jul 19, 2019 at 20:42

It shouldn't but it may have to do with the Boot1 and Boot0 settings, and you may be in a weird mode.

Try the JP1 jumpers and make sure that they are in the same configuration as the F429 Boot0 should be low and Boot1 high.

Make sure the clone matches the datasheet, and there is nothing else connected to the SWD pins (which there could be on the clone)

enter image description here


  • \$\begingroup\$ BOOT0 is low and BOOT1 is high on the black pill and on the 429 discovery BOOT0 is low and BOOT1 is high with a 120k pullup. \$\endgroup\$
    – BdT141
    Jul 19, 2019 at 20:14

One reason that pressing reset can be needed, is when the application disables the SWD pins, to use them as GPIOs. While reset is pressed, SWD is always enabled, so you can always connect with SWD while reset is pressed.

I have found that the Arduino_STM32 core by "rogerclarkmelbourne" in fact always disables the SWD pins, see this commit. This would mean that if any sketch compiled with that core is on your board, SWD won't work without reset.

I've seen the same happen on a RobotDyn black pill board, which seems to be shipped with the STM32duino bootloader and a "hello, world" sketch. The bootloader does not interfere with SWD (so you can attach the debugger in the second or so that the bootloader runs), but the sketch that follows disables SWD (is probably compiled with the Arduino_STM32 core).

For completeness, this does not hold for the Arduino_Core_STM32 core by ST, sketches compiled with that core leave SWD enabled normally (not sure if you can actually use the SWD pins as GPIO with that core, then).


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.