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

[KnarfB]

> somehow jumps to 0x1FFFxxxx

Sounds like a reset to the system memory boot loader.

Do you use BOOT0 pin / NRST? How are these pins wired? How are the Option Bytes set?

> 18:39:23:166 : Connect mode: Under Reset
> 18:39:23:166 : Reset mode : Hardware reset

So, NRST is wired to the ST-LINK? 

Anyway, I would use some minimal firmware first to separate HW from SW issues.

hth

KnarfB 

[MM..1]

18:39:23:171 : Debug in Low Power mode is not supported for this device.  Have you use it in app? Is some watchdog used in app or activated in options? 

[emf97]

>Do you use BOOT0 pin / NRST? How are these pins wired?

In this particular chip BOOT0 is aliased with SWCLK, so it's wired to the STLink as such. As the datasheet says:

> Upon reset, these pins are configured as SW debug alternate functions, and the internal pull-up on PA13 (SWDIO) pin and the internal pull-down on PA14 (BOOT0 / SWCLK) pin are activated.

>How are the Option Bytes set?

My code doesn't touch the option bytes, they should be the factory value of 0xDFFFE1AA. However by not being able to connect and actually read them, this is an assumption.

> So, NRST is wired to the ST-LINK? 

Yes, NRST is wired.

[emf97]

>Have you use it in app?

If you're referring to low power mode, no I'm not using it.

>Is some watchdog used in app or activated in options? 

Since the firmware doesn't touch them they should still be the factory value, so no watchdog enabled neither I'm using one.

[MM..1]

Then only PSU instability result to this issues. Bad soldering or wire... Too STLINK cables require be ok.

[KnarfB · Accepted solution]

> undocumented error 10061

This seems to be an error number from windows concerning network/sockets, ask your search engine. Guess this error might go away after rebooting the build host.

When your firmware is running, you may attach SWD to the running code without a reset (hot plug). If this succeeds, you regain control over your firmware.

hth

KnarfB

[Pavel A.]

10061 is WSAECONNREFUSED. Means connection refused, usually because there's nobody listening on that address & port.

[emf97]

>When your firmware is running, you may attach SWD to the running code without a reset (hot plug). If this succeeds, you regain control over your firmware.

It worked, STM32CubeProgrammer successfully connected this way. At least I know the chips aren't fried but it's still a mystery why random jumping to bootloader and refusal to work under reset.

[KnarfB]

Make a stress test that keeps the MCU busy with trivial (==guaranteed bug free) code, like a busy-wait blinky. If possible, observe if the MCU spontaneously goes through a reset (e.g. with a $10 logic analyzer monitoring the blinky pin). As @MM..1 suggested, validate the new hardware.

hth

KnarfB