NRST connection required for SWD connection to STM32 targets?

[birkenfeld]

Hello everyone, I'm using a blackpill-f411 as the probe and want to connect to other STM32 as the target. From STLink adapters (original and china clones) I'm used to only connecting GND, SWIO and SWCLK for probing, flashing etc. But with the BMP I also need to connect NRST to be able to do anything (e.g. get a result from mon a in gdb).

I've verified with the same target in the same state, that an stlink china clone can connect while BMP cannot without NRST.

Is that by design, or is there something I'm overlooking? Thanks!

[dragonmux]

That one's new on us.. the nRST connection is intended to be entirely optional. It not working sounds like BMD is having to poke the reset line to get the debug infrastructure to talk - are you using WFI/WFE in your firmware? Are you asking BMD to connect-under-reset?

Which STM32 target are you trying to work with exactly? This could be a bug.

[birkenfeld]

Thanks for the reply!

• There is no WFI/WFE in the firmware, I tested with a simple "blinky" demo that busy-waits, and also with no firmware loaded.
• --connect-under-reset does not make an appreciable difference.
• The chips I tried are STM32G431 and STM32F429.
• On the host side, I tried both gdb via target ext and probe-rs (which uses the BMP protocol).

[ALTracer]

Hello fellow blackpill-f4 user. I was able to reproduce your problem using clean main v2.0.0-rc1-38-gf4e79b65 and a STM32H503CB CoreBoard. It does not complete an SWD scan predictably with just 4 wires attached: SWCLK/PB8, SWDIO/PB9, 5v, Gnd (four consecutive pins on blackpill-f411ce) regardless of frequency. As soon as I attach SRST/PA5 it always completes predictably. Otherwise, if I attach TDI/PB7 and TDO/PB8, then JTAG scans work but SWD scans not always work. Connecting USART PA2/3 may or may not affect this, depends on DUT firmware.
Same with STM32H562RG CoreBoard. On AT32F403A it only results in bogus reads from CoreSight ROM tables for ITM/DWT/TPIU (but not FPB/ETM).
Preliminarly I believe this is just a signal integrity issue, solved by using more than one ground wire (there are three ground pins available). It may have resulted from me bumping slew rate OSPEED 2 MHz -> 25 MHz so that practically reachable 6-8 MHz SWCLK works. I hope it's an understandable compromise.

[birkenfeld]

Thanks for the feedback! I'll try and see if I can get different results with more ground connections tomorrow...

BTW, meanwhile also had the same behavior with a bluepill probe and the same targets, but that's probably not surprising.

[birkenfeld]

I made several tests with different ground connections, and this definitely looks like a signal issue. I also found that you can change the SWD frequency using mon freq. Depending on the number of grounds, I could usually manage to get a scan to work without NRST connection by going down in frequency, but never with the default frequency.

[UweBonnes]

It is not the frequency of the SWD/JTAG signal(), it is the speed of the signal edges. For F411 I see: GPIO_OSPEED_100MHZ and that will for sure cause problems.
() As long as you stay in the SWD/JTAG frequency range given in the datasheet.

[birkenfeld]

Thanks for the hint, Uwe! I made a test build setting the TCK/TMS pins (which are SWCLK and SWDIO) to GPIO_OSPEED_2MHZ, and voila, no additional grounds or NRST connections needed.

I would make a PR, but I have no real idea about the implications. It seems that the default SWD frequency is 3 MHz (?) so this OSPEED is too low for that?

[ALTracer]

It is hard to please everyone under flash constraints and zero expectations of wiring quality. Blackpill-f4 easily reaches 8.72 MHz SWCLK using no_delay primitives of swdptap.c, and there were attempts to improve that in PR1688. It manages 153-188 KiB/s transfers (read-write) to RETRAM of MP157_CM4 at that frequency. JTAG is slower, 57-113.

nRST bug aside (thanks @birkenfeld for pointing it out!), a compromise can be made if we add yet another macro, or preferably platform callback, to toggle OSPEED between 2MHz and 25MHz at run time, when crossing a preset margin, of 3-4 MHz. I've noticed that stlinkv3 platform is ready for this, maybe f411ce would benefit, too. For native BMP this function will do nothing, to save space.

[UweBonnes]

Thanks for the hint, Uwe! I made a test build setting the TCK/TMS pins (which are SWCLK and SWDIO) to GPIO_OSPEED_2MHZ, and voila, no additional grounds or NRST connections needed.

I would make a PR, but I have no real idea about the implications. It seems that the default SWD frequency is 3 MHz (?) so this OSPEED is too low for that?

For GPIO_OSPEED_2MHZ, the datasheet tells: CL = 50 pF, VDD ≥ 2.70 V 4 Mhz and CL = 10 pF, VDD ≥ 2.70 V 8MHz
Expect 5 pF for the target input and about 100 pF per Meter of cable. So there is "no size fits all" but for most users a lower default speed but a more robust setup is i.m.h.o better than a somehow faster by default setup not working in more setups.

[birkenfeld]

nRST bug aside (thanks @birkenfeld for pointing it out!), a compromise can be made if we add yet another macro, or preferably platform callback, to toggle OSPEED between 2MHz and 25MHz at run time, when crossing a preset margin, of 3-4 MHz. I've noticed that stlinkv3 platform is ready for this, maybe f411ce would benefit, too. For native BMP this function will do nothing, to save space.

Sounds good to me! Like Uwe says, IMO having a working out of the box setup is better than fast for some, non-working for others.

[birkenfeld]

Also, kudos to the BMP team for making such a versatile probe and firmware that can be used on pretty custom hardware! It must be a nightmare to catch all these little corner cases for the "in principle it should work..." setups.