Why HCLK clock speed impact pass/fail of USB Host File operation? (mount, write and read)

[BParh.1]

I am using STM32F769 Discovery board to convert the USB_OTG_HS to Host only mode.

Initially I just used default STM32CubeMX setup that is HCLK 200 MHz when AHB Presclarer is 1. But with this, I can mount f_mount() but not write/read operation (f_open(), f_write() and f_read().

Then by hunch I change the HCLK speed to 100MHz by setting AHB Prescaler to 2. Interestinly mount fail, but read/write operation success.

How to explain this?

So it seems to me, the clock speed impact USB Host operation, any guidelines to follow to setup the clock?

[BParh.1]

STM32CubeMX clock config which fail on write/read but pass mount:

 

Config pass on write read but fail on mount:

 

The snippet code from ST sample for USB Host write read operation:

static void MSC_File_Operations(void)
{
 uint16_t bytesread;
 
 printf("INFO : FatFs Initialized \r\n");
 
 if (f_open(&MyFile, "0:USBHost.txt", FA_CREATE_ALWAYS | FA_WRITE) != FR_OK)
 {
	 printf("Cannot Open 'USBHost.txt' file \r\n");
 }
 else
 {
	 printf("INFO : 'USBHost.txt' opened for write \r\n");
 res = f_write(&MyFile, wtext, sizeof(wtext), (void *)&bytesWritten);
 f_close(&MyFile);
 
 if ((bytesWritten == 0) || (res != FR_OK)) /* EOF or Error */
 {
 	printf("Cannot Write on the 'USBHost.txt' file \r\n");
 }
 else
 {
 if (f_open(&MyFile, "0:USBHost.txt", FA_READ) != FR_OK)
 {
 	 printf("Cannot Open 'USBHost.txt' file for read.\r\n");
 }
 else
 {
 	 printf("INFO : Text written on the 'USBHost.txt' file \r\n");
 
 res = f_read(&MyFile, rtext, sizeof(rtext), (void *)&bytesread);
 
 if ((bytesread == 0) || (res != FR_OK)) /* EOF or Error */
 {
 	printf("Cannot Read from the 'USBHost.txt' file \r\n");
 }
 else
 {
 	printf("Read Text : \r\n");
 	printf((char *)rtext);
 	printf("\r\n");
 }
 f_close(&MyFile);
 }
 /* Compare read data with the expected data */
 if ((bytesread == bytesWritten))
 {
 	 printf("INFO : FatFs data compare SUCCES");
 	 printf("\r\n");
 }
 else
 {
 	 printf("FatFs data compare ERROR");
 	 printf("\r\n");
 }
 }
 }
}

[Piranha]

The HAL/Cube developers are incapable of implementing correctly anything more complex than a blinky. Ethernet/lwIP, USB, SD/FatFS, especially on Cortex-M7, are the most notorious examples of complete incompetence. Your issue with clocks are just one of many ways how a broken code manifests itself.

https://nadler.com/backups/20200111_draft2_STM_Cube_Issues_and_Workflow.html

https://github.com/DRNadler/FreeRTOS_helpers

[BParh.1]

Thank you @Piranha​ for the info, may I know how you resolve yours last time?

Regardless, I still want to understand from MCU perspective, why the HCLK matters to my USB Host operation.

[Piranha]

For example, timing changes when interrupt happens relative to the other code. On Cortex-M7 timing can also change load/store order and cache eviction. And ST's code is typically broken regarding interrupt safety, memory barriers and cache management...

Some of the issues reported here are relevant not only for networking:

https://community.st.com/s/question/0D50X0000BOtfhnSQB/how-to-make-ethernet-and-lwip-working-on-stm32