Have STM32H7B3 Discovery Kit.
Used CubeMX to create IAR project.
Integrated USB_Host_Library.
Have USB mouse connected to OTG HS port.
Find that USB initialization eventually triggers a configASSERT(pxUnblockedTCB) in source tasks.c function xTaskRemoveFromEventList.
Observe the following sequence:
- USBH_Process is called for switch case HOST_IDLE
- USBH_Process is called for switch case HOST_DEV_WAIT_FOR_ATTACHMENT
- USBH_Process is called for switch case HOST_DEV_ATTACHED
- USBH_Process is called for switch case HOST_ENUMERATION
- which calls USBH_HandleEnum
- which in switch case ENUM_IDLE calls USBH_Get_DevDesc
- which calls USBH_GetDescriptor
- which calls USBH_CtlReq
- which in switch case CMD_SEND calls osMessageQueuePut
- which calls xQueueSendToBack
- which checks listLIST_IS_EMPTY is pdFALSE
- which calls xTaskRemoveFromEventList
- which calls listGET_OWNER_OF_HEAD_ENTRY which returns NULL
- which triggers configASSERT
It would appear the "if" at step #11 is contradicting the configASSERT at step #14.
Suggestions?
Edit: what is happening is the queue structure is becoming corrupted, not with random garbage, but with USBH related pointers.
Specifically, when HAL_HCD_HC_Init is called, which itself calls USB_HC_Init, field ucQueueNumber in the queue structure mysteriously is overwritten with 0x20004878, which coincidentally is the contents of field pData in structure hUsbHostHS, pointing just beyond the end of hUsbHostHS.
If I single step through HAL_HCD_HC_Init, the corruption does not occur.
But if I let it rip through HAL_HCD_HC_Init, the corruption does occur, which I infer is interrupt related.
Further execution results in more corruption, including xTasksWaitingToReceive field uxNumberOfItems, and it is that corrupted count that causes the configASSERT mentioned above.
But I have not yet been able to identify who is doing the corruption.
Please note, this is 100% STM code, from CubeMX and FreeRTOS.
No code of mine is in the project.
