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!

[davideggii]

i cannot use breakpoint, i'm not in debug mode.
i debug mode the code works, in standalone mode works.

the problem is when i run the code in standalone but, after i connected with STM32CubeProgrammer, i press start in the SVW page. In this case the code stops at the DMA initialization

[AScha.3]

Ok, i tried...on H743 , running; connect "normal" with CubeProgrammer : stops running dma...

but: connect in hot plug mode : working.

try...just click swv , then start. 

[davideggii]

Still having the same problem

[AScha.3]

So you start SWV at the running program, in hot plug mode ?

But how can it hang then in MX_GPDMA1_Init() and MX_SPI2_Init() , as this is only at program start ?

+

if you just want debug-messages, the best and most easy way is : use a uart to send the printf() ;

this always working , without using the debug module, and just a simple serial-> USB adapter needed, to see the running messages.

[davideggii]

---

@AScha.3 wrote:

So you start SWV at the running program, in hot plug mode ?

---

yes

---

@AScha.3 wrote:

But how can it hang then in MX_GPDMA1_Init() and MX_SPI2_Init() , as this is only at program start ?

---

The strange thing is that if I swap the two initializations (so MX_SPI2_Init before MX_GPDMA1_Init) the debug messages work. The code obviously stops working on the first attempt to use the SPI, but the debug messages are displayed.

[AScha.3]

So if it stops, maybe you just have to "run" it again, see (whwn connected) in core/registers the green "run" :

cpu halted here (in my case on H7A3 also), if i just click on SWV.

Try: 

- set to hot plug , software reset

- connect

- then click SWV -> start   (works?)

[davideggii]

it stops at the begininning of the code. it executes only HAL_Init and part of DMA_Init.

Even if i press stop and than start again it remains blocked. I've tried also with the configuration of hot plug, but nothing changed

[AScha.3]

Did you try exactly this sequence ?

power cycle the board; if one time click on SWV and got it "blocking", can only full reset by power off;

then try: in CubeProgrammer:

- set to hot plug , software reset

- connect  (not click SWV !)

- if connect ok, target should still run fine ; then click SWV -> start (works?)

[davideggii]

I've tried exactly that sequence.

It not works

[Aziz BRIGUI]

Hello @davideggii,

Can you try the CLI option:

STM32_Programmer_CLI -c port=swd mode=hotplug -startswv

Aziz