Skip to main content
Explorer
November 20, 2023
Question

USBX UAC2 playback issues

  • November 20, 2023
  • 2 replies
  • 1412 views

Looking for a bit of advice.

I'm developing a full speed USB audio class device using USBX and ThreadX. So far, I've successfully rebuilt the provided example written for the H743 eval board on an F407 Discovery board. The device enumerates correctly and can successfully playback audio (albeit with some expected pops due to lack of asynchronous feedback).

I'm now faced with an issue where playback doesn't always start. The Audio_ReadChange() function is always called with the correct alternate setting (0/1) but when the _ux_device_class_audio_read_thread_entry() thread is resumed, the loop often breaks and suspends after checking the return status of the _ux_device_stack_transfer_request() function, which returns UX_TRANSFER_BUS_RESET rather than UX_SUCCESS.

Can anyone verify if the same issue persists when running the example on the H743 board? I'm not sure if I've gone wrong somewhere when porting to the F407, or if the issue might lie within the DCD itself.

Here's my current project if it's any help.

Many thanks

    This topic has been closed for replies.

    2 replies

    Super User
    November 20, 2023

    i can give no advice - just some "impressions" ; 

    i made    tried to make an audio-host , with Azure/usbx ; on H653-disco board; 

    its working now, but i set uac1 now, because with uac2 setting it seem to expect hi-speed-usb. (not sure - i still have to prove ; simple soundcard enumerated + working, uac2 enumerated - but not working.)

    + my first problems coming from setting not enough memory to usbx . try to give it more...

    https://learn.microsoft.com/en-us/azure/rtos/usbx/overview-usbx

     

    m_gAuthor
    Explorer
    November 22, 2023

    After a bit more digging I've realised that the bus reset error isn't the source of the issue. In fact, later versions of USBX have a separate conditional to catch bus resets and process them without throwing errors. The issue seems to be that the PCD_EP_OutXfrComplete_int interrupt is sometimes failing to trigger, causing a lockup on the read thread.

    To be more specific, in the HAL_PCD_IRQHandler, the USB_OTG_DOEPINT_XFRC interrupt flag isn't being raised on the occasions that playback fails