Trouble with SDMMC driver and STM32F7

[Andrew Messier]

Posted on June 01, 2018 at 02:17

Hi everyone,

I'm using an STM32F777 part, with files generated by the very latest version of CubeMX (4.25.1)

I've spent the day struggling through issues writing a file to an SD card using the fatfs middleware.  I've pretty much followed the path of issues experienced by

Reishauer.Ian

 in these two threads:

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

 

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

 

So far, I've had to add pull-up resistors in the CubeMX configuration for the CMD and data lines (which I understand shouldn't be strictly necessary) and applied these two fixes:

1.  Initialized 'ReadStatus' and 'WriteStatus' to '1' in the respective SD_read and SD_write functions in sd_diskio.c

2.  Reset the state of the peripheral after the ReadBlocksDMA and WriteBlocksDMA with these lines:

__HAL_SD_CLEAR_FLAG(hsd, SDMMC_STATIC_FLAGS);

hsd->State = HAL_SD_STATE_READY;

both of which were discovered and reported in the threads linked above.

Now my code succeeds occasionally (30%-ish?), but when it fails it spins in the following loop in SDMMC_GetCmdResp1

do{    if (count-- == 0)    {       return SDMMC_ERROR_TIMEOUT;    } }while(!__SDMMC_GET_FLAG(SDMMCx, SDMMC_FLAG_CCRCFAIL | SDMMC_FLAG_CMDREND | SDMMC_FLAG_CTIMEOUT));

Has anyone come across this or have a clue what might be wrong?

Thanks,

Drew

null

[Tesla DeLorean]

Posted on June 01, 2018 at 23:18

When you get bored of fighting with CubeMX might I suggest the following as good working templates

STM32Cube_FW_F7_V1.11.0\Projects\STM32F769I-Discovery\Applications\Display\LCD_PicturesFromSDCard

STM32Cube_FW_F7_V1.11.0\Projects\STM32F769I-Discovery\Examples\JPEG\JPEG_DecodingUsingFs_DMA

STM32Cube_FW_F7_V1.11.0\Projects\STM32746G-Discovery\Applications\FatFs\FatFs_uSD

STM32Cube_FW_F7_V1.11.0\Projects\STM32F769I_EVAL\Applications\USB_Host\DynamicSwitch_Standalone\Src\sd_diskio_dma.c

I can construct a workable template for a custom board with a couple of hours of engineering time.

Would need a wiring diagram for the SDMMC interface, and details of serviceable USART and LEDs

I recommend using DTCM RAM for SDMMC buffers, it avoids a lot of DMA coherency issues

[Andrew Messier]

Posted on June 01, 2018 at 23:30

Where can I get these?

[Tesla DeLorean]

Posted on June 02, 2018 at 00:03

In the Cube Repository, check your CubeMX configuration to see where it is putting the .ZIP files, and expanding the HAL trees.

[Andrew Messier]

Posted on June 04, 2018 at 19:02

That project (

FatFs_uSD) worked right out of the box for me.  I just reconfigured it for my chip (STM32F777) and removed the test for the presence pin (mine's not wired up).  The wiring of my project is evidently the same as the example project otherwise.

My question is why would the latest CubeMX drivers not work work with the exact configuration as their previous demo project?  It's as if they never bothered to test it at all.

In any case, I suppose I can add these files to my project instead.  A couple of questions.

1.  Should I use the latet version of FatFS and just bring in the HAL files from the demo project?

2.  Would it be a lot of trouble to add DMA to this project.  I'm not familiar with configuring DMA without the help of the CubeMX drivers.

Thanks.  

[Tesla DeLorean]

Posted on June 04, 2018 at 19:44

I use FatFS R0.13 (87030) internally, have for a year, ST is using R0.12c (68300), the API changed a bit, a tad disruptive. For most testing I've just used the ST version as it seems sufficiently robust, and easier for people to merge/diff. Newer FatFS provide f_size() as a macro, so I use that now.

I would definitely use DMA, unpredictable loading on CPU/BUS results in sporadic underrun errors on SDMMC during writes while driving LTDC/DSI displays. Code changes in sd_diskio.c, and perhaps stm32f7xx_it.c, are minimal and easily merged. Couple of good templates, cited one above, form/function similar across several STM32 families.

Looks like current is R0.13b, might pull that in and evaluate. Found R0.12c/R0.13 solid on media in the 128-200GB range

[Tesla DeLorean]

Posted on June 04, 2018 at 22:01

R0.13b (63463) was an easy merge over the R.013 (87030)

[Forest L]

Hi Andrew, did you manage to get this working? I have a pretty similar problem.

[Tesla DeLorean]

Other threads

https://community.st.com/s/question/0D50X00009ZERPzSAP/problems-interfacing-stm32-w-sdmmcfatfs

https://community.st.com/s/question/0D50X00009XkW7XSAV/fmount-fails-using-stm32l4-w-sdmmc

[David Littell]

Was the original question (SDMMC_ERROR_TIMEOUT in SDMMC_GetCmdResp1()) ever resolved?