I will use with my STM32H745 Disco Board the eMMC memory together with the Flash File System.

[JPiet.3]

I wanted to use with my STM32H745 Disco Board the eMMC memory together with the Flash File System. In compare to (https://community.st.com/s/article/how-to-create-a-file-system-on-a-sd-card-using-stm32bubeide), the selection for the hardware is grayed. Unfortunately, my knowledge is not so advanced to write my own middleware.

For now, I am able to read out the parameters from the eMMC card and I am able to read out a dedicated block,

I found in the firmware example project "FatFs_Shared_Device" but it seems, this projects is just showing the FAT functionality, but not the middleware. The description mentioned "This application provides a description on how to use STM32Cube™ firmware with FatFs middleware component as a generic FAT file system module. The objective is to develop an application making the most of the features offered by FatFs to access the eMMC card."

But how to connect the middleware functions with the FATFS is a secret for me. If someone could give me a hint, how to connect it, FATFS and the eMMC, it would be great. Any hint is welcome.

My Settings, I use Cube MX V6.6.1 and STM32CubeH7 Firmware Package V1.10.0 / 11-February-2022. I saw, at ST, firmware package is now at version V1.11.0 but Cube MX is not recognizing the latest version for an update.

 

 

Thanks,

Jan

[JPiet.3]

CubeMX recognize now the new firmware package V1.11 (but it solves not my problem :sad_but_relieved_face: )

[JPiet.3]

Hello,

My latest results are written down 

I found in the meantime the following project in the firmwarepackage.

STM32Cube_FW_H7_V1.11.0\Projects\STM32H745I-DISCO\Applications\FatFs\FatFs_Shared_Device

I can compile and download the project, but it is still not running as expected yet. After analyzing the program code, I saw, the eMMC memory interface will never be initialized (maybe I am blind, but I never reached a similiar function during debuggin the code step by step (Function MMC_MspInit in stm32h745i_discovery_mmc.c)).

I added the following lines in my main.c for the CM7 Core, . The pin assign seems as expected within the definition for the ports.

 const uint32_t mmcInstance = 0; // If this is correct, I am not pretty sure. 
 
 res = BSP_MMC_Init(mmcInstance);

It seems, it is running until I want to read out the new created file. I excluded all influences from, the CM4 Core, but the result ist he same. While reading from the file, I get the error FR_DENIED.

(This is the serial output from UART to show the activities within the code (original from the code)

[CM7]: Welcome!

[CM7]: Creating FileSystem...

[CM7]: FileSystem Created successfully!

[CM7]: opening 'cm7.log' for writing...

[CM7]: 'cm7.log' '34' bytes written...

[CM7]: 'cm7.log' Read out failed...

When I step again through the code to look for the read and write functions ( I would expect to hit the functions like BSP_MMC_ReadBlocks(), BSP_MMC_WriteBlocks() , HAL_MMC_ReadBlocks() or HAL_MMC_WriteBlocks.

This is not the case. My read and write process is finished in the diskio.c within the following functions. Maybe something in the background is happen, but I have no clue, where and what. 

But why I got the return value FR_OK for fs_write() and fs_mount()?

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;
 
 }
 
 
 
/**
 
 * @brief Writes Sector(s)
 
 * @param pdrv: Physical drive number (0..)
 
 * @param *buff: Data to be written
 
 * @param sector: Sector address (LBA)
 
 * @param count: Number of sectors to write (1..128)
 
 * @retval DRESULT: Operation result
 
 
 
 */
 
 
 
#if _USE_WRITE == 1
 
 DRESULT disk_write (
 
 BYTE pdrv, /* Physical drive nmuber to identify the drive */
 
 const BYTE *buff, /* Data to be written */
 
 DWORD sector, /* Sector address in LBA */
 
 UINT count /* Number of sectors to write */
 
 )
 
 {
 
 DRESULT res;
 
 res = disk.drv[pdrv]->disk_write(disk.lun[pdrv], buff, sector, count);
 
 return res;
 
}

Could it be possible, the example from ST is not completed yet? 

Thanks for your feedback,

Jan

[JPiet.3]

Update:

I found the reason of my proble. Because the application is not running with the two cores, expanded the f_open function to make the return code visible for me.

This is the origin

/* Open the text file object with read access */
 
 if(f_open(&MyFile, CM7_FILE, FA_READ) != FR_OK)
 {
 goto error; }

Unfortunately, I used the same from the f_open()-function, needed by the write-functions. My assumption, with FR_WRITE I have also Read access, was wrong. But I continued the quest for the failure with this wrong statement.

At the end, the example FatFs_Shared_Device is running, but just with one core (CM7). I was not able to let it run on both. As a nice site effect, I have now a deeper understanding of the file system. Not complete, see below.

I was not able to find out, how the functions e.g in mmc_diskio.c are called and from whom. When I debug linear from the main function, I can't reach the emmedded functions in mmc_diskio.c. I have no idea, how the equivalent functions disk_read() from diskio.c and MMC_read() from mmc_diskio.c are linked. But when I set a breakpoint within the MMC_read(), I can reach this point during runtime. 

If someone has an idea an can it share with me, I will be happy.

Jan