From my mislead I put HAL_PWR_EnterSTANDBYMode() in the code whithout any wakeup behaviour, which made my chip unable to debug via SWD interface. So I can not either erase, upload new code or do anything with this chip.
I have an Aliexpress ST-Link V2 dongle for programing and debug. I connected the terget to the dongle with the following wires:
- 3,3V
- GND
- SWDIO
- SWCLK
- NRST
I hoped that NRST will hold the target from running my broken code, but it is still not programmable and debuggable (I turned Reset behaviour setting to "Connect under reset").
The second thing I tried is to connect BOOT0 pin to VCC while power up. The problem is that my chip is STM32G030F which has BOOT0 and SWCLK on the same pin (PA14). So I tried to power up while PA14 (BOOT0) was connected to VCC and then – I disconnected PA14 from VCC and connected PA14 (SWCLK) to USB dongle. Same thing: no effect.
What else can I do to wake up my chip from standby mode?
Best Answer
Connecting the SWD with NRST asserted, halting the core, releasing reset and doing a mass erase will work.
The problem is NRST. A lot of software tools default to commanding reset via an SWD sequence, not using the hardware signal until you find a buried mode option.
Worse, your "fake" ST-Link probably cannot drive its NRST signal at all, as those boards all seem to have a mismatch between physical connection and firmware so the pin toggled by the MCU never makes it to the connector.
Using a fully functional debug adapter that acutally drives NRST is going to be key if you work with suspend modes, as you'll see this issue over and over. You could get a real ST-Link or whip up a CMSIS-DAP in a supported eval board, etc. Black magic firmware might fix your fake, or you can consult schematics and do microsurgery on it, easier if it's a TQFP than QFN inside. Have a raspberry pi? You can use the GPIOs as an SWD under openocd, just don't try to steal its 3v3 but regulate your own.