USB microphone to H743 host streams mic then data freezes

[Robmar]

Connected an USB microphone to an H743 as host and it streams mic audio perfectly at 48 KHz for around 5 seconds then the data freezes.
SOF is still being called as is AudioHost_IsoDataReadyISR() from the STM IRQ driver, DMA is running (its set to use DMA, I tried without but same behaviour), but the same 96 bytes are transfered every uS: I can clear the receive buffer but it gets refilled with the same data.  Attempts to re-init the pipes etc etc fail to restore streaming.
Also, any pause in the servicing of the call to AudioHost_IsoDataReadyISR() results in exactly the same repeat data arriving.

This is my own code based on STM’s examples, as I said it runs perfectly for many seconds, if I unplug the microphone it runs again when plugged back in for the same good few seconds.

Is there an approved way to restore audio streaming without a full reset when there is an occasional timing glitch in servicing the AudioHost_IsoDataReadyISR() call?

[Robmar]

There must be a standard way to reactivate the stream after  pause in serviving Notify, I tried this below but it did nothng.
 

static void AUDIO_HOST_HardRecoverChannel(USBH_HandleTypeDef *phost, uint8_t pipe_num)

{

USB_OTG_GlobalTypeDef *USBx = ((HCD_HandleTypeDef *)phost->pData)->Instance;

USB_OTG_HostChannelTypeDef *hc = (USB_OTG_HostChannelTypeDef *)

(((uint32_t)USBx) + USB_OTG_HOST_CHANNEL_BASE + (pipe_num * USB_OTG_HOST_CHANNEL_SIZE));



// 1. Request halt

hc->HCCHAR |= USB_OTG_HCCHAR_CHDIS;

hc->HCCHAR |= USB_OTG_HCCHAR_CHENA;



// 2. Wait for hardware to confirm the channel actually halted

uint32_t timeout = 1000;

while ((hc->HCCHAR & USB_OTG_HCCHAR_CHENA) && timeout--)

; // hardware clears CHENA itself when truly halted



// 3. Clear any pending interrupt flags for this channel

hc->HCINT = 0xFFFFFFFF;



// 4. Flush the RX FIFO (required per reference manual before re-submitting)

USBx->GRSTCTL |= USB_OTG_GRSTCTL_RXFFLSH;

timeout = 1000;

while ((USBx->GRSTCTL & USB_OTG_GRSTCTL_RXFFLSH) && timeout--)

;

}

 

[Robmar]

STM managers clearly don’t value support, as a result of this, many clients have adopted the ESP32 platform, which has comprehensive USB support

[FBL]

Hi ​@Robmar 

Would you provide minimum firmware to reproduce?

Can you point me directly in which file AudioHost_IsoDataReadyISR is defined STMicroelectronics/stm32-mw-usb-host: Provides the USB Host library part of the STM32Cube MCU Component "middleware" for all STM32xx series

[Robmar]

Hi, thanks for the reply.  There is no host audio code samples for audio as far as I am aware.

My Host audio driver works perfectly for around 6 seconds, receiving 96 byte packets perfectly every 1mS, I have a GPIO toggle on the ISOCreceive Notify that shows 1000uS spacing on calls that then stretches during a few seconds from a 1000:1000:1000 timing to 1200:800:1000 or less, a sort of slow drift with the centre of every 3 sets of pulses drifting back to 1000:1000:1000 and repeating.
I wonder if the USB mic’s and H743 (25MHz xtal) 48 MHz clocks are beating, then a USB_OTG_HCINT_TXERR and USB_OTG_HCINT_BBERR can occur, a missed packet, is the odd/even packet bit out of step?

Anyway after that the host receives the last packet forever via DMA into its sole receive buffer, SOF and ISOCreceiver keep firing, no errors appear, same data.  I have erased the data buffer with memset but it gets refilled with same data as last packet before the errors.

So a lost packet can happen, even heavy noise could cause it.

My questsion is how to recover Host operation without unplugging the microphone, there must be an approved way, with minimal interruption?

I can’t post my USB code without posting my entire project.  As I said the issue is error recovery.
I also have USB audio at 192 KHz working perfectly, with DMA enabled, but with this Mars Gaming microphone, timing drift occurs, which does not happen with a PC.  The Mic works fine on the PC, so I guess the PC driver syncs or recovers better.