cancel
Showing results for 
Search instead for 
Did you mean: 

USBX UAC2 playback issues

m_g
Associate

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

2 REPLIES 2
AScha.3
Principal III

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

 

If you feel a post has answered your question, please click "Accept as Solution".
m_g
Associate

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