Help using SWD and NRST as GPIO safely - STM32G031

[NGD]

Hi, so I've chosen to use STM32G031J6M6 8-pin version for an audio level meter project to get me started. I'm using pin 1 as the adc input, 2 and 3 are 3v3 and gnd, obviously. I was hoping to use the remaining 5 pins as GPIO outputs attached to LEDs for the level display. I'm using the DISCO board to program.

​

I'm pretty sure I bricked one of my chips already though, I think because I assigned the NRST (pin4) as well as the SWDIO and SWDCLK (pins 7 and 8) as GPIO outs and I guess then that there was no way to hold the chip in reset and program or debug it? The only other thing I did before it was unresponsive was to probe some of the board traces with my multimeter in diode/continuity mode.

​

I'm trying to be careful not to break another chip so I wanted to be sure before assigning those pins.​

Is there a way I can use all these pins as GPIO output but not lock myself out of programing / debugging the chip? I read something about maybe adding a delay before the pins are assigned? Would this be as simple as placing a HAL_Delay(1000) towards the top of the main function in main.c? I'm using the CubeIDE and it's auto code generation functionality to assign the pins. I am still fairly new to this level of MCU programming having come from using Arduino so I might need baby steps.

​

Thanks.

​

​

[Tesla DeLorean]

You'd want the delay in the Reset_Handler, and not dependent on interrupts and C code. You're trying to buy some time for the debugger to intercede, and if you can't use NRST, perhaps gate the power, in your debug harness / fixturing.

The UFQFPN28 or UFQFPN32 are either smaller, or of equivalent physical size.

[NGD]

Thanks for the reply. I'm partly using the 8 pin chip because it means I can solder it by hand, I don't have a hot air station so those UFQ chips are out if the question for my purposes, I also have a bunch of them in my parts drawer.

​

How would I add a delay to the reset_handler if not in the C code?

​

I​ can power cycle the board by hand by unplugging the USB cable or just the chip by removing the 3v3 the line.

​

My understanding is that when power is initially applied the pins are in their default states before they are assigned based on my code. I guess it's before they are assigned that I need to introduce a delay so I have time to upload new code, attach the debugger or to hold NRST so I can do a flash under reset thing?

​

Sorry for my basic questions, I'm still getting my head around all this. Hopefully I'm not asking the impossible.​

​

Thanks.​

[MM..1]

I mean for developing debug time you need dont use pin NRST in code. You can test function code for this pin on other pin and as last prog code with use this pin and deactivate NRST.

For get access to chip after this, you can prepare in your code test sequence check on NRST or other pin for onstart states and skip configure NRST ...

[NGD]

Ah that sounds closer to what I'm after.

​

How do I check onstart states? Is there a HAL command for that? Or a #define I can use in an #if statement?

​

I guess this way, if I wanted to program or debug I would say... hold one of the pins high during power on and I could skip configuring the pins or if it is instead connected to the LED it wouldn't be high so would proceed to configure the pins and then run the code.​

​

Does this sound right or am I misunderstanding?

​

Thanks again.​

[gbm]

1. For debugging and programming, NRST is not needed. SWDIO and SWCLK are enough. In G030, NRST is hard-configured in Option bytes, so you can't disable NRST in software. This is not a problem really.
2. If you use HAL, there is 1 ms SysTick interrupt already active. If you don't use HAL, then you surely have some timer interrupt. Leave SWDIO and SWCLK initially in the default state; count to 5..10 seconds in timer interrupt then set the fuctions of these pins as required by your application. Just make sure you don't put the CPU to sleep during that time, as in M0+ core this prevents debug connection. That's how I handle it in my devices based on G030 in 8-pin case.

[NGD]

Thanks for the response. So I guess I'd have to add this delay in 'int main(void)' right?

The generated code goes: HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_ADC1_Init(); MX_TIM16_Init(); HAL_TIM_Base_Start_IT(&htim16); then into the while loop.

From what you have said I'm guessing that the HAL_Delay(5000); should be added after SystemClock_Config() but before MX_GPIO_Init(). Is this correct?

Yeah I discovered yesterday to use the NRST pin I'd have to use STM32CubeProgrammer to set the User Option Byte so I can use that as GPIO. Attempting to use it before doing that (ie. setting it to GPIO output and attaching an LED through a current limiting resistor) just seemed to keep the chip in a reset state.

So to reiterate, If I am to set the NRST user option byte so that it is a GPIO output and I am also to set the SWDIO and SWDCLK pins as GPIO outputs I am likely to lock myself out of reprogramming or debugging the chip unless I prepare it before hand with this 5 to 10s delay which will give me a window of opportunity to access the chip from power on before it reassigns the pins.

Am I talking sense? Thanks again.

[Markus GIRDLAND]

Hello there,

Normally the debugger should be able to connect, program and control the device regardless of your application code. The debugger will override your application code and configure the debug related registers to allow debug assuming that your debug configuration is properly set up.

Which reset behavior are you using to connect to the MCU? You should rely on connect under reset if you don't want your application code to interfere with the debug experience. This will keep the NRST pin under reset until the debugger is connected and in control.

Assuming this works there is no reason to keep any delays in the startup code.

If I misunderstood the problem you are facing then let me know!

Extra hint: Use STM32CubeProgrammer to connect under reset and perform "mass erase" as the first approach to "un-brick" a board.

[MM..1]

Markus Maybe you dont read carefuly, here is question about 8 PIN package, that resulty –2 pin power and –2 SWD to only 4 usable pin in debug code. Plus if code activate SWD pins for other purnpose –1 pin for NRST and here only reprogramming is possible no debug...
If user activate SWD+NRST = no next reprogramming + no debug – without special code on app start.

[Danish1]

I’ve played with an 8-pin G030 and one thing I found was that during a reset (either power-on-reset or wakeup from e.g. shutdown) the G030 would drive the reset pin low - no matter what was programmed into the option bytes. (The documentation states that the option bytes are only read after reset and this is a consequence). So you don’t have full freedom on that pin.

I like to get the code (largely) right before enabling code-readout-protection. And I could spare the Swdio and Swclk pins for that application. So while doing most of the development I could debug freely. But if you need to use those pins, and are happy to do more “burn and crash�? development then a startup pause (a few seconds) during which swd is enabled is an option. Of course this is just for the “debug�? build - you don’t need the delay in the “release�? build.

To allow me to enable code-readout-protection level 1 was have a certain power-on pattern of GPIO pins which my codd would recognise as impossible, and under those circumstances go back to protection level 0 (and erase the FLASH in the process). So I could recover the chip and start again.

Hope this helps,

Danish

[Antoine Odonne]

Hello,

Upon power up, even if NRST is reconfigured as GPIO by OB, it act as NRST until it reaches high level. As mention by Danish, the OB loading (taking the information of NRST config is done after Power sequence or upon shutdown exit).

So I think you could pull down this NRST line, supply your chip and then try to connect under debug and then release this NRST line. It could help to recover your bricked parts.

Best regards,

Antoine

[robtor]

Hello,

I tried to do as you say and the problem was solved. I had some chips stuck. Thanks for your help.

Best regards.

Roberto