STM32H563 gets stuck, and unstuck when connecting the debugger

[massimoperdigo]

Hello everyone,

I’ve encountered some strange behaviour with my PCB using an STM32H563VGI MCU.

The setup includes an array of 10 LEDs, where one additional LED turns on every 2 minutes. Initially, the system worked fine, but after about 10 minutes, I noticed the LED sequence stopped progressing, it got stuck at LED 2.

To investigate, I connected a SEGGER J-Link debugger. Surprisingly, as soon as it was connected, the system resumed normal operation: the MCU printed all messages correctly, and the LED array advanced to LED 5, which was the expected state at that moment. It’s as if simply connecting the debugger “unstuck” the MCU.

I’m using ThreadX as the RTOS.

Has anyone experienced similar behavior? Any ideas what could be causing this?

Thanks in advance for your help!

[Chris21]

"the MCU printed all messages correctly"

How are the messages printed?

[massimoperdigo]

I’m using SEGGER_printf to print debug messages through the SEGGER J-Link.

It looks like the timer responsible for turning on the LEDs every 2 minutes is still working in the background. However, the MCU seems to enter a sleep or blocked state, where it stops running the main application logic (possibly stuck or suspended ??)

When I connected the SEGGER J-Link, the MCU appeared to “wake up” immediately. Since the timer had continued counting while the MCU was “asleep,” several LEDs turned on at once (in my case, up to LED 5) reflecting the expected behaviour had the system been running normally the whole time.

[Andrew Neil]

---

@massimoperdigo wrote:

It’s as if simply connecting the debugger “unstuck” the MCU.

---

Maybe you had a poor earth, and the debugger connection provided a good one?

[massimoperdigo]

what do you mean with poor earth?

the system does not have earth, just power and gnd.

[Chris21]

Perhaps SEGGER_printf blocks if the debugger is not connected.

[massimoperdigo]

No, this is not the case, SEGGER_RTT_printf, does not block if the debugger is not connected.  see this from SEGGER:

Q:  Some terminal output (printf) Solutions "crash" program execution when executed outside of the debug environment, because they use a Software breakpoint that triggers a hardfault without debugger or halt because SWO is not initialized. That makes it impossible to run a Debug-build in stand-alone mode. What about SEGGER-RTT?

A:  SEGGER-RTT uses non-blocking mode per default, which means it does not halt program execution if no debugger is present and J-Link is not even connected. The application program will continue to work.

[Andrew Neil]

---

@massimoperdigo wrote:

the system does not have earth, just power and gnd.

---

A poor GND, then.

ie, the connection from your system to power supply GND is poor

[massimoperdigo]

Sorry, but i do not think this is the case... My PCB has 6 layers, with multiple full GND planes, without splits...
Is it possible that the threadX enters to sleep mode for some reason?

[Andrew Neil]

---

@massimoperdigo wrote:

Sorry, but i do not think this is the case... My PCB has 6 layers, with multiple full GND planes, without splits

---

but what about the connection from your power source to the PCB ?

Have you actually put a scope on the PCB power supply traces to verify that they are stable?