STM32Cube USB Host Library CPU time utilization seems too high

[Rostyslav]

My MCU is STM32H753 on custom PCB. It is running at 480 Mhz. 

I use USB USB_OTG_FS it is clocked by RC48.

On “Middleware and Software packs” I have enabled “FATFS”, “FREERTOS” and “USB_HOST”

I generated project by using CubeMX 6.17 with “STM32Cube_FW_H7_V1.13.0”.

For more details see attached pictures with configurations.

 

I use FreeRTOS function uxTaskGetSystemState to get info about CPU time per task.

In my project I have FatFS test module that performs some read write tests. 

When I check CPU usage I get this numbers for tasks: 

1. “fatfs_test” CPU: 43%
2. “USBH_Queue” CPU: 46%
3. left 11% are utilized by GUI.

I ran tests with USB DMA enabled and disabled - there is no difference. 

So, the question is: Is it OK for “USBH_Queue” task to utilize that much CPU when read/write operations in progress???

 

For example I have similar test for SD-card, and I get this numbers for tasks: 

1. “fatfs_test” CPU: 51%
2. “IDLE” CPU: 35%
3. GUI and other tasks CPU: 14%

USB OTG FS pins

USB OTG FS parameters

USB OTG FS NVIC Settings

USB HOST Parameters settings

USB HOST platform settings

 

 

[FBL]

Hi @Rostyslav,

The behavior can be normal. During USB Mass Storage transfers, the STM32 USB Host stack may spend an amount of CPU time in host processing, so USBH_Queue can look heavily loaded while I/O is active.

In my understanding, I suggest also checking: 

• transfer correctness,
• sustained throughput,
• system responsiveness,
• absence of stalls, timeouts, task starvation.

Also, STM32 embedded USB DMA is not the main lever for reducing CPU load here; that feature is generally relevant to USB_OTG_HS rather than FS. When internal USB DMA is available, it does not eliminate all CPU involvement. The USB stack and class layer still require software processing.

[Rostyslav]

Thank you for your reply. I did checked most of that. In general everything is butter smooth. I just did not expected that much level of CPU usage during data transfers with DMA enabled. Though my knowledge of USB HOST controller is pretty much absolute zero. CubeMX software with HAL library and other software packs made programmer life so much easier these days. Whole thing setup was just bunch of clicks. Most of code written by me was actual performance test module.

P.S.: I remember how about 15 years ago I had to implement USB MSC for LPC2478 without any software packs, except provided startup file “LPC2400.s” and “LPC23xx.h” header with some peripheral defines. That was nightmare.

[FBL]

Hi ​@Rostyslav 

Since transfers are stable and the system remains responsive, there is no evidence of a functional issue. I cannot confirm if the observed CPU load is consistent with the software overhead of USB MSC + FatFS on USB_OTG_FS. However if CPU reduction is important, reduce small chucked data, use larger properly aligned buffers, and avoid unnecessary file system calls (maybe repeated open/close, mount/unmount, or frequent flushes..) Logging should also be minimized during performance measurements.

To check the measurements, please provide a minimal reproducible firmware example. This will allow our experts to assess whether the observed CPU usage is in line with expected behavior. Just for your info, such analysis may be handled with lower urgency than a functional defect.

[Rostyslav]

Hi ​@FBL 

I do use relatively large buffers for read/write calls to FatFS (128Kb) placed in SDRAM and they are aligned to 32bytes. Logging is limited to output test performance data once per two seconds. Tasks performance data output happens twice per second (when turned on). Basically test itself is just file opened once, bunch of write calls performed, after that bunch of read calls with consistency checks performed.

I just ran tests again. For my custom FatFS test thread “fatfs_test“ I set priority to osPriorityRealtime and observed interesting picture:

Pic.1 USB test. Thread “fatfs_test“ with priority osPriorityRealtime

What you can see, is that all other threads not getting any CPU ticks (except the one used for debug UART commands processing). The “fatfs_test” thread is taking all of the CPU time it can get. That looks like all that time is waisted somewhere inside “USBH_MSC_Write” and “USBH_MSC_Read” in loop:

  while (USBH_MSC_RdWrProcess(phost, lun) == USBH_BUSY)
  {
    if (((phost->Timer - timeout) > (10000U * length)) || (phost->device.PortEnabled == 0U))
    {
      return USBH_FAIL;
    }
  }

It feels like while data transfer is in progress whole thing is just polling USB host controller non-stop, instead of self lock until transfer complete (or error occurs), like it implemented for SD-card. But again, I have zero clue how USB host controller works in STM32. Maybe as is - is the way to go.

 

See, this is not happening when I run SD-card test:

Pic.2 SD-card test. Thread “fatfs_test“ with priority osPriorityRealtime

Both tests (USB and SD-card) are done by same thread “fatfs_test“, it just get different path pointing to different drives.

 

Due to all the code is done for custom PCB it will be quite time consuming to port it to STM32H753I-EVAL2 that I also have access to, to make it possible someone else to run this code.

 

Also, as long as task performing calls to FatFS has lowest priority everything else works smooth. So, there is a stable working workaround for me. So, no promise I’ll make that port to provide source code for testing, but I hope I narrowed down where to look for a possible issue.