2018-05-31 05:17 PM
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
null2018-06-01 02:18 PM
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
2018-06-01 04:30 PM
Where can I get these?
2018-06-01 05:03 PM
In the Cube Repository, check your CubeMX configuration to see where it is putting the .ZIP files, and expanding the HAL trees.
2018-06-04 12:02 PM
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.
2018-06-04 12:44 PM
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
2018-06-04 03:01 PM
R0.13b (63463) was an easy merge over the R.013 (87030)
2018-08-02 07:58 AM
Hi Andrew, did you manage to get this working? I have a pretty similar problem.
2018-08-02 08:19 AM
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
2018-08-16 12:18 PM
Was the original question (SDMMC_ERROR_TIMEOUT in SDMMC_GetCmdResp1()) ever resolved?