Recover bricked STM32 MCU | STM32G041F6P6

[arjun.binu]

During the process of configuring option bytes, we unfortunately got few MCUs bricked (unresponsive). 

In these devices, i was getting the following errors when trying to flash using STM32 programmer. (Tried both GUI and CLI with various reset modes and frequencies). All attempts resulted in the same error as shown below.

Error: No STM32 target found! If your product embeds Debug Authentication, please perform a discovery using Debug Authentication

Could you suggest a way to recover these devices from the bricked state?

For your information, these were the option bytes configuration done along with the Flash unlock/lock sequences during runtime 

Are there any issues with the Lock/Unlock sequences used here? Should I not Lock the flash after configuring the option bytes?
This made me to think about configuring the option byte at the time of flashing using STM programmer CLI. Is this best way to proceed?

STM32G0 Series   IWDG-WWDG

[TDK]

The problem is that the program will always go into the loop as USERType will never be only OB_USER_OWDG_STDBY. Step through the code to understand what it's returning here. The rationale is fine apart from this faulty check.

To recover, connect under reset in STM32CubeProgrammer, or hold BOOT0 high during reset to boot into the bootloader, then connect and recover.

[Tesla DeLorean]

Can't you configure and lock for user space code? Something you can initiate once successfully working? Perhaps also with a method to erase or unlock to permit recovery. 

[Feng XIONG]

Upon an option byte programming failure for any reason, the mismatch values of the option bytes are loaded after reset. Those mismatch values force a secure configuration that might permanently lock the device.

Please connect your board to STM32CubeProgrammer in "Under reset/hardware reset" mode, in OB/User Configuration, check the values of nBOOT_SEL, nBOOT1 and nBOOT0, you can either use the OB or the physical BOOT0 pin to configure the MCU to boot from system memory.
After the boot configuration completes, configure the RDP level to Level 1 (0xBB). Disconnect the board and reconnect.
Then do a regression to set the RDP to Level 0 again to perform a full mass erase.
If this procedure still can't recover your device, the MCU is locked and can't be recovered.

As for the flash option byte programming, please refer to and follow exactly the steps in chapter 3.4.2 of RM0444.
https://www.st.com/content/ccc/resource/technical/document/reference_manual/group0/2f/21/cb/33/78/80/42/64/DM00371828/files/DM00371828.pdf/jcr:content/translations/en.DM00371828.pdf

There are some problems in your code, HAL_FLASHEx_OBProgram() in STM32CubeG0 is provided to perform the OB programming. Please follow its implementation.
https://www.st.com/en/embedded-software/stm32cubeg0.html

[arjun.binu]

Actually the main issue which we are facing is to connect the MCU using STM32CubeProgrammer. We have tried all the possible reset options and at various frequencies but couldn't get it connected. 
It seems that MCU is locked.
Thanks for the STM32CubeG0 repository. I will look into it for a safer implementation.