32F417: Mapping SPI1 to the SWD debug pins PB3-PB5 - how can this work?

PHolt.1 · ‎2025-12-12

One of the AF options on SPI1 is to use the SWD debug pins PB3-PB5.

How can this be used in reality?

Pretty obviously you can't do SWD breakpoints when SPI1 is thus mapped!

But assuming no SWD debugging is needed, and you use SWD just to program the FLASH, how does one implement this? AFAICT one would need

- on SWD inputs, FLASH loading will work

- on SWD outputs (e.g. SWO - the SWV ITM debug output), FLASH loading works because these pins power up in some mode suitable for SWD FLASH programming.

Then when the code starts running, you will need some logic to disconnect the debugger, so the clock and data SPI signals can come out, without contention with the debugger.

Maybe I am missing something obvious. Or maybe this SPI1 AF mapping option is intended for FLASH programming not via SWD but via a UART, CAN or the weird USB mode.

PB3 may not need anything because the SPI CLK is an output and the SWD SWO signal is also an output

PHolt.1 · ‎2025-12-16

"It's not obvious. Why would that be?"

I am happy with the target doing the right thing, but was worried about the debugger's output pin(s) remaining active, whenever it is connected to the target.

But you are right. The two signals the debugger will be driving will be JT-SWDIO and JT-SWCLK. It then monitors JT-SWO. These are PA13 PA14 PB3 respectively.

So we are left with the possible PB3 conflict. AFAICT the SWO mode is selected by the debugger after the target /reset is removed (one of the "hidden" things the debugger does to the CPU) so the question is whether setting up the AF for the SPI mode will disable SWO (specifically, disconnect PB3 from the SWO circuit and connect it to SPI). The info I can find states that selecting AF5 disables SWO, and experimentally I can confirm this.

This should do it

    GPIO_InitTypeDef GPIO_InitStruct = {0};
    
    __HAL_RCC_GPIOB_CLK_ENABLE();
    __HAL_RCC_SPI1_CLK_ENABLE();
    
    // PB3 = SCK, PB4 = MISO, PB5 = MOSI
    GPIO_InitStruct.Pin = GPIO_PIN_3 | GPIO_PIN_4 | GPIO_PIN_5;
    GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
    GPIO_InitStruct.Pull = GPIO_NOPULL;
    GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH;
    GPIO_InitStruct.Alternate = GPIO_AF5_SPI1;
    HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);

Some stuff I found online states that you can still use SWD debugging (SWDIO/SWCLK on PA13/PA14) and breakpoints, stepping, variable watching all still work. I can confirm this too. You only lose SWO.

I think others have been up this road before...

This has been an interesting exercise!

View solution in original post

Andrew Neil · ‎2025-12-12

You just configure the GPIO pins in exactly the same way as you'd configure any other GPIO pins - there's nothing special to it.

But, as you say, the big downside is that you then can't use SWD - not for debugging, and not for programming.

So there is a high risk that you can "brick" the chip - leaving in a state that can be neither debugged nor programmed via SWD.

So you should think very carefully indeed before actually doing this!

But you should still be able to program via the system bootloader.

And an SWD probe (eg, ST-Link) should be able to connect under Hardware reset.

PS:

Only yesterday, an example of the trouble this can land you in: lost access to STM32G030 micro.

This is why you'll find that one of the first questions in the many "Help, I can't connect to my STM32!" threads is often, "have you reconfigured the SWD pins?"

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

PHolt.1 · ‎2025-12-12

"not for debugging, and not for programming."

but you say

"SWD probe (eg, ST-Link) should be able to connect under Hardware reset."

AIUI, with hardware reset (NRST=0) asserted, the pins all go floating (with some exceptions) and the debugger gets free access because your code is not (yet) running so any SPI1 pin config code cannot be running. So FLASH programming should work?

And even after your code has configured the pins, NRST=0 should cancel that out.

I also note that PB4 is SPI MISO which is an input, just like NJTRST is an input. So maybe this AF was carefully chosen after all :)

In SPI usage, PB4 will be driven (by the SPI Slave's MOSI) so one needs to arrange for that signal to go tri-state when NJTRST=0. But what does NJTRST actually do? It came up here

https://www.eevblog.com/forum/microcontrollers/st-32f4xx-debugging-and-njtrst-mystery-does-it-do-anything/msg3564987/#msg3564987

and it seems you can ignore it. I have a 10k pullup on it but otherwise do not use it. However I never set it to 0, which is exactly what will happen if you use it for SPI.

You definitely lose SWO debug output but that's not so bad. Well, breakpoints also!

I see good input here

https://www.eevblog.com/forum/microcontrollers/re-assigning-swd-pins-of-stm32/msg2970158/#msg2970158

including a suggested delay before reconfig of the SWD pins.

Andrew Neil · ‎2025-12-12

@PHolt.1 wrote:
AIUI, with hardware reset (NRST=0) asserted, the pins all go floating (with some exceptions) and the debugger gets free access because your code is not (yet) running so any SPI1 pin config code cannot be running. So FLASH programming should work?

Correct.

@PHolt.1 wrote:
And even after your code has configured the pins, NRST=0 should cancel that out..

Correct.

@PHolt.1 wrote:
But what does NJTRST actually do? It came up here

The thread says it just resets the debug controller.

It's only relevant if you're using actual JTAG - not SWD.

@PHolt.1 wrote:
suggested delay before reconfig of the SWD pins.

Yes - I also suggest that in the link I posted earlier.

PS:

https://www.st.com/resource/en/reference_manual/rm0090-stm32f405415-stm32f407417-stm32f427437-and-stm32f429439-advanced-armbased-32bit-mcus-stmicroelectronics.pdf#page=1692

With SWD, there is no external reset for SW-DP - just the overall chip reset from NRST or power-on reset:

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

PHolt.1 · ‎2025-12-12

OK so one needs to be sure that putting muck on NJTRST does not break anything.

EDIT: just seen your PS. Can we be sure waggling NJTRST will not break anything, either during FLASH programming or during code execution?

Stuff appearing on NJTRST could well violate reset timing specs on the TAP controller.

Andrew Neil · ‎2025-12-12

I don't know.

But sounds like yet another reason to avoid doing this unless absolutely unavoidable!

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

PHolt.1 · ‎2025-12-12

ST should know, otherwise why offer that AF option, if actually using the SPI blows it up?

OTOH, if the SPI is a Master only, output only (say driving an LCD or a DAC) then this issue does not arise.

Andrew Neil · ‎2025-12-12

It's up to the user to configure their system sensibly - that's beyond ST's control.

There are plenty of ways that users could configure things badly ...

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

PHolt.1 · ‎2025-12-12

For sure, but the existence of that AF mapping where SPI1 shares the SWD pins must mean that somebody thought about it and decided it is ok.

Probably about 15 years ago :)

I wonder if anyone from ST will drop in.

Andrew Neil · ‎2025-12-13

I'm sure there are lots of shared AF mappings where one would conflict with another.

I don't think it would be possible to choose them so that no two could possibly ever cause any conceivable conflict in any circumstance?

Choosing an SPI mapping on any set of pins requires that you only connect a compatible device - ST can't stop you connecting two SPI masters together ...

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.