"bricked" STM32C011J6: SWCLK/SWDIO/nRST reconfigured to GPIO - how to recover?

[wb0gaz]

Owing to a developer (me) firmware blunder, I successfully "bricked" several STM32C011J6 (SO8 package) devices so that I cannot access them using STM32CubeProgrammer and STLINK.

My error was this - my firmware reconfigured pins 7 (SWDIO) and 8 (SWCLK) as GPIO immediately after reset and also initialized pin 1 (nRST) as GPIO at the same time (rather than looking for another pin (button press during power up) that would have held off these steps).

After my errant firmware was installed via STM32CubeProgrammer and STLINK, the STLINK device was/is no longer able to connect to the device.

I am using STM32CubeProgrammer version 2.21.0 and a USB-attached STLINK device.

I have transplanted one of the affected (few) devices to a PCB containing only a connector for the STLINK device, power, ground, and Pin 1 (NRST), so there is no other hardware potentially interfering with STLINK connection.

As pin 1 (nRst) was repurposed at start-up time, I don't believe hardware reset (set by STM32CubeProgrammer) is available.

AN2006 (handily linked from the Document menu) provides some information about STM32C011 family, however, from what I see so far, there is only one boot option image in the system firmware, so I don't believe I can try what I did long ago with STM32F103 in a similar situation, setting another MCU pin to select a different MCU boot option image (i.e., system RAM) in the MCU's system firmware.

These devices are obviously not expensive so at this point I'm able to replace the devices and continue on, but I would like to find a way to recover them in the future when (not if) I blunder in a similar way again.

Happy to provide any clarifying information, experiment as directed, or otherwise cooperate with this discussion!

Thank you

[TDK · Accepted solution]

Unless you've already modified option bytes, it's effectively bricked. Buy another one, replace, and move on.

Set option bytes to boot into system memory if BOOT0 is high.

Or put a HAL_Delay(250) near the start so you can connect before reassigning the SWD pins.

Lots of solutions out there to prevent this, but only one to recover: you will have to "connect" after the chip loads but before SWD pin is reassigned.

[wb0gaz]

Thank you TDK - I was pretty sure I had blundered my way into a lesson, but wanted to be sure I wasn't overlooking something.

At about USD 5, it is a cheap lesson!

(and yes, lots and lots of avoidance mechanisms, I just was careless! Fortunately the walk-in junkbox has yielded some additional parts and I'm pressing on.)