STM32CubeMX v4.26 SD Card Problem Continues [STM32F4 Discovery]

[Ogulcan Ariyurek]

Posted on June 19, 2018 at 14:21

Hi,

I've been dealing with the SD card problem since the CubeMX version 4.

Here are the corresponding parts of my code:

...

...

...

/* USER CODE BEGIN PV */

/* Private variables ---------------------------------------------------------*/

FATFS myFATFS = {0};

FIL myFILE;

UINT testByte;

/* USER CODE END PV */

...

...

...

/* USER CODE BEGIN 2 */

if(f_mount(&myFATFS, SDPath, 1) == FR_OK){

char myPath[] = 'WRITE1.TXT\0';

f_open(&myFILE, myPath, FA_WRITE | FA_OPEN_ALWAYS);

char myData[] = 'Hello World\0';

f_write(&myFILE, myData, sizeof(myData), &testByte);

f_close(&myFILE);

HAL_Delay(1000);

}

/* USER CODE END 2 */

...

...

...

Here, the problem is in f_mount, it doesn't go forward. Debugging further, the code stucks in 'ff.c' file at the following bold line (line 3050):

/* Find an FAT partition on the drive. Supports only generic partitioning rules, FDISK and SFD. */

bsect = 0;

fmt = check_fs(fs, bsect); /* Load sector 0 and check if it is an FAT-VBR as SFD */

if (fmt == 2 || (fmt < 2 && LD2PT(vol) != 0)) { /* Not an FAT-VBR or forced partition number */

for (i = 0; i < 4; i++) { /* Get partition offset */

pt = fs->win + (MBR_Table + i * SZ_PTE);

br[i] = pt[PTE_System] ? ld_dword(pt + PTE_StLba) : 0;

}

This problem continues in the last 4 version, and still not fixed. Can someone try to create a project from scratch with STM32CubeMX version 4.26 and FW F4 v1.21 which are both the lastest versions by the moment?

Here are few extra notes:

- I set minimum heap and stack size as 0x2000 and 0x4000.

- I'm using Keil uVision MDK v5.15 with compiler v5.05 update 2 (build 169).

- My operating system is Windows 7 Pro SP1 64 bits.

- I'm sure that there is no hardware issue as I was able to run the SD card with a example project.

Regards,

Ogulcan

#f_mount #stm32cube-fw_f4-v1.0 #cubemx-4.26 #fw_f4-v1.0 #sd-card #cubemx #stm32f4 #fatfs #sdcard-fatfs

Note: this post was migrated and contained many threaded conversations, some content may be missing.

[Tesla DeLorean]

Posted on June 19, 2018 at 15:05

>>I've been dealing with the SD card problem since the CubeMX version 4.22.

I admire your persistence.

>>Here, the problem is in f_mount, it doesn't go forward. Debugging further, the code stucks in 'ff.c' file at the following bold line (line 3050):

Some how I doubt it is stopped here. Stop the debugger execution and see where you are actually stuck. It is almost certainly in layers below FatFs, so DISKIO or SDIO/SDMMC. Stepping around in the high level code isn't going to provide you with answers.

Is it stuck in the Hard Fault Handler, have one that prints out fault data, then you'll know it is there.

Instrument the DISKIO and SDIO/SDMMC layers, so you know the entry/exit conditions on the paths it is traversing.

Make sure the interrupt handlers are being called and functioning.

Make sure all the callback functions are in place and being called.

Is it stuck in the SDIO/SDMMC code spinning on status?

is is stuck in the Error Handler?

[Ogulcan Ariyurek]

Posted on June 19, 2018 at 15:34

 ,

 ,

Hello Clive,

It doesn't end up in any of the error handlers. I chased the counter forward and finally saw that the code falls into timeout after the following bold line located in 'sd_diskio.c'

DRESULT disk_read (

 ,

 , ,  ,BYTE pdrv, , ,  , , ,  ,/* Physical drive nmuber to identify the drive */

 ,

 , ,  ,BYTE *buff, , ,  , , ,  ,/* Data buffer to store read data */

 ,

 , ,  ,DWORD sector, , ,  , , , , , , , , /* Sector address in LBA */

 ,

 , ,  ,UINT count , ,  , , ,  ,/* Number of sectors to read */

 ,

)

 ,

{

 ,

 , DRESULT res,

 , res = disk.drv[pdrv]->,disk_read(disk.lun[pdrv], buff, sector, count),

 ,

 , return res,

 ,

}

From there the timeout is as follows in the same file, bold line is looping infinitely(sd_diskio.c):

DRESULT SD_read(BYTE lun, BYTE *buff, DWORD sector, UINT count)

 ,

{

 ,

 , DRESULT res = RES_ERROR,

 ,

 , ReadStatus = 0,

 ,

 , uint32_t timeout,

 ,

♯ if (ENABLE_SD_DMA_CACHE_MAINTENANCE == 1)

 ,

 , uint32_t alignedAddr,

 ,

♯ endif

 , if(BSP_SD_ReadBlocks_DMA((uint32_t*)buff,

 ,

 , , , , , , , , , , , , , , , , , , , , , , , , , , (uint32_t) (sector),

 ,

 , , , , , , , , , , , , , , , , , , , , , , , , , , count) == MSD_OK)

 ,

 , {

 ,

 , , , /* Wait that the reading process is completed or a timeout occurs */

 ,

 , , , timeout = HAL_GetTick(),

 ,

 , , , while((ReadStatus == 0) &,&, ((HAL_GetTick() - timeout) <, SD_TIMEOUT))

 ,

 , , , {

 ,

 , , , }

 ,

 , , , /* incase of a timeout return error */

 ,

 , , , if (ReadStatus == 0)

 ,

 , , , {

 ,

 , , , , , res = RES_ERROR,

 ,

 , , , }

 ,

 , , , else

 ,

 , , , {

 ,

 , , , , , ReadStatus = 0,

 ,

 , , , , , timeout = HAL_GetTick(),

 , , , , , while((HAL_GetTick() - timeout) <, SD_TIMEOUT)

 ,

 , , , , , {

 ,

 , , , , , , , if (BSP_SD_GetCardState() == SD_TRANSFER_OK)

 ,

 , , , , , , , {

 ,

 , , , , , , , , , res = RES_OK,

By the way, I managed to make the same code work in the version 4.21, but I need to make it work in the latest version as my project is upgraded to the latest version and there is no way if downgrading the project.

One more note: I wrote the code piece with the help of

https://www.youtube.com/watch?v=0NbBem8U80Y&,t=5s

.

Regards,

Ogulcan

[Tesla DeLorean]

Posted on June 19, 2018 at 17:13

Well if the ReadStatus value is not changing that tends to indicate that the IRQ, Callback scheme isn't working.

Break-point or emit a character via USART or SWV in the IRQ Handler. Make sure the naming there is correct and linkage to the vector table is working.

Check the assorted HAL and BSP functions are correctly named and get called, and you're not ending up in some __weak functions instead of the ones in the chain that gets to the ones setting ReadStatus/WriteStatus. Make sure those variables are marked as volatile.

Make sure the ticker is running, and you see counting of HAL_GetTick in this loop, and that the timeout is not ridiculously long, ie 30 seconds, not 4 billion micro-seconds.

[Ogulcan Ariyurek]

Posted on June 20, 2018 at 10:20

Hi,

I honestly couldn't figure out the way fixing this, so I first downgraded SMT32CubeMX to 4.21.0 and created a new project selecting SDIO and FATFS. I created the files with STM32Cube F4_FW V1.16.

Then, I upgraded my STM32CubeMX to 4.26.0 and created a project with STM32Cube F4_FW V1.21. I copied all the related SDIO and FATFS files from the 4.21 project to 4.26 project, and it worked.

The problem is I may need to repeat this copy paste process every time I regenegerate project from STM32CubeMX, so can you please solve the problem in the next version?

Regards,

Ogulcan

[Jason Ro]

Posted on June 24, 2018 at 04:16

Hello!

I also have the same problem. f_mount function does not work at all.

I use following configuration

- Board : STM32F407-Discovery

- CubeMX : v4.26

-STM32CubeF4 Firmware Package : V1.0 / 23-February-2018

- Compiler : Atollic TrueStudio v9.0.1

- uSD card : SanDisk Class-4 8 GB SDHC

- O/S : Win10 & win7

Test result

-

1-bit SDIO configuration : Everything is OK.

(f_mount / f_open / f_write / f_read)

==> Both ofnon-DMA and DMA modes are OK.

-

4-bit SDIO configuration : f_mount fails.

So I can't do anything.

==> Both of non-DMA and DMA modes don't work.

I really need to use the latest CubeMX version because I am not a S/W expert.

So far, I spent a lot of time to test 4-bit SDIO mode.But I was not able to findany solution.

I watched many Youtube videos and checked a lot of articles about STM32 SDIO 4-bit.

However, none of them didn't work on my side.

Is there anyone who can solve this issue?

Thank you for the help in advance.

________________

Attachments :

SD_1bit_OK.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HxTl&d=%2Fa%2F0X0000000aya%2FeaQc.SkEVYKcNN14TmQFfRSdbOCUEONjzNodolwfb_o&asPdf=false

[Tesla DeLorean]

Posted on June 24, 2018 at 19:52

 ,

 ,

>,>,Is there anyone who can solve this issue?

I'm sure there are, I'm not much of a mechanic, I have a local garage to work on my vehicles.

As I've advised here several times, you're not going to determine the problem with pass/fail tests at the FatFs level. You need to look at the ErrorCode returned by the SDIO/SDMMC code.

1-bit vs 4-bit has a couple of potential failure modes, one is that the pins are not wired properly, or there is significant skew in the signals, and second is the increase in bandwidth requirements. Also don't park the debug view over the SDIO peripheral as it will break the FIFO.

The following post has a test build for the STM32F4-DISCO attached, it should indicate if the wiring is viable

 ,

[Jason Ro]

Posted on June 26, 2018 at 04:22

Dear Clive,

Hello!

Thank you for the reply.  Finally, I made it !!!

(CubeMX v4.26 + STM32F4 firmware v1.21 + TrueStudio + SDIO 4-bit mode)

Yes. You were right. I should have checked the signal integrity carefully.

I think poor signal quality made the problem.

The most important signal was SDIO_CLK.

I was not able to mount uSD card even though I decreased clock speed to 2MHz.

After I increased the signal quality of SDIO_CLK, all of functions worked fine.

And I will continue to check the signal integrity of SDIO.

Best regards,

Jason

[Altamash Abdul Rahim]

Posted on June 28, 2018 at 11:03

Hello,

 I also encountered issues with FATFS and SD-CARD a while ago. Code failed at fmount() and it was because SD-CARD was not initialised in SD_initialize() function.(Note: This function is genrated by Cube)  I have attached the link to the issue below.

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

 

[URane]

Dear Ashwinraj,

can you share complete project along with cubemx ioc file to understand it completely?

[mhal]

Hi,

My problem was slightly different. 1 bit mode with DMA worked but 4-Bit mode did not. In 4-Bit mode f_mount was hanging.

I'm using the STM32F769NI discovery board and the system clock needed to be higher than the SD card clock. Originally had SDMMC clock set to divider of 0 but it was flacky. Changed system clock to run faster than SDMMC clock and used PLL48MHz as input clock to SD module. After this change no problems with f_mount or reading or writing.