STM32F767Zi-Nucleo SDMMC DMA Write help

[Looke Jean]

Posted on February 20, 2018 at 16:15

Hi

I'm testing F767Zi-Nucleo to write some data to a 16G SD card with no file system.

With 

HAL_SD_WriteBlocks function, everything works fine.

I can read out the data that just have been wrote.

With 

HAL_SD_WriteBlocks_DMA function, no error during excution.

But I can only read out 0x00 in the data block that just been wrote before.

SDMMC controller clock frequency is 4 MHz.

SDMMC1 and SDMMC2 are tested and they both have this problem.

Has anyone encountered same situation?

 Need help.

Thanks a lot.

[John Craven]

Posted on February 20, 2018 at 17:01

There are a bunch of HAL SDIO DMA workarounds on here. Which one applied depends on what HAL version 1.X.0 you are using.

https://community.st.com/0D50X00009XkWt5SAF

It worked for me on the NUC-767

Only change is where &hsd is used, i had to change to &hsd1

[Tesla DeLorean · Accepted solution]

Posted on February 20, 2018 at 17:18

The 4 MHz clock is pretty low, are you sure that doesn't cause some issues? The SDMMC should be clockable north of 48 MHz, and bus clock of 24 MHz.

The F7 you'll need to be careful about the memory you use and the caching/write-back. The SRAM at 0x20000000[0x20000] is ideal as it is TCM and not cached.

DMA also requires that you confirm completion of the write and the flushing of the SDMMC FIFO. DMA has alignment requirements.

I do have SDMMC DMA working on a number of F7 boards, mostly DISCO boards with the microSD socket on-board, should be something back-portable to the F767ZI-NUCLEO with a socket wired up.

[Tesla DeLorean]

Posted on February 20, 2018 at 17:59

//****************************************************************************

//// NUCLEO-144 SDIO/SDMMC//          CN8//        NC   PC8  (D0)//     IOREF   PC9  (D1)//     RESET   PC10 (D2)// (3V3) 3V3   PC11 (D3)//        5V   PC12 (CLK)// (GND) GND   PD2  (CMD)//       GND   PG2  (CS)//// SOCKET (VIEWTOOL)//   VCC  3V3//   GND  GND//   D0   PC8//   CMD  PD2//   CLK  PC12//   D3   PC11//   D2   PC10//   D1   PC9//   CD   PG2////****************************************************************************â€�â€�â€�â€�â€�â€�â€�â€�â€�â€�â€�â€�â€�â€�â€�â€�â€�â€�â€�â€�â€�â€�â€�â€�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

�

[Looke Jean]

Posted on February 21, 2018 at 02:31

Hi John

I'm using Keil MDK-ARM V5.20.

The pack for F7 is STM32F7xx_DFP V2.9.0 and STM32F7xx_HAL_Driver version is V1.2.0.

There is no SDIO but only SDMMC. I'm not sure if they are the same.

[Tesla DeLorean]

Posted on February 21, 2018 at 03:08

Additional note for NUCLEO-144 boards, the PC8/PC9 pins go to CN12 also, there are typically two solder bridges, in this case SB116,SB117 which can be removed to stop there being stubs for the SDMMC D0,D1 pins. Recommend removing for use >25MHz

On the L496ZG and L4R5ZI these are SB136,SB137, and the CS in use is PF3

[Looke Jean]

Posted on February 21, 2018 at 05:37

Hi Clive

Thank you very much for your help.

The reason for this problem is the D-cache.

I add a SCB_CleanDCache() before DMA write to solve this problem.

It works fine now.

[Tesla DeLorean]

Posted on March 02, 2018 at 22:45

I might add that using DMA with SDMMC is something you really want to do. Had a couple situations in longer term testing where I was seeing TX OVERRUN errors with the POLLED variants of code on the STM342F769I-DISCO (800x480 DSI LCD) and STM342F769I-DISC1 (800x600 VGA). This would constitute the bulk of the sample/example code for the F769 DISCO boards.

These will present as write errors in FatFs. At lower layers an overrun, and then a command response timeout.