cancel
Showing results for 
Search instead for 
Did you mean: 

Question about FATFS Integration on STM32H5 Modules

Mcherif
Associate II

Hello everyone,

I have a question about the STM32H5 modules. I can't find the integrated FATFS in the list of middleware provided by ST. Is it complicated to integrate FATFS by myself, or should I use the middleware provided by ST?

I am using STM32CubeMX for my project, and I've noticed that the FATFS middleware option is available for other STM32 families but not for the STM32H5. If I need to integrate FATFS manually, what steps should I follow? Are there any specific configurations or additional libraries required to ensure compatibility with the STM32H5?

Additionally, any advice on best practices for setting up the file system, optimizing performance, or troubleshooting common issues would be greatly appreciated.

1 ACCEPTED SOLUTION

Accepted Solutions

Well ST's been shipping the 2017 broken version of FATFS for literally years

The integration is done at the DISKIO.C / SDMMC level, it surely has to be materially similar to the historic versions of SDMMC from F7 and H7. The FILE-X version presumably got to interface at the BLOCK level quite similarly.

Yes, it's probably not going to form at the press of a button, but the port shouldn't be overwhelming.

Debugging, instrument DISKIO so you can see usage and failure, add tables and checksumming for validation.

Speed/Performance, do data work at sector or cluster boundaries, do multi-sector transfers, single-up has huge inefficiencies. Try do deal with the f_read/f_write at these sector sized, sector aligned boundaries. There's no caching, and the deblocking is quite expensive. Avoid lots of small f_writes, buffer at the application level. The erase block size on the media is of the order of 128KB, the card hides the details. Format based on the erase block size expectations, the SD Industry Formatter does this, gets the FAT and Clusters falling on these boundaries, not crossing/spanning them. Avoid f_mkfs() unless you absolutely have to, cards come preformatted, properly.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

View solution in original post

2 REPLIES 2

Well ST's been shipping the 2017 broken version of FATFS for literally years

The integration is done at the DISKIO.C / SDMMC level, it surely has to be materially similar to the historic versions of SDMMC from F7 and H7. The FILE-X version presumably got to interface at the BLOCK level quite similarly.

Yes, it's probably not going to form at the press of a button, but the port shouldn't be overwhelming.

Debugging, instrument DISKIO so you can see usage and failure, add tables and checksumming for validation.

Speed/Performance, do data work at sector or cluster boundaries, do multi-sector transfers, single-up has huge inefficiencies. Try do deal with the f_read/f_write at these sector sized, sector aligned boundaries. There's no caching, and the deblocking is quite expensive. Avoid lots of small f_writes, buffer at the application level. The erase block size on the media is of the order of 128KB, the card hides the details. Format based on the erase block size expectations, the SD Industry Formatter does this, gets the FAT and Clusters falling on these boundaries, not crossing/spanning them. Avoid f_mkfs() unless you absolutely have to, cards come preformatted, properly.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..