Describe the bug
In composite mode, the AUDIO class uses pdev->classId inside USBD_AUDIO_Sync(). This is unsafe when USBD_AUDIO_Sync() is called from an async context (e.g. I2S DMA callback), because pdev->classId may currently point to another class (HID), leading to wrong pClassDataCmsit[]/pUserData[] indexing and a HardFault.
How To Reproduce
-
Indicate the global behavior of your application project.
- USB composite device: HID interface (like keyboard or mouse) and Audio.
- Audio data is played via I2S with DMA.
- DMA Half/Full transfer callbacks call
USBD_AUDIO_Sync() to adjust/read audio buffer state and trigger AudioCmd().
-
The modules that you suspect to be the cause of the problem (Driver, BSP, MW ...).
Class/AUDIO (specifically USBD_AUDIO_Sync()).- Also, general composite behavior because
classId is used as a global context selector.
-
The use case that generates the problem.
- Start audio playback from Host to the device (USB Audio OUT streaming).
- While audio is playing, generate HID traffic (move mouse / press keyboard keys).
- Eventually (typically within a few seconds), the target hits
HardFault_Handler.
-
How we can reproduce the problem.
Composite Audio + HID application example:
https://github.com/STMicroelectronics/STM32CubeH7/tree/dev/usb/composite/Projects/STM32H743I-EVAL/Applications/USB_Device/Composite_Audio_HID
Additional context
-
Root cause: USBD_AUDIO_Sync() assumes it is always called with pdev->classId already set to the AUDIO instance. That assumption is not true when USBD_AUDIO_Sync() is invoked from non-USB asynchronous contexts (DMA callbacks).
-
Proposed fix idea: make USBD_AUDIO_Sync() (and any similar helper callable outside USB context) not depend on pdev->classId, similar to USBD_HID_SendReport.
If the intended usage is “USBD_AUDIO_Sync() must only be called from the AUDIO class callbacks (where classId is set by the core)”, it would help a lot to document that requirement clearly, because it’s very easy to call it from the audio DMA layer, and the failure mode is a hard crash.
Describe the bug
In composite mode, the AUDIO class uses
pdev->classIdinsideUSBD_AUDIO_Sync(). This is unsafe whenUSBD_AUDIO_Sync()is called from an async context (e.g. I2S DMA callback), becausepdev->classIdmay currently point to another class (HID), leading to wrongpClassDataCmsit[]/pUserData[]indexing and a HardFault.How To Reproduce
Indicate the global behavior of your application project.
USBD_AUDIO_Sync()to adjust/read audio buffer state and triggerAudioCmd().The modules that you suspect to be the cause of the problem (Driver, BSP, MW ...).
Class/AUDIO(specificallyUSBD_AUDIO_Sync()).classIdis used as a global context selector.The use case that generates the problem.
HardFault_Handler.How we can reproduce the problem.
Composite Audio + HID application example:
https://github.com/STMicroelectronics/STM32CubeH7/tree/dev/usb/composite/Projects/STM32H743I-EVAL/Applications/USB_Device/Composite_Audio_HID
Additional context
Root cause:
USBD_AUDIO_Sync()assumes it is always called withpdev->classIdalready set to the AUDIO instance. That assumption is not true whenUSBD_AUDIO_Sync()is invoked from non-USB asynchronous contexts (DMA callbacks).Proposed fix idea: make
USBD_AUDIO_Sync()(and any similar helper callable outside USB context) not depend onpdev->classId, similar toUSBD_HID_SendReport.If the intended usage is “
USBD_AUDIO_Sync()must only be called from the AUDIO class callbacks (where classId is set by the core)”, it would help a lot to document that requirement clearly, because it’s very easy to call it from the audio DMA layer, and the failure mode is a hard crash.