2024-02-13 06:29 PM
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!
2024-02-13 07:38 PM
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.
2024-02-13 08:09 PM
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.
2024-02-14 06:51 AM
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.
2024-02-15 12:31 AM
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.
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2024-02-15 12:45 AM - edited 2024-02-15 12:46 AM
@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.
2024-02-15 01:14 AM
Hi @farrelldw ,
I cannot say much about freertos+usb , but as i see your stack size here ... 🙂
I made an audio USB host , with Azure rtos + usbX ; crash...until i made the memory area big...
see my settings:
your > we increased to .stack_size = 512 * 4
mine 32K pool + 24K usb host stack + 2K app
So try with more memory .
2024-02-15 09:45 AM
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