USB_Host_Library / FreeRTOS Problem

[farrelldw]

Hello All,

We've been struggling with getting hard faults originating in FreeRTOS generated code, but triggered by initialization of a USB optical mouse.  The symptoms and stack trace are nearly identical to a previous unreproduced / unresolved post:
https://community.st.com/t5/stm32cubemx-mcus/problem-with-usb-host-library/td-p/57379

 

Environment:
MCU STM32H7B3NIHx
STM32CubeMX 6.8.1
IAR EW IDE 8.50.9
FreeRTOS 10.3.1
CMSIS 2.00

 

We decided to start from scratch with a new CubeMX project with nothing enabled but UBS_HS_OTG and USB_Host.  (attached)  The application ran great and mouse actions were accurately received.  When FreeRTOS was enabled a hard fault was generated when the mouse was plugged in.  

 

Stack Trace:

HardFault_Handler
<Exception frame>
uxListRemove
xTaskRemoveFromEventList
xQueueGenericSendFromISR
osMessageQueuePut
USBH_LL_PortEnabled
HAL_HCD_PortEnabled_Callback
HCD_Port_IRQHandler
HAL_HCD_IRQHandler
OTG_HS_IRQHandler
<Exception frame>
HAL_GetTick
HAL_Delay
USB_ResetPort
HAL_HCD_ResetPort
USBH_LL_ResetPort
USBH_Process
USBH_Process_OS
prvTaskExitError

 

There is very little custom code involved here, and execution doesn't make it past USB device initialization, so my code never runs.  This is all USB_Host_Library and FreeRTOS generated code.  Please advise as to next steps or things to try.

 

Thanks!

[TDK]

Look for signs of stack corruption. Try increasing stack size.

Examine the hard fault in more detail to determine where and why it's happening.

[farrelldw]

Stack corruption possible.  Dont know the source.  Have already increased "Minimum Stack Size" at CubeMX->Project Manager->Project to 0x4000.  Should be plenty.  Or are you referring to the stack size of the DefaultTask, which we increased to .stack_size = 512 * 4?

The hard fault is happening at the first line of uxListRemove( ListItem_t * const pxItemToRemove ) in list.c
List_t * const pxList = pxItemToRemove->pxContainer;
Registers look like:

 

exception description:
   The processor has escalated a configurable-priority exception to HardFault.
  A precise data access error has occurred (CFSR.PRECISERR, BFAR) at data address 0xc8d0245c.
   Exception occured at PC = 0x800a26a, LR = 0x8007c47

 

Hope this helps.

[TDK]

If this is in a task, which is likely, then the task stack size would be the relevant metric.

At the faulting line, does pxItemToRemove and pxItemToRemove->pxContainer contain valid values? If not, set a hardware watchpoint and rerun the program to figure out where they get modified.

[FBL]

Hello @farrelldw 

According to the fault analysis, it seems you are reading from a bad address 0xc8d0245c (invalid pointer being passed to the function). So, this may not be solved by just increasing stack size but also check state of your pointers: pxContainer in the initialization.

[Pavel A.]

@farrelldw The real mice are much more complex than the ancient "legacy" model used in the ST HID examples. They likely have a different report format or even can be multifunctional devices. This will break the example code. Instrument the code, detect unexpected descriptor or report, avoid buffer overruns.

For a "serious" project consider a production quality USB & HID library.

 

 

[farrelldw]

Update:

increased "Minimum Stack Size" at CubeMX->Project Manager->Project to 0x8000. 

Also increased the stack size of the DefaultTask, to .stack_size = 8000 * 4.

Nearly 32K for each.  Same fault.

Doug