STM32G030 Connection to device lost

[emf97]

Hi,

I'm working on a STM32G030C8T6 based personal project and recently done a revision 2 to fix some annoyances and add some status LEDs. Programming and debugging is done via a STLink V3 and the SWD. I've encountered twice the same strange behaviour, with the second time replicating the first step-by-step:

1. Board is all wired up, I open STM32CubeIDE and launch debugging. Debugger connects without problem to the board and upload the firmware to it. Just to see if everything is working properly I step through the code.
2. HAL_Init() executes without problems, SystemClock_Config() (configured with CubeMX and known to work as intended in the previous hardware) somehow jumps to 0x1FFFxxxx. I find it strange and I do a terminate and relaunch.
3. In the second attempt SystemClock_Config() executes normally but it doesn't go much further: this time it's a memset() that makes the code jump to 0x1FFFxxxx.
4. I decide to power cycle the board. The board has its own PSU which is fed from a bench power supply and I cut-off this one to power cycle the board.
5. Now the strange part. The firmware start executing as intended (I can see it from the status LED and in particular the heartbeat pulsing); it does react to my inputs the way I expect to. However, if I try to enter debug mode the debugger fails to connect, citing an "undocumented error 10061".
6. I open STM32CubeProgrammer and try to connect and the connection fails. Sometimes it fails to read the option bytes, sometimes it goes "connection lost to device". Below is a level 3 verbosity of a failed attempt

Spoiler

18:39:23:057 : UR connection mode is defined with the HWrst reset mode
18:39:23:165 : ST-LINK SN : 00320017544B500520343637
18:39:23:165 : ST-LINK FW : V3J15M6B5S1
18:39:23:165 : Board : STLINK-V3SET
18:39:23:165 : Voltage : 3.30V
18:39:23:166 : SWD freq : 8000 KHz
18:39:23:166 : Connect mode: Under Reset
18:39:23:166 : Reset mode : Hardware reset
18:39:23:166 : Device ID : 0x466
18:39:23:166 : Revision ID : Rev 1.1
18:39:23:167 : Reading data...
18:39:23:167 : r ap 0 @0x1FFF77DD 0x00000004 bytes Data 0xFF000030
18:39:23:167 : Reading data...
18:39:23:167 : r ap 0 @0x1FFF77DD 0x00000004 bytes Data 0xFF000030
18:39:23:167 : Reading data...
18:39:23:168 : r ap 0 @0x1FFF75E0 0x00000004 bytes Data 0xFFFF0040
18:39:23:168 : Reading data...
18:39:23:168 : r ap 0 @0x1FFF77DD 0x00000004 bytes Data 0xFF000030
18:39:23:169 : Reading data...
18:39:23:169 : r ap 0 @0x1FFF77DD 0x00000004 bytes Data 0xFF000030
18:39:23:169 : Reading data...
18:39:23:169 : r ap 0 @0x1FFF77DD 0x00000004 bytes Data 0xFF000030
18:39:23:170 : Reading data...
18:39:23:170 : r ap 0 @0x1FFF75E0 0x00000004 bytes Data 0xFFFF0040
18:39:23:170 : Database: Config 4 is active.
18:39:23:170 : flash loader C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin/FlashLoader/0x466.stldr is loaded
18:39:23:171 : Debug in Low Power mode is not supported for this device.
18:39:23:171 : Reading data...
18:39:23:171 : r ap 0 @0x1FFF75E0 0x00000004 bytes Data 0xFFFF0040
18:39:23:171 : r ap 0 @0x1FFF1FFE 0x00000004 bytes Data 0x00000053
18:39:23:172 : fail @0x00000001
18:39:23:712 : r ap 0 @0x1FFF1FFE 0x00000004 bytes Data 0x00000053
18:39:23:712 : fail @0x00000001
18:39:23:712 : UPLOADING OPTION BYTES DATA ...
18:39:23:712 : Bank : 0x00
18:39:23:712 : Address : 0x40022020
18:39:23:712 : Size : 108 Bytes
18:39:23:712 : Reading data...
18:39:23:713 : r ap 0 @0x40022020 0x0000006C bytes Data 0xDFFFE1AA
18:39:23:713 : Bank : 0x01
18:39:23:713 : Address : 0x40022080
18:39:23:713 : Size : 4 Bytes
18:39:23:713 : Reading data...
18:39:23:713 : r ap 0 @0x40022080 0x00000004 bytes Data 0x00000000
18:39:23:714 : UPLOADING OPTION BYTES DATA ...
18:39:23:714 : Bank : 0x00
18:39:23:714 : Address : 0x40022020
18:39:23:714 : Size : 108 Bytes
18:39:23:714 : Reading data...
18:39:23:714 : r ap 0 @0x40022020 0x0000006C bytes Data 0xDFFFE1AA
18:39:23:715 : Bank : 0x01
18:39:23:715 : Address : 0x40022080
18:39:23:715 : Size : 4 Bytes
18:39:23:715 : Reading data...
18:39:23:715 : r ap 0 @0x40022080 0x00000004 bytes Data 0x00000000
18:39:23:715 : r ap 0 @0x1FFF1FFE 0x00000004 bytes Data 0x00000053
18:39:23:715 : fail @0x00000001
18:39:23:715 : UPLOADING ...
18:39:23:716 : Size : 1024 Bytes
18:39:23:716 : Address : 0x8000000
18:39:23:716 : Read progress:
18:39:23:716 : Reading data...
18:39:23:716 : r ap 0 @0x08000000 0x00000400 bytes Data 0x00000000
18:39:23:716 : Data read successfully
18:39:23:716 : Time elapsed during the read operation is: 00:00:00.003
18:39:23:882 : Unable to retriev Rom table address from AP0
18:39:23:882 : r ap 0 @0x1FFF1FFE 0x00000004 bytes Data 0x9DC10015
18:39:23:882 : fail @0x00000001
18:39:24:059 : Error: Unable to get core ID
18:39:24:059 : Error: Unable to get core ID
18:39:24:059 : Warning: Connection to device 0x466 is lost
18:39:24:605 : Disconnected
18:39:24:605 : Disconnected from device.

If this was only a single board I would've concluded that some kind of hardware fault happened but I tried again on a second board, following the same procedure and the same behavior happened: the board is executing the firmware as intended but I'm unable to connect to it. I've tried to lower the SWD frequency but to no avail. Given the repeatability of this I'm now afraid to assemble a third board just to have it soft-bricked again.

Any idea if this is recoverable or what is going on would be appreciated. Thanks

Edit: typos

[emf97]

> observe if the MCU spontaneously goes through a reset

This has been particularly elusive: entering debug mode in STM32CubeIDE somehow make the MCU undergo a reset event, which I don't observe if I just let the board alone. I've done some further investigation into this matter:

1. Poking the memory confirms the option bytes are still set to the factory default value: BOOT0, IWDG and WWDG are disabled.
2. If I don't connect to the board and leave it be, the code goes through its initialization and reaches the main loop. The blinky on the board flashes on and off and everything is fine.
3. If I connect to the board the code doesn't ever reach the main loop. The jump to the bootloader isn't random but happens always at the exact same spot. However, if I forcefully disable IRQs at the beginning of the main() the code proceeds until the point they're reenabled.
4. I've added a line to clear the RCC_CSR register before reenabling the IRQs and noticed that after the jump PINRSTF and SFTRSTF flags are set.

Any idea would be appreciated