cancel
Showing results for 
Search instead for 
Did you mean: 

H743ZI2 SDMMC with DMA (MDMA)

OHaza.1
Associate III

Hi, I've been trying to use SDMMC1 on the h743ZI2 nucleo board but can't get it to work with (M)DMA (it works without DMA with straight HAL code) as I always get HAL_SD_ERROR_TX_UNDERRUN when trying to format the card.

I have copied the rtos threads from FatFs_uSD_DMA_RTOS however I have used CubeMX to generate the project. the BSP is calling HAL_SD_WriteBlocks_DMA and instead of a transfer complete call-back I get an error one instead.

Have tried various clock speed combinations and Hardware flow control.

I suspect something is not quite right with the DMA initialisation.

Thanks, Oliver

5 REPLIES 5

SDMMC1 has it's own DMA unit doesn't it.

Seem to hear a lot of problems with RTOS's, perhaps you shouldn't yield the processor via the interrupts here. With Write DMA the DMA TC Interrupt will occur significantly before the wire level transfer completes. Tread carefully, wait for the FIFO to empty, and the SDMMC peripheral to complete the current command's data phase.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
OHaza.1
Associate III

Yes.

So after eventually stripping down the original example and getting it to run, and write the file successfully, I compared the SDMMC configuration just before the write.

The only difference was the address on the pointer to the buffer. The example's pointer was above 0x24000000 as opposed to 0x20000000, the DMA controller requires the data to be in the 0x24000000, in the AXI-SRAM space.

I altered the linker .ld script to match the original and it works ok now.

I guess this is a bug/oversight in cube's generation.

Still possible the other issues will occur down the line, though

Mohammed Eshaq
Associate III

I have the exact same problem (STM32H7):

  • FATFS Works find without DMA Templates.
  • I don't have options for DMA in SDMMC (it is internal or IDMA).
  • BSP is calling HAL_SD_WriteBlocks_DMA().
  • HAL_SD_TxCpltCallBack() never gets called.
  • I get HAL_SD_ERROR_TX_UNDERRUN.

How exactly did you solve the problem?

Did you configure (M)DMA to work with SDMMC?

Can you please elaborate on your solution?

OHaza.1
Associate III

Hi you need to use the linker (.ld file) from the Fx_uSD_File_Edit project STM32H735IGKX_FLASH.ld

In it you will see that it moves the memory allocation to be inside RAM_D1. The DMA can use this area of memory , but note between RAM and RAM_D1

 /* Initialized data sections goes into RAM, load LMA copy after code */

 .data :

 {

  . = ALIGN(4);

  _sdata = .;    /* create a global symbol at data start */

  *(.data)      /* .data sections */

  *(.data*)     /* .data* sections */

  *(.RamFunc)    /* .RamFunc sections */

  *(.RamFunc*)    /* .RamFunc* sections */

  . = ALIGN(4);

  _edata = .;    /* define a global symbol at data end */

 } >RAM_D1 AT> FLASH

Hi @OHaza.1​ ,

When working with DMA for STM32H7 devices, you should pay attention to the memory allocation.

The default memory used by most of ST projects is DTCM which is not accessible by DMA in STM32H7 devices.

So, you should change it to something else which is accessible by DTCM (for example AXI SRAM 0x2400 0000). Please refer to the corresponding reference manual, under System Architecture section.

In most cases this can solve the issue. However sometimes for more advanced applications, the D-Cache can affect the functionality of DMA transfers, since the default cache policy for product SRAMs is normal memory (cacheable). Cache will hold the new data in the internal cache and don't write them to SRAM memory. However, the DMA controller loads the data from SRAM memory and not D-Cache. Same behavior can happen when reading data, as DMA will update buffers in SRAM, and the content of SRAM will not be immediately visible to CPU as CPU will see previously cached data. This will result in data coherency issues.

So if changing memory allocation did not solve the problem, you have to disable the D-Cache. But I think in your case changing memory allocation to AXI SRAM (for example) is enough to solve the issue.

STM32CubeIDE/STM32CubeMX do not handle memory allocation settings. So you have to change it manually after generation when you use DMA with STM32H7 devices. But there are plans that memory allocation settings will be added in STM32CubeMX interface in the future.

For more details, please visit these two FAQs:

How to correctly setup your application to use USB DMA controller with STM32H7 devices

DMA is not working on STM32H7 devices

Best Regards,

Ons.

Best Regards,

Ons.