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

[VShet.2]

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]

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

[VShet.2]

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]

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

[Amel NASRI]

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

[budzik1678]

I have the same problem. I use the STM32H743ii chip and when I use HID (keyboard) and FATfs (SD card) FATfs returns the error "FR_DISK_ERR" after a while. Today I have 2024 and I don't know if you are still dealing with this problem or if it has already been solved. Mine was not solved in the case of 743. I have a very similar system but based on STM32H753ii and the problem does not occur here. The programs are identical. I use "stm32cube_fw_h7_v191" in both cases. I have not seen STM write anything about errors in this chip. Now I do not know what is the problem. The chip (my copy) or the software.

[Pavel A.]

Strange. What are differences in these "similar" boards? Clock source? Are both 753 and 743 stepping V? Any software differences  such as stack size?

 

[budzik1678]

Both systems are in version V. The first system is based on CoreH7XXI and the second on Core4X9I with 753 system. Both systems have different LCD. Core H7XXI has an additional Mp3 system. Stacks are set by CubeMX to 0x400. You think the stack is too low. Hepa is set to 0x200. I will check with more Stack in a moment.