STM32H563RIT freezes during GPDMA1 initialization with CubeProgrammer SWV

[davideggii]

Hello everyone,

I’m working on a project based on the STM32H563RIT, and I’m encountering an issue related to SWV trace when using STM32CubeProgrammer.

The firmware runs correctly in both debug mode and standalone. The problem appears only when I connect to the target with STM32CubeProgrammer and attempt to read the SWV trace. When I do so, the MCU freezes during the initialization phase, specifically inside MX_GPDMA1_Init(), where the DMA used for SPI communication is configured.

As part of the investigation, I also provided the main.c file, where the full list of initialized peripherals and their initialization order can be seen.

For testing, I tried swapping the initialization order between MX_GPDMA1_Init() and MX_SPI2_Init(). With this modification, the firmware starts even while connected to CubeProgrammer, but later freezes when SPI is used in DMA mode, since SPI ends up being initialized before the DMA.

My questions are:

• Why does connecting with CubeProgrammer and reading SWV cause the STM32H563RIT to stall during GPDMA1 initialization?

• Are there any known limitations or interactions between SWV trace and GPDMA on the STM32H5 series?

• What is the correct or recommended initialization order for SPI + DMA in this scenario?

Any help, suggestions, or documentation references would be greatly appreciated.
Thank you!

[AScha.3]

Hi,

> Are there any known limitations or interactions between SWV trace and GPDMA 

Did you check errata sheet for this ?

+

can you attach your ioc , just to see, what you set ?

[davideggii]

Yes i checked and i didn't found anything.

I attached the .ioc file

[AScha.3]

Seems ok , and your program "runs correctly in both debug mode and standalone. "

But problem with SWV active - so question is: what you do in SWV ?

- you cannot "view live" something in Mbit range : all data is transmitted serial like uart, at 2 Mbit or so.

- "reading" a value from an input might change state of receiver : input "readed" now

+

Dont trace, just use printf to get debug info or message from your running program: then also problem there ?

[davideggii]

I only use it as a debug. I print only some debug infos

[AScha.3]

Whats not obvious to me: you write SWV trace , but want only debug messages, so you should set it:

nothing than the port "0" enabled:

[davidstan]

The STM32H563RIT freeze during GPDMA1 initialization while SWV tracing is active points to a conflict between the DMA setup and the debug peripheral's state. Since the code runs fine otherwise, the issue is likely SWV bus interference or a timing conflict during the GPDMA clock or register writes. The best solution is to limit SWV to only Port 0 for debug prints to reduce data load, or use breakpoints to pinpoint the exact line of failure.

[davideggii]

I'll try to explain the problem I'm having again because I think there's a misunderstanding.
I just want to print some debugging information. To do so, I enabled everything in the debug configuration as your picture shows, and it works fine in debug mode.

It also works when I try to run the code in standalone mode, while when I press the start button in the SWV interface it doesn't work.

For testing, I always use the STM32CubeProgrammer to get a log containing the same information I printed in debug mode. To do this, I connect the nReset, SWO, and SWLK pins to the stlink and launch the code using the start button in the STM32CubeProgrammer's SWV interface, as shown in the figure.

I usually get the same output as in debug mode, but not in this case. To understand why I added a printf before and after each init, I noticed that it stops printing after DMA initialization. That's why I assumed the code stopped there.

[AScha.3]

Hmmm, ok.

I assumed you start it in the IDE , as i do.

Try it in IDE , in debug session see output in SWV console. This had no side effect in my experience.  

[davideggii]

In the debugging session on the SWV console, it works. But it remains a debugging session and therefore is far from field testing.

anyway thanks for the help