ST-Link debugger connection lost after adding DMA to SPI

[SZwie]

With STM32CubeIDE 1.7.0 (Windows) I try to setup SPI2 with DMA at an Nucleo-G431RB.

After starting with an new STM32Cube C-Project for the Nucleo-G431RB with all peripherals at their default settings, I enable SPI2:

• Full-Duplex Master at PB[15:13]
• 8bits
• prescaler at 16
• all other settings at their defaults

A simple

HAL_SPI_TransmitReceive(&hspi2, tx_buffer, rx_buffer, BUFFER_SIZE, 100);

works as expected and I am able to transmit and receive data.

If I then enable the SPI2_RX and/or SPI2_TX DMA in the Device Configuration, I am no longer able to upload the generated binaries to the Nucleo board:

 
STMicroelectronics ST-LINK GDB server. Version 5.9.1
Copyright (c) 2021, STMicroelectronics. All rights reserved.
 
Starting server with the following options:
        Persistent Mode            : Disabled
        Logging Level              : 1
        Listen Port Number         : 61234
        Status Refresh Delay       : 15s
        Verbose Mode               : Disabled
        SWD Debug                  : Enabled
        InitWhile                  : Enabled
 
Waiting for debugger connection...
Debugger connected
Debugger connection lost.
Shutting down...
 

GDB received a timeout when trying to connect to the target.

If I remove the DMA channels of SPI2 from the Device configuration, GDB is able to connect to the target again:

STMicroelectronics ST-LINK GDB server. Version 5.9.1
Copyright (c) 2021, STMicroelectronics. All rights reserved.
 
Starting server with the following options:
        Persistent Mode            : Disabled
        Logging Level              : 1
        Listen Port Number         : 61234
        Status Refresh Delay       : 15s
        Verbose Mode               : Disabled
        SWD Debug                  : Enabled
        InitWhile                  : Enabled
 
Waiting for debugger connection...
Debugger connected
      -------------------------------------------------------------------
                       STM32CubeProgrammer v2.8.0                  
      -------------------------------------------------------------------
 
ST-LINK SN  : 004C003D3039510734393838
ST-LINK FW  : V3J8M3
Board       : NUCLEO-G431RB
Voltage     : 3.28V
SWD freq    : 24000 KHz
Connect mode: Under Reset
Reset mode  : Hardware reset
Device ID   : 0x468
Revision ID : Rev Y
Device name : STM32G43x/G44x
Flash size  : 128 KBytes
Device type : MCU
Device CPU  : Cortex-M4
BL Version  : 0x__
 
 
 
Memory Programming ...
Opening and parsing file: ST-LINK_GDB_server_a09144.srec
  File          : ST-LINK_GDB_server_a09144.srec
  Size          : 11372 Bytes
  Address       : 0x08000000 
 
 
Erasing memory corresponding to segment 0:
Erasing internal memory sectors [0 5]
Download in Progress:
 
 
File download complete
Time elapsed during download operation: 00:00:00.316
 
 
 
Verifying ...
 
 
 
 
Download verified successfully 
 
 
Debugger connection lost.
Shutting down...

Why does adding DMA channels to the device configuration breaks the connection of GDB to the target?

How can I get DMA working at SPI2?

Best regards, Sebastian

[Amel NASRI]

Hi @Community member​ ,

Are you adding the DMA channel via STM32CubeMX interface?

If yes, please pay attention to place the call of MX_DMA_Init() before the call of MX_SPI_Init().

-Amel

[SZwie.1]

Hi @Amel NASRI​ ,

Sure, *MX_DMA_INIT()* is called before *MX_SPI_INIT()* .

What I do not understand is: Why does the debugger connection fails if the binary (which is to be uploaded to the device later) will enable SPI. Looks like a serious software issue in the STM32CubeIDE.

BR, Sebastian.

[SZwie.1]

Hi @Amel NASRI​ ,

I created a screen cast to demonstrate the issue. If you do not mind, watch the 3'30" clip to better understand this issue.

Thanks, Sebastian

[ABrun.5]

Hi, can I see which instruction do you use to call the DMA? Try &rx_buffer[0] instead of rx_buffer.

[mattias norlander]

Hi Sebastian,

TEST1:

Can you open the debug configuration and enable the checkbox under Debugger > Log to file.

Would be interesting to see if we can get some more information in the log then what is seen in the console.

I don't have access to the specific board to try to re-produce the issue.

I wonder if this is related to the additional DMA code or just an unlucky coincident.

TEST2:

Could you perhaps try to perform a mass erase of the device before flashing the image with DMA enabled?

This could be done either by CubeProgrammer stand-alone. Or by adding the following in your debug configuration:

Startup > Initialization commands: monitor flash mass_erase

TEST3

You could also try to program the elf-file with CubeProgrammer only to try to see if the issue is in CubeIDE or CubeProgrammer.

If you have CubeProgrammer GUI version installed then it is easy. If not you can find the CLI version we bundle with CubeIDE somewhere here:

C:\ST\STM32CubeIDE_1.7.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_2.0.0.202105311346\tools\bin\STM32_Programmer_CLI.exe

You could call it with more or less the same argument that CubeIDE (ST-LINK GDB server) uses which can be copied from the debug log, assuming you enabled it..

TEST4:

I label the tests above with TESTx x={1,4} to make sure it is easy to follow your progress. Please share any results with us.

I can see if someone has the board. According to your video it seems very easy to re-produce.

If you are in a hurry, I would only do TEST4, which I think has the best chance of "unblocking" you from progress..

Kind regards, Mattias