STM32F746g SD card no already existing solution works

[jendoubi saif ddine]

Posted on March 31, 2018 at 19:38

Hello everyone i've been working on a project using STM32F746g and i found many diffculties but this one is the most hard one and i couldn't solve it for weeks, i can't acces the SD card, tried everything /solution in this forum / youtube ... etc..  Everything would seem fine when i creat the project it compile fine , when i debug it, it get stuck  in   if(FATFS_LinkDriver(&SD_Driver, SDPath) == 0) 

I tried the suggested solutions change the code did everything ... always nothing works i really need help ASAP

#stm32f746-discovery #linkdriver #fatfs #sd-card-

[jendoubi saif ddine]

Posted on March 31, 2018 at 19:47

I tried the examples and they work fine , i don't know why when i create my own project it doesn't work

\STM32Cube\Repository\STM32Cube_FW_F7_V1.7.0\Projects\STM32746G-Discovery\Applications\FatFs

[Tesla DeLorean]

Posted on March 31, 2018 at 20:21

>> i don't know why when i create my own project it doesn't work

Because CubeMX isn't very robust, there are also issues with DMA and Cache coherency. Make sure to use most current CubeMX and HAL libraries so you aren't re-litigating issues/bugs that get fixed over time.

All these are reasonable workable example

\STM32Cube_FW_F7_V1.11.0\Projects\STM32746G-Discovery\Applications\Display\LTDC_PicturesFromSDCard

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

\STM32Cube_FW_F7_V1.11.0\Projects\STM32746G-Discovery\Applications\LibJPEG\LibJPEG_Decoding

That said you really want to be using DMA if you are writing data and using the LTDC/DSI interfaces otherwise you're likely to observe UNDERRUN errors

[jendoubi saif ddine]

Posted on March 31, 2018 at 20:31

Thanks for the reply,

I'm really new to all of this, and about the examples i know that they are working fine but when i open them on keil and let's say i want to add 'ADC' or 'LCD' it generates lots of errors is it impossible to combine two projects under keil ? otherwise that would be easier for me ..

[Tesla DeLorean]

Posted on March 31, 2018 at 22:56

HAL typically requires you do two things

a) Enable the modules your code will be using in stm32f7xx_hal_conf.h

b) The source for the library files is dropped into the project tree, often under Drivers/STM32F7xx_HAL_Driver group.

Review several example projects that pull in different components, and also the templates

[GreenGuy]

Posted on April 02, 2018 at 02:18

I am having the same issue.  It is unfortunate that neither CubeMx or the examples are helpful.  CubeMx produces code that compiles but fails to operate and the examples while compiling and operating cannot be rebuilt outside of the repository without incurring serious dependency failures.  Trying to integrate code from one example into another also has similar issues.  If the answer is to use examples as guides and write my own code from scratch then I fail to see how this is in keeping with the spirit of CubeMx which is, 'to make developers’ lives easier by reducing development effort, time and cost.'  Quote taken from UM1718 Rev 25, User Manual, STM32CubeMX for STM32 configuration and initialization C code generation.  I have listen and carefully followed every work around proposed based on other discovery or eval boards.  There is always the comment 'Your mileage may very' which I have found to be not much of a comfort; for in every case, nothing has worked.

In my most recent attempt, I generated a Cube project based on F746G-Discovery with all the peripherals initialized, FatFs selected with SD selected as the device.  With the CubeMx spirit in mind, I should then be able to simply f_mount, f_open and f_write/f_read as needed. 

I should not have to debug and modify the FatFs Middleware, the HAL, or the BSP code. 

I should not have to provide my own customized code to make up for that which is lacking in the generated code or BSP. 

I should not have to reverse engineer the board and associated code to get basic FatFs working.

I was able to discern that CubeMx generated a BSP file called bsp_driver_sd.c and placed in my User/src directory which was meant to replace the stm32746g_discovery_sd.c file in the BSP/STM32746G-Discovery folder.  Having both files in the build creates obvious duplication.  I really had to dig through repository code to determine that the bsp_driver_sd.c code was being produced from a template sd_diskio_dma_rtos which I can only assume at this point was meant to replace the sd_diskio_dma_rtos.c file in the example code.

This has all cost me over a month of development time with still yet no solution.

Someone from ST needs to own this.