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

[AScha.3]

Come on...its also possible to use the debug pins as simple GPIO - if you dont want /need debug, its okay.

Up to the user, to choose a the cheapest/smallest package and need every pin for i/o or spi ...and have no debug.

If you want debug set it in Cube as one of the first things to set and there is no problem with all alternative functions on these pins. You should know...i think. :)

[PHolt.1]

This topic comes down to whether "muck" injected into NJTRST will definitely not break something on the CPU.

If the SPI (mapped to the SWD pins, as per this thread) is used for output only then this issue does not arise.

[waclawek.jan]

NJTRST is JTAG pin, not SWD, so if you don't use JTAG for debugging - and there are only marginal reasons to do so, so it's very unlikely you do - there is no "muck" injected into it, the JTAG state machine is disabled as soon the debugger enables SWD, they are mutually exclusive.

JW

[PHolt.1]

What if the chip is powered up without a debugger. Is SWD the power-up default i.e. the JTAG portion does nothing at all unless some "code" is sent on the debug pins to configure it?

[AScha.3]

You see in ds what pins are after reset: here from H533

+

Depending on boot0 pin/signal after reset core starts bootloader or user program.

And after power up the debug unit waits for a "key" sequence, to start swd or jtag actions - or stays sleeping/waiting . So you can still connect "under hardware reset" to the debug unit , even if user program would use the swd pins for other functions and so debug impossible , as soon as user program has control and gpio init is done.

[waclawek.jan]

What if the chip is powered up without a debugger. Is SWD the power-up default i.e. the JTAG portion does nothing at all unless some "code" is sent on the debug pins to configure it?

The power-on default is JTAG, and it does nothing unless - as you say - some "code" is sent to it. This involves wiggling TMS and TCK, as long as these pins are static (rigorously speaking, if TMS is high), nothing happens externally. TMS is pulled up after reset (see GPIO chapter in RM), so if that pin is unconnected, everything is safe. TMS and TCK are also - and not coincidentally - the SWD pins, and to switch on SWD (and disable JTAG), another "magic code" has to be "played" at those two pins; that "magic code" is deliberately designed so that no part of it can generate a valid JTAG instruction, so you can hot-plug the SWD connector while the debugger is playing continuously the "magic code" and it won't switch to JTAG.

TLDR is, that as long as you use the SWD pins only for debugging, you are safe. So yes, some thought went into these things, which are btw. designed by ARM, not by ST.

Just a side note, nTRST is an optional JTAG signal which does nothing with the DUT (i.e. the mcu itself), it just resets the internal JTAG state machine.

JW

[Andrew Neil]

---

@PHolt.1 wrote:

This topic comes down to whether "muck" injected into NJTRST will definitely not break something on the CPU.

---

If you've configured the GPIO to be something other than NJTRST, then no external signals will reach it.

[PHolt.1]

That is an excellent point.

Now let's assume a debugger (which was used to program the FLASH) is still connected. What will that do to the target? 

If you have Cube IDE running, the debugger (in ST SWD mode or in the Segger OpenOCD mode) will be interacting with the target, clocking stuff into the long SWD shift register chain and clocking out the CPU registers, etc. Cube shows this

So the SPI1* (remapped to PB3-PB5) will obviously not work.

I can see three scenarios:

1) Exit Cube IDE. This should stop the debugger activity (maybe; the debugger contains a low-end arm32 chip of some sort) but will its outputs go tri-state?

2) Put a mux on the target PCB, activated by a spare GPIO, so that when you set up the AF mapping to get SPI1 to come out, you flip that GPIO pin to switch the mux to disconnect the debugger. The mux will need a pullup on its selector input so that when the CPU powers up, GPIO floating, the mux ends up in "debugger selected" state.

3) Once the AF is changed to SPI (whether the above mux is used or not) the debugger interface will fail and Cube will automatically drop out from debug mode. It never restarts debug mode (you have to do another build-debug with F11) and quite often this occurs anyway by itself.

* can actually be SPI1 or SPI3, both on the 32F407/417 and the 437

[waclawek.jan]

> So the SPI1* (remapped to PB3-PB5) will obviously not work.

It's not obvious. Why would that be?

As I've explained above, PB4 set to NJTRST has nothing to do with SWD, it's a JTAG signal and JTAG is inactive once the debug interface is in SWD mode.

PB5 has nothing in common with debug at all.

PB3 in SWD mode *can* be set as TRACESWO, so simply don't set it as such - not in program nor in IDE - and you're fine.

As a second thing which makes sure SPI works is, that if PB3 and PB4 are set as AF in GPIO_MODER and to 5 (which is for SPI1) in GPIO_AFR[], the debug functions are disconnected and SPI is connected to these pins.

JW

[PHolt.1 · Accepted solution]

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