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.

[Chris21]

Perhaps SEGGER_printf blocks if the debugger is not connected.

[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.

[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

[Andrew Neil]

---

@massimoperdigo wrote:

To investigate, I connected a SEGGER J-Link debugger. Surprisingly, as soon as it was connected, the system resumed normal operation

---

What, exactly, do you mean by, "connected" here?

• Just physically plugged-in?
• With an active debug session?
• other?

[massimoperdigo]

I connected the SEGGER J-Link and opened the J-Link RTT Viewer, which doesn’t start a full debug session, it’s only used to read non-blocking messages printed via SEGGER_RTT_printf.

As soon as I connected to the MCU using the RTT Viewer, the system seemed to unblock and resumed normal operation. The internal timer appeared to have been working correctly the entire time, as 5 LEDs turned on immediately, indicating that 10 minutes had passed, which aligns with the expected behaviour.

[Andrew Neil]

So just plugging-in the connector makes no difference - it's not until you actually connect RTT that your target "unblocks" ?

Have you asked Segger about this? They may have insight into what happens during/after an RTT connection which might cause this...
https://forum.segger.com/index.php/Board/3-J-Link-Flasher-related/?s=35d02df31511720cdf7a9f94838ca4a097a95584

 

---

@massimoperdigo wrote:

opened the J-Link RTT Viewer, which doesn’t start a full debug session.

---

I'm not sure that it makes any difference as far as the core is concerned ? 

As far as the Core is concerned, I think it's all just a DAP connection?

Again, Segger may be able to clarify that.

 

Does your code have anything which checks for a debugger connection; eg, to allow debug through sleep modes, prevent disabling debug pins, etc?