Reassigning STM32 SWD pins to GPIO: is that cleared after a power cycle?

Question

I am trying to connect some dots here and I am missing something (completely?). This is my understanding:

1. An STM32 MCU boots from its bootloader after nRST is pulled low
2. Also a power cycle will have it reboot.
3. Boot pin(s) will help understand the MCU what to load into memory. E.g. from flash by default, or from USB or UART alternatively
4. Flashing using SWD (system by ARM, not vendor specific) does not require nRST to be toggled low. Somehow (I miss that point) programming probes can ‘just’ start talking over the SWD ports, ‘soft’ resetting the MCU and reprogram flash.
5. To me it then seems there is no role for the bootloader in ‘SWD flashing’.

The above assumptions create an OK model of reality for me. I can program and use MCUs that way (on a desk, not real world yet). But I trust not all of it is correct.

Where I become uncertain is when wanting to use SWD designated pins for GPIO. It almost seems SWD itself is an alternative function and I can move it around for larger MCUs (in CubeMX).

I have been looking through examples around this and it seems care has to be taken. But I cannot get my head around it and it is probably because my above model of reality is way too shallow. E.g. I read that it might require ‘using SWD under reset’. That doesn’t fit my model.

My basic questions are:

• Q1: How is it possible that the you can move SWD pins (in CubeMX) and program using the new location afterwards?
• Q2: Why would it matter if I reassign the SWD pins to GPIO as one of the first instructions of my program?
• Q3: How can moving SWD (or using the pins as GPIO) survive a power cycle? Is that the main point I am missing?
• Q4: Is my code actually executed before SWD flashing starts?
• Q5: Is there really no relation between the bootloader and SWD flashing?

The reason for asking is that I have ‘blocked’ some MCU’s from reprogramming when using the SWD pins for something else. Last time it happened was when using the SWD pins as UART and start a debugging session... That didn’t work. But a power cycle did not help either.

I am trying to use an 8 pin STM32G031J6 and I have to use two out of the nRST, Boot0 or SWD pins. That made me dive into the subject leading to the above simplified ‘model’ and open questions that I could not resolve.

Could you shoot at all incorrect assumptions and help me with the answers? Thank you.

Answer 1

The main question is: Under what circumstances do my SWD pins work?

The SWD pins work under any of these conditions:

• The flashed firmware/program does not use the SWD pins for something else. In that case, you can connect to the MCU at any time.
• The bootloader is running instead of the firmware. This can usually be achieved by pulling BOOT0 high on power-up or reset. The main purpose of the bootloader in this context is that it does not reconfigure the SWD pins.
• If the MCU is held in reset while connecting to SWD. (I'm not really familiar with the details. It basically resets the MCU and prevents the firmware from starting.)

Note that both a reset and a power cycle resets the pin configuration the the factory default. So right after the reset and power up, SWD pins are always working.

If the SWD pins are working, you can connect to the device at any time.

I am not aware that you can move the SWD pins. But I might just not have come across it.

In order to make good use of the few pins of your chip:

• With a pull-down resistor, you can easily use the BOOT0 pins for selecting the boot mode at startup and then reassign it as an output pin or input pin with pull-down (be it GPIO, UART etc.).
• Sometimes it's possible to find a setup whereby the SWD pins remain active until a certain event happens (e.g. USB is plugged in) or a certain condition is given at startup (pin X is not held low). Only after the event are the SWD pins reconfigured for a different purpose. That way you can still use them for flashing.

Answer 2

Q1: How is it possible that the you can move SWD pins (in CubeMX) and program using the new location afterwards?

Q3: How can moving SWD (or using the pins as GPIO) survive a power cycle? Is that the main point I am missing?

You can't remap the SWDIO and SWDCLK pins.
Your STM32G031J6 is a bit of a weird boy since it can remap the entire gpio pad instead of only alternate functions.

Q2: Why would it matter if I reassign the SWD pins to GPIO as one of the first instructions of my program?

Typically it wouldn't. Not for the function of the program. But any further connection with the ARM Debug Interface over SWD will then require a Connect-Under-Reset, with NRST asserted.

1. The debug adapter forces reset low.
2. The ARM debug module inside it not affected by this.
3. The debug adapter sets "core-reset" and "halts" the core. Which it what it usually does when you connect without reset.
4. Release reset.
5. Continue programming.

Q4: Is my code actually executed before SWD flashing starts?

Possibly, depends on the debug adapter and how it's controlled.
With STM32Cube IDE your code may start as much as 3 times before it starts flashing. Because it's coupled together with multiple executables that need to run.
With Keil the debugger may hold the chip reset or arm core reset to prevent your app from running.

Q5: Is there really no relation between the bootloader and SWD flashing?

No. But also yes.
Sometimes the flash programming is actually done by having the debugger load a small application to RAM and run it, it then transfers blocks to RAM and has the little program write them to FLASH and request for more.

So fun fact, you can write your own little program to do this for external memory.

Answer 3

I am not an expert of STM32 but I can write my point of view:

• An STM32 MCU boots from its bootloader after nRST is pulled low
• Boot pin(s) will help understand the MCU what to load into memory. E.g. from flash by default, or from USB or UART alternatively

After nRST it starts the program, a custom bootloader can also be a part of it.

Boot pins at nRST invoke the factory bootloader, no program is started.

Flashing using SWD (system by ARM, not vendor specific) does not require nRST to be toggled low. Somehow (I miss that point) programming probes can ‘just’ start talking over the SWD ports, ‘soft’ resetting the MCU and reprogram flash.

Yes, by assigning SWD pins in CubeMX and flashing trough factory bootloader. After that, those pins are reserved for SWD and not being used as GPIO.

In the manuals (different for each family and product) there are tables on default assignment of pins, bootloader for new devices.

The reason for asking is that I have ‘blocked’ some MCU’s from reprogramming when using the SWD pins for something else. Last time it happened was when using the SWD pins as UART and start a debugging session... That didn’t work. But a power cycle did not help either.

It makes sense. You have flashed a new configuration, where SWD pins were, now you have a GPIO (UART) so SWD debuging can't work. Now you can't even flash over SWD. The only way is to flash trough factory bootloader method, I guess by using BOOT pins.