STM32H7 latest firmware v1.9 has a bug which causes FATFS API to return FR_DISK_ERR.

VShet.2 · ‎2021-08-13

My current project is based on STM32H743IIT6 microcontroller with CMSIS RTOS v2, FATFS, USB FS as Mass Storage Host class. Recently, I upgraded to H7 firmware v1.9 after which FATFS API return "FR_DISK_ERR" error frequently.

As a workaround, I had to replace these files "stm32h7xx_ll_usb.c", "stm32h7xx_ll_usb.h", "stm32h7xx_hal_hcd.c" and "stm32h7xx_hal_hcd.h" in latest drivers in v1.9 to the once present in earlier version that is H7 firmware v1.8.

There are changes in USB link layer drivers & HCD drivers in latest firmware and that seems to be the root cause of these issue. I narrowed down at a place in USB link layer "stm32h7xx_ll_usb.c" to function like "USB_ReadPacket()", "USB_WritePacket()" where in earlier v1.8 read and write from USBx_DFIFO were 32bit word aligned which is NOT the case with latest firmware v1.9. I am not sure if word alignment is the issue here but it has something to do with this USB and HCD drivers cause replacing them with the older version in latest firmware seems to work for me.

Amel NASRI · ‎2021-08-23

Hi @VShet.2 ,

I reported your case to our development team for more investigation. Internal ticket number: 112204 (PS: This is an internal tracking number and is not accessible or usable by customers).

Thanks for all relevant details you provided and the analysis you added. This is helpful to identify the root cause.

-Amel

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

VShet.2 · ‎2021-08-27

Hi @Amel NASRI ,

I did some more work on this issue and I have narrowed it down to clock issue. Everything with latest firmware work correctly if I change my clock source for USB peripheral to internal RC48 instead of 48 MHz generated from PLL3Q which I was using earlier. This is precisely the ONLY change I require in my project for USB and FATFS to work correctly with the new firmware for H7: v1.9.

PLL3 in my project using divider PLL3R is used for LTDC peripheral. There is only one clock source possible for LTDC so, cannot modify that. If I disable LTDC so that NO other peripheral uses PLL3 then USB & FATFS works correctly with latest firmware.

I have attached both working and not working IOC files of my project in this thread for reference.

Conclusion: USB and FATFS works correctly in latest firmware with PLL3 as clock source only if this PLL3 is NOT used by any other peripheral. If any other peripheral uses PLL3 then you need to use RC48 as source for USB. This issue was NOT there in older H7 firmware.

@Amel NASRI Can you please share this information and attached files to relevant internal ticket ( Internal ticket number: 112204 ). This might help in focusing on exact issue.

Amel NASRI · ‎2021-08-27

Hi @VShet.2 ,

The results of your investigation are quite interesting. As you asked for it, I shared your findings with development team.

Thanks again.

-Amel

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Amel NASRI · ‎2021-08-30

Hi @VShet.2 ,

Just to make sure, do you confirm that there is no problem with exactly the same application in following cases:

H7 firmware v1.9, with files "stm32h7xx_ll_usb.c", "stm32h7xx_ll_usb.h", "stm32h7xx_hal_hcd.c" and "stm32h7xx_hal_hcd.h" from H7 v1.8
keep all H7 firmware v1.9 drivers as they are but make sure that USB clock source is RC48
keep all H7 firmware v1.9 drivers as they and use PLL3 as USB clock source (only if PLL3 is not used as clock source for other peripherals).

Is that summary correct?

-Amel

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

VShet.2 · ‎2021-08-30

Hi @Amel NASRI ,

Yes, that's correct.

Update the clock source for USB to RC48 instead of PLL3 to make things work with H7 firmware v1.9 without modifying any USB, HCD driver files.
I cannot definitely say for any peripheral on PLL3 but my application uses LTDC on that PLL3. If I turn off LTDC which means I have to remove TouchGFX as well then, USB works correctly with PLL3 as well.

OR

Replace H7 firmware v1.9, with files "stm32h7xx_ll_usb.c", "stm32h7xx_ll_usb.h", "stm32h7xx_hal_hcd.c" and "stm32h7xx_hal_hcd.h" from H7 v1.8 to for USB to work using PLL3 along with LTDC, TouchGFX.

Note: My application uses FreeRTOS i.e CMSIS OS v2

Amel NASRI · ‎2021-09-01

Hi @VShet.2 ,

To go ahead with problem analysis, I have 2 proposals:

can you test the example STM32Cube_FW_H7_V1.9.0\Projects\STM32H743I-EVAL\Applications\USB_Host\MSC_RTOS on your side?
in case you are adding some BSP components to your project, please make sure to redefine MX_LTDC_ClockConfig as it is declared weak in STM32Cube_FW_H7_V1.9.0\Drivers\BSP\STM32H743I-EVAL\stm32h743i_eval_lcd.h and it is overwrtting the configuration set by STM32CubeMX for PLL3.

Thanks.

-Amel

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

VShet.2 · ‎2021-09-02

Hi @Amel NASRI ,

I don't have STM32H743 evaluation kit with me So, I cannot check example code. But the example code also uses RC48 clock source for USB.
I have not used any BSP component from any evaluation kit for my project.

Let me know if I misunderstood anything from your two proposals ? If you want I can create a new project with just USB and LTDC, TouchGFX and share that code with you but again you can't run it at your side because its my custom board.

Amel NASRI · ‎2021-09-02

Hi @VShet.2 ,

1- In the mentioned example, we have this configuration for USB clock in SystemClock_Config():

 /* PLL3 for USB Clock */
  PeriphClkInitStruct.PLL3.PLL3M = 25;
  PeriphClkInitStruct.PLL3.PLL3N = 336;
  PeriphClkInitStruct.PLL3.PLL3FRACN = 0;
  PeriphClkInitStruct.PLL3.PLL3P = 2;
  PeriphClkInitStruct.PLL3.PLL3Q = 7;
  PeriphClkInitStruct.PLL3.PLL3VCOSEL = RCC_PLL3VCOMEDIUM;
  PeriphClkInitStruct.PLL3.PLL3RGE = RCC_PLL3VCIRANGE_0;
 
  PeriphClkInitStruct.PeriphClockSelection = RCC_PERIPHCLK_USB;
  PeriphClkInitStruct.UsbClockSelection = RCC_USBCLKSOURCE_PLL3;
  HAL_RCCEx_PeriphCLKConfig(&PeriphClkInitStruct);

My understanding is that PLL3 is being used for the suggested project, not RC48 as USB clock source.

2- OK thanks for confirming.

Yes indeed, sharing a project with the complete configuration and minimum code to reproduce the issue will be helpful.

Thanks again.

-Amel

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

VShet.2 · ‎2021-09-04

Hi @Amel NASRI ,

Yes, you are correct in the example code it uses PLL3 for USB. I had created example project using CubeMX there it was using RC48 as clock source for USB.
I have attached a minimal project where I am getting ERROR in USB. This project uses PLL3 as clock source for USB. To make this project work I simply have to change clock source to RC48 for USB. Please Note: This project is for my custom PCB so, you cannot run this on any evaluation board. Below is the overview of this project:

I have enabled minimal peripheral in this test project required to recreate this error. This includes FreeRTOS CMSIS OS v2, USB, FATFS, LCD (LTDC, FMC(Display framebuffer), QUADSPI(TouchGFX images), DMA2D, TouchGFX).
When USB pen drive is connected it looks for a folder names "Dijitex" and then searches for all files ending with "*.bmp" inside that folder. There is a loop which does this search and in each iteration It reads first few bytes from this files and gets some information and updates my structure. It is this FATFS find function "fr = f_findnext(&dj, &fno);" which returns error "FR_DISK_ERR". Usually my pen drive has around 1000 valid files in this folder. There is no fix number but after few iterations in this search loop f_findnext() API returns error. you can find this function in "test\Core\Src\file_operation.c".

/**
 * This function searches for files inside search_dir which matches file extension specified by ext. It calls function to check
 * validity and update RAM. RAM is NOT updated with file info if that file fails to open/read.
 * @param search_dir Search Directory is path of H<HookNo> if exists otherwise root of PenFolder
 * @param ext String specifing file extension: ".bmp", ".bmc"
 */
void USB_search_read_header(char *search_dir, char *ext)
{
	FRESULT fr;     							/* Return value */
	DIR dj;         							/* Directory object */
	FILINFO fno;    							/* File information */
	uint8_t len = 0;
	char search_file[270] = {0};
	Update_typedef update;
	FRESULT (*File_Type)(char *Path, char *Name);
 
 
	File_Type = &USB_save_BMP_header;
 
 
 
	strcpy(search_file, search_dir);
	strcat(search_file, "/");
	len = strlen(search_file);
 
	fr = f_findfirst(&dj, &fno, search_dir, ext);  /* Start to search for files */
 
    while (fr == FR_OK && fno.fname[0])          /* Repeat while an item is found */
    {
    	memcpy((search_file+len), fno.fname, (strlen(fno.fname)+1));
    	memcpy(DsgName_CurrAddr, fno.fname, (strlen(fno.fname)+1));
 
		if((*File_Type)(search_file, fno.fname) == FR_OK) // Call through Function pointer
		{
			DsgName_CurrAddr += (strlen(fno.fname)+1);
		}
 
    	if(USB_FileCnt_all < USB_Max_Dsg)				// USB MAX files supported 4000
    	{
    		fr = f_findnext(&dj, &fno);               /* Search for next item */
    	}
    	else
    	{
    		break;
    	}
    }
 
    if(fr == FR_OK)
    {
    	update.type = USB_File_ready;
    }
    else
    {
    	update.type = USB_Disk_Error;
    }
//    osMessageQueuePut(Model_QueueHandle, (void *)&update, 0, 0);
    f_closedir(&dj);
}

You need to add some UI in TouchGFX so that screen gets updated periodically for this error to occur. So, I have added an Animation UI from TouchGFX example.

Let me know if any clarification is required in my test code.

Thanks,

Vatsal