Read/Write into SD card using FatFs in STM32u5A9

[RiverDi_user]

Hello,

I have been trying to read/write into an SD card using the SPI or SDMMC method with Fatfs. I wasn't able to make use of the filex option for file operation which is provided in the STM32u5A9 libraries, since I am using FreeRTOS in my project (as per notes, Filex cannot be used with FreeRTOS). So, I have taken the FatFs library from STM32F4 design and ported the same to STM32U5A9 design (took reference from https://deepbluembedded.com/stm32-sd-card-spi-fatfs-tutorial-examples/). Unfortunately, in both SPI and SDMMC methods, I was not able to initialize my SD card and the application keep on waiting for SPI Rx data in SPI mode, and in SDMMC method, the application keeps on waiting in a HAL_Delay() in HAL_SD_initcard() API

Is there any known issues in this board type? Can you point any working examples for STM32U5A9 with FatFs and FreeRTOS?

Your support is much appreciated!

Thanks & Regards

[RiverDi_user]

Hello @SHs,

This is regarding the same issue that I am facing after sometime of longrun in my SD card rea/write application. Here is the issue explanation:

1. I have more than 3 tasks running to execute different implementation. Major tasks in my application are UART task (having 30ms cycle time - osPriorityHigh), TouchGfx task (to update the received UART data in the display - osPriorityRealtime) and an SD card task (periodically update the device status every 5 seconds - osPriorityRealtime1)

2. With the above tasks priorities the application runs seamlessly for 40+ minutes and after that, the SD card task halts in the same API as before HAL_SD_ReadBlocks()

The application doesnt write data or show the updated UART data in screen, since the SD card task takes over the priority, and never returns. What should I do in this case? Can you please shed some light on this?

Edit:

I reduced the SD_TIMEOUT from SD_DATATIMEOUT(0xFFFFFFFF) to 30000 and tried to run the app. The application ran for about 50 minutes and I got the FR_DISK_ERR in the f_mount() API.

Regards

RiverDI_User

[RiverDi_user]

Update of the issue:

I have tried the reinit of SD when the error occurs like below. 

		if (FSTATUS != FR_OK)
		{
			Unmount_SD("/");
			FSTATUS = Mount_SD("/");

			/* If mount failed, try resetting the SDMMC */
			if (FSTATUS != FR_OK)
			{
				Unmount_SD("/");
				retSD = FATFS_UnLinkDriver(SDPath);
				HAL_SD_MspDeInit(&hsd1);
				HAL_Delay(100);
				MX_SDMMC1_SD_Init();
				retSD = FATFS_LinkDriver(&SD_Driver, SDPath);
				FSTATUS = Mount_SD("/");
			}
		}

But the mount sd call returns FR_NOT_READY error. 

[AScha.3]

Hi,

maybe i (we, at work) have same or similar problem: sometimes a system stops working ->

- no reset, so watchdog not catching it

- no error message

- no hard fault

-> seems just to "wait" for something.

And impossible to get this state by any action we tried. 

SD-cards from those systems exchanged, tried to check the "problem cards" :

- all branded "Intenso" 16 GB 

- one getting hot, 100% defective (ok, can happen, its still an complex electronic part)

- one has data on it, but can no more changed, deleted, formated. Just keeps its state and data.

- all others have data, are working, but show strong variations on access times, up to seconds (!)

If card not working at all or not present, no problem; just error msg : sd..not working.

Problem seem only possible, if working card develops a long (or endless) delay in the middle of the access;

so for now we use only SanDisk cards, as they seem better (no "errors" until now).

btw

What sd-card brand you use ?

[RiverDi_user]

Hi @AScha.3

Yes the SD read/write works for about 40-45 minutes and after that application seems to wait for the flag in the Fatfs layers and I am unable to recover from it. I am using a Sandisk micro SD 8 GB volume. Do you have any suggestions?

		if (FSTATUS != FR_OK)
		{
			Unmount_SD("/");
			FSTATUS = Mount_SD("/");

			/* If mount failed, try resetting the SDMMC */
			if (FSTATUS != FR_OK)
			{
				Unmount_SD("/");
				retSD = FATFS_UnLinkDriver(SDPath);
				HAL_SD_MspDeInit(&hsd1);
				HAL_Delay(100);
				MX_SDMMC1_SD_Init();
				retSD = FATFS_LinkDriver(&SD_Driver, SDPath);
				FSTATUS = Mount_SD("/");

				if (FSTATUS != FR_OK)
				{
					Unmount_SD("/");
					HAL_NVIC_SystemReset();
				}
			}
		}

When I tried to do HAL_NVIC_SystemReset() after FR_DISK_ERR, the next read/write works fine, but its not a ideal solution.

[AScha.3]

Hi,

> Do you have any suggestions?

No "solution" until now...but did you try different port/pin speed settings ?

And sd/mmc clock setting? (I use typ./max. : 100MHz, div1 . -> gives 50MHz , what is standard/maximum clock.)

And 4-bit -> 1-bit mode ? (1-bit is less sensitive to hardware problems.)

So to come closer to the problem: try all and check, whats better or worse or just about same:

- 4 -> 1bit mode

- clock at 50M or slower, div4 or div8 

- pin speed medium or high , with pullups on all lines 

[RiverDi_user]

Hello,

I have tried 1 bit mode, pin speed "High" instead of very high, but the result is still the same. The 1 bit mode seems to be very slow and 8 bit doesnt work. Also, the pulldown doesnt work in GPIO settings.

My SDMMC clock is 40MHz

Clock div is 50

Do you have any more suggestion?

One thing I tried was to soft reset the application when FR_DISK_ERR occurs, but if I try to reinit the SDMMC alone, the reinit doesnt work, and app waits in "if (HAL_SD_GetCardStatus(hsd, &CardStatus) != HAL_OK)"

				retSD = FATFS_UnLinkDriver(SDPath);
				HAL_SD_MspDeInit(&hsd1);
				HAL_Delay(100);
				HAL_SD_MspInit(&hsd1);
				retSD = FATFS_LinkDriver(&SD_Driver, SDPath);

				FSTATUS = Mount_SD("/");

Suggestions are most welcome

[AScha.3]

Hi,

> My SDMMC clock is 40MHz

+ >Clock div is 50

What you do then ? give 40M to the sdmmc module and set there div to 50 ??

This would drive the sd-card with about 800 kHz ! I see no sense here, to do so.

At 40MHz it should run with div 0.     sd-card at -> 20Mbit transfer speed. Try this.

And then try different pin speed settings...and 1 -> 4-bit mode, just to narrow down the possibility of hardware influence .

+

> 8 bit doesnt work

sd-cards have 4-bit data lines, so.... yes, cannot work on 8.

+

>Also, the pulldown doesnt work

with pullups on all lines - i wrote . pullups . pullups .pullups .