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.

 

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:

 

[PHolt.1]

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.

[PHolt.1]

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]

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

[PHolt.1]

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]

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

[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

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

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

 

 

 

 

[PHolt.1]

Turns out that page 873 of the 32F417 RM has this note

My interpretation of it is that this is fine provided your code does not re-initialise these pins until the debugger has finished with them.

When they say "disable both JTAG/SWD interfaces" they surely mean when the debugger has finished, because user code has no means of controlling JTAG/SWD.