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

[PHolt.1]

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

[Andrew Neil]

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?"

[PHolt.1]

"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]

---

@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.