Rewiring PF2-NRST to GPIO - Does this brick SWD debugging?

[NGall.5]

Hello, I need the PF2-NRST pin on the STM32G0C1 chip as an MCO. 
Thus, I had to change the user flash to use the pin in GPIO mode. While I had doubts about this approach's validity since we are fiddling with the NRST, I still went ahead with it. 

Now the pin is in GPIO mode, but surprise, reflashing new software with the ST-Link doesn't work anymore.
Error in ST-Link: The interface firmware FAILED to reset/halt the target MCU 
Is there any possibility of unbricking this by booting from the embedded SRAM or the system memory?

Kind regards for any help. 

This was the code I used to create a paperholder:

void ConfigureNRSTasGPIO(void)
{
 FLASH_OBProgramInitTypeDef OBInit; // Option Bytes configuration structure

 // Unlock the Flash Control Register
 HAL_FLASH_Unlock();
 HAL_FLASH_OB_Unlock();

 // Configure the Option Bytes
 HAL_FLASHEx_OBGetConfig(&OBInit); // Get the current configuration

 // Set the NRST mode to GPIO
 OBInit.USERType = OB_USER_NRST_MODE;
 OBInit.USERConfig = FLASH_OPTR_NRST_MODE_1;

 // Write the Option Bytes configuration
 HAL_FLASHEx_OBProgram(&OBInit);

 // Launch the option byte loading
 HAL_FLASH_OB_Launch();

 // Lock the Flash Control Register
 HAL_FLASH_OB_Lock();
 HAL_FLASH_Lock();
}

 

[Andreas Bolsch]

Sounds like you've reconfigured PA13/PA14 away from SWD as well, as NRST is usually not needed for SWD connection. If so, and if you've touched BOOT_LOCK etc. or your firmware clears DBG_SWEN, there is a good chance that you're locked out irreversibly.

In theory there might be a short intervall after a power-up reset before option byte loading finished during which the debugger might have a chance to attach and halt the CPU, but that's quite a narrow window.

[NGall.5]

I thought aswell that NRST is not needed for SWD but when connecting with the CubeProg in Normal or HotPlug mode I get the same behaviour. 

The PA13 and PA14 pins should not have been tampered with and worked before this firmware flash.

 I can't tell you the exact makeup, though, since we are developing with Zephyr, and I am unable to find the SWD settings in the DTSI.

BOOT_LOCK or DBG_SWEN should not have been touched. 

What I tried else:
I already tried setting the BOOT0 pin on the STM32G0C1E-EV to Vcc by connecting CN9 pin 8 and 6. As far as I understand, I cannot set the option bites while not connected with the CubeProg or without HAL functions over Zephyr.

 I have already had a look at the AN2606 but couldn't see what connection over the ST-Link is easily accessed.

(Connecting UART over the VCOM for example leads to nothing)

 

At the same time when connecting to the UART1 bootloader with a Analog Discovery I also don't see any output.

 

Thank you for your time.

 

[AScha.3]

+ set st-link connection : reset mode -> software reset

[NGall.5]

Same behaviour with Normal and HotPlug mode. 

Log:
08:55:04 : UR connection mode is defined with the HWrst reset mode
08:55:05 : ST-LINK SN : 066EFF544855888367165521
08:55:05 : ST-LINK FW : V2J42M27
08:55:05 : Board : STM32G0C1E-EV
08:55:05 : Voltage : 3.24V
08:55:05 : Error: No STM32 target found! If your product embeds Debug Authentication, please perform a discovery using Debug Authentication

In the log it displays HWrst reset mode even though the Prog reset mode is set to software reset. 

Thanky ou for your time.