STM32 USB to I2S multi channel - log - ask for help

@JMF11 : Your altsetting 1 has 6 channels of 16bits with max packet size 588 bytes + bInterval=1, and alsetting 2 has 6ch/24bits with max packet size only 128 bytes + bInterval=1. That does not look logical, IMO

If the linux UAC driver does not complain, maybe you could check the USB packets with wireshark.
 
Hi and thanks for your advices. I will try what you say: disable the device in Pulseaudio, install windows SDK and try to check drivers logs.

I had seen the bug in the altsetting2. There is an issue in the macro I will address. However it is not called. Only altsetting1 is activated.

I understand from your (lack) of comments that the calculation of the size of the USB packets looks correct.

@phofman: UAC driver complaining is always refected by dmesg or I need to also look elsewhere?

If you have any ideas of possible root causes, I'm interested :)

JMF
 
At the moment, I have USBD_LL_PrepareReceive():
  • at the usbd_audio init
  • in case of IsoOutIncomplete() (not the perfect behaviour, but used in several codes, including ST code. Nota: I don't have many.

As I have changes from alt_interf_0 to alt_interf_1, I wonder if something is needed when switching to alt_interf_1.

Stereo version is working well without... but could it be needed when more channels are needed?

Correction log:
the alt_2 setting maxpacket size was wrong because it is to big for USB_FS. The 1024 max length is exceeded.
I had an error for the sampling rate range request, which with only 1 value (MIN=MAX) needed a RES =0
aplay works (I can use the command) when the device is switched off in pulseaudio

... but still no DataOut call...

Which should be an issue with USBD_LL_PrepareReceive() not being active at the time I want to stream music.
 
I tried this morning to close and reopen Streaming EP when switching the alt _interface. See code in spoiler.

Not much better. But I get some IsoOutImcomplete at start of playing. Not systematic but frequent.

Same behaviour on Windows and Linux. On linux dmesg does not raise errors/warnings.

I will try to revert to Stereo, then to 3.1 (instead of 5.1).

Current version of the code is there: Code

if (haudio->alt_setting == 0)
{
//## BSP_LED_Off(LED3);
USBD_LL_FlushEP(pdev, STREAMING_EP_ADDR);
USBD_LL_CloseEP(pdev, STREAMING_EP_ADDR);
pdev->ep_out[STREAMING_EP_NUM].is_used = 0U;
} else {
//## BSP_LED_On(LED3);
//##jmf test
AudioBuffer_Reset(&haudio->aud_buf, haudio->buf_cap);
USBD_LL_OpenEP(pdev, STREAMING_EP_ADDR, USBD_EP_TYPE_ISOC, USB_FS_AUDIO_PACKET_SIZE);
USBD_LL_FlushEP(pdev, STREAMING_EP_ADDR);
pdev->ep_out[STREAMING_EP_NUM].is_used = 1U;
USBD_LL_PrepareReceive(pdev, STREAMING_EP_ADDR, (uint8_t*)haudio->pkt_buf, USB_FS_AUDIO_PACKET_SIZE);
BSP_LED_Toggle(LED5);
}
 
Ok, so I get the DataOut calls in 3.1 (with some IsoOutIncomplete calls).

So I may have some limit I hit somewhere on my stm32F4 Discovery 8MHz clocked board.

As with 6 channels, I don't even get DataOut called, it is not the "manual" copy of samples from USB packet buffer to Audio buffer.

USB_FS is expected to allow up to 8 * 16 bit cahnnels. So with 6 I should have headroom.
 
I stuggle to see what would make the 3.1 configuration have the DataOut triggered and the 5.1 not. Most of the workload is related to recieving the music stream. If it doesn't start, there is no such load.

Using the logic analyser, I checked some behaviour in 3.1 mode:
  • Alt Interface 0 or Alt Interface 1 => switch to 1 when playing, then revert to 0 => good
  • 1 DataOut call ebvery 1ms ; good for USB_FS. Time in dataOut short (On on entry, Off on exit)
  • No IsoOutIncomplete => Good (toggles when happen)
  • Many IsoInIncomplete ???? (toggles when happens) => alternance 1ms, 0.5ms, 0.5ms, 1ms...

Is that normal?

I would like to better understand the load on my stm32F4, however most of the code is run from interrupts:
  • from USB (part of it in USB stack lower layers I would be happy not to touch,
  • from DMA/I2S.
Seems not easy to check.
 
For USB_FS spec, the max size for Isochronous end points is 1023 (https://www-user.tu-chemnitz.de/~heha/hsn/chm/usb.chm/usb4.htm). However I see that some implementations have lower size at 512 (https://community.nxp.com/t5/Kinetis-Microcontrollers/USB-max-Isochronous-packet-size/m-p/317290 , https://www.infineon.com/dgdl/Infin...N.pdf?fileId=8ac78c8c7d0d8da4017d0e814c2f12fc)

I did some additional tests with 3.1 descriptor, and it works with values up to 420 bytes (I get DataOut) but not working (no DataOut) with 440 bytes. However it could be because of the discrepancy between the need (392 bytes) and the max packet size value.

Bottom line If in stm32 USB stack implementation thare was a limit for Isochronous end points at 512 bytes, then the multichannel config would be limited to 3.1: 48k * 4 channels * 2 bytes.

5.1 needs 588 bytes and would be above that limit and not working.

Would you have information about the stm32 implementation limit for Isochronous EP packets?

Looking at time spent in DataOut, I doubt that it is a CPU load issue
 

Attachments

  • Capture play overview.JPG
    Capture play overview.JPG
    93.1 KB · Views: 14
  • Capture play zoom.JPG
    Capture play zoom.JPG
    120.3 KB · Views: 16
Thanks @bohrok2610 for the information. So my idea of a limit in the ST USB stack for Isochronous end points at 512 bytes should be wrong. Good: there is still hope. Bad: I don't know where to look.

A work plan could be:
1)revert to 5.1 Channels config and try to capture events with logic analyze as I did for the 3.1 config
2)install the tools to extract the Windows UAC2 logs
3)align the IsoInIncomplete and IsoOutIncomplete to bohrok (and ST) instructions
4)fix the Async feedback in case it would be detrimental to the whole operation of the host/device pair

Is it normal to have those IsoInIncomplete() call (I imagine related to the feedback mechanism)? Is it related to the last anwer from Tsuneo here: https://community.st.com/t5/stm32-m...edback-problem-and-even-odd-frame/td-p/542335 ?

I don't find the answer for a studid question. How is working the DataIn process between the Host and the device (and associated ST USB stack if dependant):
  • is the Host (as Master) that asks DataIn to the Device (Slave). A DataIn interrupt is raised and DataIn() code executed ?
  • of the Device can send the Data to the Host when it wants, and so the DataIn() code has to be called by the application (without interrupt triggered by the Host/Master)?

A lot of things to learn... Some help would be appreciated :)

JMF
 
Last edited:
So, this afternoon, I installed the Windows SDK and followed the instructions to access the UAC2 logs. Not so difficult in the end. I collected 3 logs:
-(jmf3) Board init, when connecting to Windows,
-(jmf4) After init and before playing Music (but in fact the Windows driver immediatly goes to Alt_Interface 1,
-(jmf 5) During music playback.

For (jmf4) and (jmf5), those are successions of:
[0]2580.25E4::03/17/2024-19:06:15.716 [USBAudio2](OUT): packetNumber=922 flags=0x00000000 eosPacketLength=5760
[0]0000.0000::03/17/2024-19:06:15.725 [USBAudio2](0x01): COMPL OUT buf 0 CurrenLinearPosition=442560 EVENT
[0]2580.25E4::03/17/2024-19:06:15.726 [USBAudio2](OUT): packetNumber=923 flags=0x00000000 eosPacketLength=5760
[0]0000.0000::03/17/2024-19:06:15.735 [USBAudio2](0x01): COMPL OUT buf 1 CurrenLinearPosition=443040 EVENT
[0]2580.25E4::03/17/2024-19:06:15.736 [USBAudio2](OUT): packetNumber=924 flags=0x00000000 eosPacketLength=5760
[0]47BC.0780::03/17/2024-19:06:15.745 [USBAudio2](0x01): COMPL OUT buf 2 CurrenLinearPosition=443520 EVENT
[1]2580.25E4::03/17/2024-19:06:15.746 [USBAudio2](OUT): packetNumber=925 flags=0x00000000 eosPacketLength=5760
[0]0000.0000::03/17/2024-19:06:15.755 [USBAudio2](0x01): COMPL OUT buf 0 CurrenLinearPosition=444000 EVENT

Does it means that Windows is streaming (but I don't hava dataOut)?

(jmf3) looks "globally" successful, but there are odd things / posible issues. I may not have catched all. Not sure what it means and what should be corrected (note that my board is USB_FS and not HS):
[1]0004.20D4::03/17/2024-19:06:06.188 [USBAudio2]Created OutputTerminal ID=0x03
[1]0004.20D4::03/17/2024-19:06:06.188 [USBAudio2]No AC Interrupt endpoint present
[1]0004.20D4::03/17/2024-19:06:06.188 [USBAudio2](0x0101): FEEDBACK ENDPOINT UNUSABLE because of bInterval=4 PacketFreq=125
[1]0004.20D4::03/17/2024-19:06:06.188 [USBAudio2](0x0102): FEEDBACK ENDPOINT UNUSABLE because of bInterval=4 PacketFreq=125

[1]0004.20D4::03/17/2024-19:06:06.188 [USBAudio2]SUCCESS

[1]0004.20D4::03/17/2024-19:06:06.189 [USBAudio2] * Alt Setting Group *
[1]0004.20D4::03/17/2024-19:06:06.189 [USBAudio2] AS OUT IfNb=0x01 AltSetting=0x01 '<NULL>'
[1]0004.20D4::03/17/2024-19:06:06.189 [USBAudio2] Format Type I PCM (0x00000001) SubSlotSize=2 BitsPerSample=16 ChannelCount=6
[1]0004.20D4::03/17/2024-19:06:06.189 [USBAudio2] Data Endpoint 0x01 Isochronous Asynchronous Data ActualMaxPacketSize=588 ActualPacketFrequency=1000/s (HS Endpoint)
[1]0004.20D4::03/17/2024-19:06:06.189 [USBAudio2] Feedback Endpoint 0x81 Isochronous None Feedback ActualMaxPacketSize=4 ActualPacketFrequency=125/s (HS Endpoint)
[1]0004.20D4::03/17/2024-19:06:06.189 [USBAudio2] Supported sampling frequencies:
[1]0004.20D4::03/17/2024-19:06:06.189 [USBAudio2] min=48000 max=48000 res=0
[1]0004.20D4::03/17/2024-19:06:06.189 [USBAudio2] * Alt Setting Group *
[1]0004.20D4::03/17/2024-19:06:06.189 [USBAudio2] AS OUT IfNb=0x01 AltSetting=0x02 '<NULL>'
[1]0004.20D4::03/17/2024-19:06:06.189 [USBAudio2] Format Type I PCM (0x00000001) SubSlotSize=4 BitsPerSample=24 ChannelCount=6
[1]0004.20D4::03/17/2024-19:06:06.189 [USBAudio2] Data Endpoint 0x01 Isochronous Asynchronous Data ActualMaxPacketSize=64 ActualPacketFrequency=1000/s (HS Endpoint)
[1]0004.20D4::03/17/2024-19:06:06.189 [USBAudio2] Feedback Endpoint 0x81 Isochronous None Feedback ActualMaxPacketSize=4 ActualPacketFrequency=125/s (HS Endpoint)
[1]0004.20D4::03/17/2024-19:06:06.189 [USBAudio2] Supported sampling frequencies:
[1]0004.20D4::03/17/2024-19:06:06.189 [USBAudio2]SUCCESS

[0]0004.20D4::03/17/2024-19:06:06.189 [USBAudio2]CTOR this=0xFFFFB5855D73B140
[0]0004.20D4::03/17/2024-19:06:06.189 [USBAudio2]returning <NULL> {b4c90a31-5791-11d0-86f9-00a0c911b544} 0xFFFFB5855D73B178
[0]0004.20D4::03/17/2024-19:06:06.189 [USBAudio2][
[0]0004.20D4::03/17/2024-19:06:06.189 [USBAudio2]]
[0]0004.20D4::03/17/2024-19:06:06.189 [USBAudio2]returning 0xFFFFB5855D738680
[0]0004.20D4::03/17/2024-19:06:06.189 [USBAudio2]<NULL> iid={5dadb7dc-a2cb-4540-a4a8-425ee4ae9051} is not supported
[0]0004.20D4::03/17/2024-19:06:06.189 [USBAudio2]<NULL> iid={29cc9ab1-e89d-413c-b6b2-f6d50005d063} is not supported
[0]0004.20D4::03/17/2024-19:06:06.189 [USBAudio2]CTOR this=0xFFFFB58560740EB0
[0]0004.20D4::03/17/2024-19:06:06.189 [USBAudio2]returning <NULL> {0f9fc4d6-6061-4f3c-b1fc-075e35f7960a} 0xFFFFB58560740EE8
[0]0004.20D4::03/17/2024-19:06:06.189 [USBAudio2][
[0]0004.20D4::03/17/2024-19:06:06.189 [USBAudio2]]
[0]0004.20D4::03/17/2024-19:06:06.189 [USBAudio2]MiniportWave: FFFFB58560740EB0
[0]0004.20D4::03/17/2024-19:06:06.189 [USBAudio2]returning 0xFFFFB5855D73AA20
[0]0004.20D4::03/17/2024-19:06:06.189 [USBAudio2]returning <NULL> {b532678c-be50-472d-9973-8a6f16594989} 0xFFFFB58560740EF8
[0]0004.20D4::03/17/2024-19:06:06.189 [USBAudio2]<NULL> iid={2ebf536c-ef57-4c64-bedc-25c1a6d668e6} is not supported
[0]0004.20D4::03/17/2024-19:06:06.189 [USBAudio2]<NULL> iid={5dadb7dc-a2cb-4540-a4a8-425ee4ae9051} is not supported

[0]0004.260C::03/17/2024-19:06:06.190 [USBAudio2]Adapter: FFFFB5855D738260
[0]0004.260C::03/17/2024-19:06:06.190 [USBAudio2]] STATUS_SUCCESS
[0]0004.260C::03/17/2024-19:06:06.190 [USBAudio2][ 0x14 <NULL>
[0]0004.260C::03/17/2024-19:06:06.190 [USBAudio2]] STATUS_SUCCESS
[0]0004.260C::03/17/2024-19:06:06.190 [USBAudio2][ 0x07 <NULL>
[0]0004.260C::03/17/2024-19:06:06.190 [USBAudio2]] 0xc00000bb(STATUS_NOT_SUPPORTED)
[0]0004.260C::03/17/2024-19:06:06.190 [USBAudio2][ 0x07 <NULL>
[0]0004.260C::03/17/2024-19:06:06.190 [USBAudio2]] 0xc00000bb(STATUS_NOT_SUPPORTED)

[0]07F4.0840::03/17/2024-19:06:06.312 [USBAudio2]PIN 1 HostPin InPin
[0]07F4.0840::03/17/2024-19:06:06.312 [USBAudio2]KSPROPERTY_PIN_PROPOSEDATAFORMAT SET
[0]07F4.0840::03/17/2024-19:06:06.312 [USBAudio2]SET: ValueSize=64 < sizeof(KSDATAFORMAT_WAVEFORMATEX)
[0]07F4.0840::03/17/2024-19:06:06.312 [USBAudio2]] 0xc0000023(STATUS_BUFFER_TOO_SMALL)

1]2580.48EC::03/17/2024-19:06:06.493 [USBAudio2]PIN 1 HostPin InPin
[1]2580.48EC::03/17/2024-19:06:06.493 [USBAudio2]KSPROPERTY_PIN_PROPOSEDATAFORMAT SET
[1]2580.48EC::03/17/2024-19:06:06.493 [USBAudio2]CHECKING: WAVEFORMATEXTENSIBLE PCM ch=6 cm=0x0000003f sz=16/16 sr=48000 STATUS_SUCCESS
[1]2580.48EC::03/17/2024-19:06:06.493 [USBAudio2]] STATUS_SUCCESS
[0]2580.48EC::03/17/2024-19:06:06.496 [USBAudio2][ PIN 1 HostPin InPin
[0]2580.48EC::03/17/2024-19:06:06.496 [USBAudio2]SignalProcessingMode={9e90ea20-b493-4fd1-a1a8-7e1361a956cf} (<NULL>)
[0]2580.48EC::03/17/2024-19:06:06.496 [USBAudio2]CHECKING: WAVEFORMATEXTENSIBLE PCM ch=6 cm=0x0000003f sz=16/16 sr=48000 STATUS_SUCCESS
[0]2580.48EC::03/17/2024-19:06:06.496 [USBAudio2](OUT): CTOR this=0xFFFFB5855EA67B60
[0]2580.48EC::03/17/2024-19:06:06.496 [USBAudio2](OUT): [
[1]2580.48EC::03/17/2024-19:06:06.497 [USBAudio2](0x01): Interface 0x01 set to AltSetting 0x01
[1]2580.48EC::03/17/2024-19:06:06.497 [USBAudio2](0x01): Interface 0x01 set to AltSetting zero
[1]2580.48EC::03/17/2024-19:06:06.497 [USBAudio2](OUT): ] STATUS_SUCCESS
[1]2580.48EC::03/17/2024-19:06:06.497 [USBAudio2]] STATUS_SUCCESS
[1]2580.48EC::03/17/2024-19:06:06.497 [USBAudio2]returning <NULL> {23759128-96f1-423b-ab4d-81635bcf8ca1} 0xFFFFB5855EA67B78
[1]2580.48EC::03/17/2024-19:06:06.497 [USBAudio2]<NULL> iid={cd8e756a-5fc7-4624-984b-2af02925b91f} is not supported
[1]2580.48EC::03/17/2024-19:06:06.497 [USBAudio2]returning <NULL> {831fc7bc-6347-44bc-b47b-c0c657b5bf73} 0xFFFFB5855EA67B88
[1]2580.48EC::03/17/2024-19:06:06.497 [USBAudio2](OUT): [ notificationCount=2 requestedSize=11520
[1]2580.48EC::03/17/2024-19:06:06.497 [USBAudio2](0x01): calling AllocatePagesForMdl for 11520 bytes
[1]2580.48EC::03/17/2024-19:06:06.498 [USBAudio2](0x01): MDL: ByteCount=12288 bytes ByteOffset=0 bytes
[1]2580.48EC::03/17/2024-19:06:06.498 [USBAudio2]Cyclic buffer for PCM ch=6 sz=16/16 sr=48000 is: 2 x 5760 = 11520 bytes, 2 x 1 XFERs
[1]2580.48EC::03/17/2024-19:06:06.498 [USBAudio2](0x01): DATA Isoch Buffers: BufferCount=3 PacketsPerBuffer=12 MillisecondsPerBuffer=12 IsochPacketsPerUsbFrame=1 BytesPerPacket=588
[1]2580.48EC::03/17/2024-19:06:06.498 [USBAudio2](0x01): FEEDBACK ENDPOINT UNUSABLE because of bInterval=4 PacketFreq=125
[1]2580.48EC::03/17/2024-19:06:06.498 [USBAudio2](OUT): ] actualSize=11520
[1]2580.48EC::03/17/2024-19:06:06.498 [USBAudio2](OUT)
[1]2580.48EC::03/17/2024-19:06:06.498 [USBAudio2](OUT): [ KSSTATE_ACQUIRE
[1]2580.48EC::03/17/2024-19:06:06.499 [USBAudio2](0x04): ClockSource SET 48000
[1]2580.48EC::03/17/2024-19:06:06.499 [USBAudio2](0x04): ClockSource locked to 48000 by InputTerminal ID=0x01
[1]2580.48EC::03/17/2024-19:06:06.499 [USBAudio2](0x04): LockedFrequency=48000 TerminalCount=1
[0]2580.48EC::03/17/2024-19:06:06.499 [USBAudio2](0x01): Interface 0x01 set to AltSetting 0x01
[0]2580.48EC::03/17/2024-19:06:06.499 [USBAudio2](OUT): ] STATUS_SUCCESS
[0]2580.48EC::03/17/2024-19:06:06.499 [USBAudio2](OUT): [ KSSTATE_PAUSE
[0]2580.48EC::03/17/2024-19:06:06.499 [USBAudio2](OUT): ] STATUS_SUCCESS
[0]2580.48EC::03/17/2024-19:06:06.500 [USBAudio2][
[0]2580.48EC::03/17/2024-19:06:06.500 [USBAudio2]PIN 1 HostPin InPin
[0]2580.48EC::03/17/2024-19:06:06.500 [USBAudio2]KSPROPERTY_PIN_PROPOSEDATAFORMAT SET
[0]2580.48EC::03/17/2024-19:06:06.500 [USBAudio2]CHECKING: WAVEFORMATEXTENSIBLE PCM ch=6 cm=0x0000003f sz=16/16 sr=48000 STATUS_SUCCESS
[0]2580.48EC::03/17/2024-19:06:06.500 [USBAudio2]] STATUS_SUCCESS
[0]2580.48EC::03/17/2024-19:06:06.500 [USBAudio2](OUT): [ notificationEvent=0xFFFFB58561C1EB60
[0]2580.48EC::03/17/2024-19:06:06.500 [USBAudio2](OUT): ]
[1]2580.48EC::03/17/2024-19:06:06.502 [USBAudio2](OUT): [ KSSTATE_RUN
[1]2580.48EC::03/17/2024-19:06:06.502 [USBAudio2](iso0x01): Starting pipe.
[1]2580.48EC::03/17/2024-19:06:06.502 [USBAudio2](iso0x01): State: 0 <NULL> --> 1 <NULL>.
[1]2580.48EC::03/17/2024-19:06:06.502 [USBAudio2](iso0x01): Pipe started.
[1]2580.48EC::03/17/2024-19:06:06.502 [USBAudio2](OUT): ] STATUS_SUCCESS
[0]2580.25E4::03/17/2024-19:06:06.502 [USBAudio2](OUT): 0
[0]2580.25E4::03/17/2024-19:06:06.502 [USBAudio2](OUT): pos=0 smp ts=2574762816651
[0]2580.25E4::03/17/2024-19:06:06.502 [USBAudio2](OUT): packetNumber=1 flags=0x00000000 eosPacketLength=5760
[0]0000.0000::03/17/2024-19:06:06.515 [USBAudio2](0x01): COMPL OUT buf 0 CurrenLinearPosition=480 EVENT
[0]2580.25E4::03/17/2024-19:06:06.515 [USBAudio2](OUT): 1
[0]2580.25E4::03/17/2024-19:06:06.515 [USBAudio2](OUT): pos=0 smp ts=2574762950700
[0]2580.25E4::03/17/2024-19:06:06.515 [USBAudio2](OUT): packetNumber=2 flags=0x00000000 eosPacketLength=5760
[0]0004.0114::03/17/2024-19:06:06.525 [USBAudio2](0x01): COMPL OUT buf 1 CurrenLinearPosition=960 EVENT
[0]2580.25E4::03/17/2024-19:06:06.525 [USBAudio2](OUT): pos=432 smp ts=2574763051106
[0]2580.25E4::03/17/2024-19:06:06.525 [USBAudio2](OUT): packetNumber=3 flags=0x00000000 eosPacketLength=5760
[0]0000.0000::03/17/2024-19:06:06.535 [USBAudio2](0x01): COMPL OUT buf 2 CurrenLinearPosition=1440 EVENT
 

Attachments

  • jmf3_USB init.txt
    394.3 KB · Views: 12
  • jmf4_Init done no Music.txt
    208.5 KB · Views: 12
  • jmf5_music.txt
    270.2 KB · Views: 11
Step step...

So usbd_core.c USBD_LL_DataOutStage() is not triggered

hpcd->DataOutStageCallback() is called by PCD_EP_OutXfrComplete_int(), which is not triggered

PCD_EP_OutXfrComplete_int() is called by HAL_PCD_IRQHandler(): there are a lot of triggering of interrupts related to EP1: good
But in the cascade of "if then else", PCD_EP_OutXfrComplete_int() is not called: conditions are not met. USB_OTG_DOEPINT_XFRC seems never occuring

epint = USB_ReadDevOutEPInterrupt(hpcd->Instance, (uint8_t)epnum);

if ((epint & USB_OTG_DOEPINT_XFRC) == USB_OTG_DOEPINT_XFRC)
{
CLEAR_OUT_EP_INTR(epnum, USB_OTG_DOEPINT_XFRC);
(void)PCD_EP_OutXfrComplete_int(hpcd, epnum);
}

epint value is 0x0200, which correcponds to USB_OTG_DOEPINT_NAK

Handshake Packets: There are three type of handshake packets which consist simply of the PID:
  • ACK - Acknowledgment that the packet has been successfully received.
  • NAK - Reports that the device temporary cannot send or received data. Also used during interrupt transactions to inform the host there is no data to send.
  • STALL - The device finds its in a state that it requires intervention from the host.
Seems that all HAL_PCD_IRQHandler() calls for EP1 are related to those cases.
I downloaded the stm32F407 Reference Manual... but the USB_FS section is like 150 pages :-(
 
I wonder if it makes sense to dig that further. I'm tenacious and don't like to give up, but usb_fs would be, if working, limited to 16 bits / 48k. This is a good enough but limited configuration.

I believe that if I port my code on a usb_hs board, it will work more easily.

The other option would be to have a look to the now open source option if threadX and USBX option. If the code quality is good, this could be an interesting way to achieve the objective of a open multichannel usb to I2S bridge.
 
Ok, so after googling different information, I decide to give a try to the Azure/Threadx on STM32 and the associated USBX stack:
  • Azure Code is moving open source, under MIT license (Eclipse/ThreadX),
  • There is documentation, which looks at least interesting,
  • The Device Audio Class address UAC10 and UAC20,
  • Code seems to support Asynchronous feedback,
  • USBX is advertised as "Industrial Grade embedded USB solution",
  • Azure RTOS USBX has a remarkably small minimal footprint of 10.5 KB of FLASH and 5.1 KB RAM for Azure RTOS USBX Device CDC/ACM support.

I'm curious to see if the overall philisophy is more easy to grasp than the ST USB stack.

Maybe I will turn back after some time ;-)

JMF
 
  • Like
Reactions: 1 user
So I try to get a first understanding about threadx and usbx. I try to recall some memories from class room more than 30 years ago about RTOS :).

The package looks quite clean and documented. It raises my curiosity and will to learn. But the fact is that Audio Class was not the primary focus. So:
  • less documented than some other classes by Microsoft/Eclipse/ST,
  • no official example in stm32CubeIDE,
  • one (and possibly only one) ST example on Github in 2022, on one MCU
  • this shows that there may still be missing pieces to the puzzle to fill the gap between generic USBX code and stm32 hardware: https://github.com/eclipse-threadx/usbx/issues/58 (very informative about issues ahead, but not on solutions (or if solutions have been addressed). Good to check if this looks addressed in the ST example.

Let's continue (and possibly have a look to wireshark in parallel).
 
I have only looked briefly at USBX but it seems to be just another layer on top of Synopsys USB OTG FW and HAL so it works on same interrupts. Unless you can find a functioning USBX UAC2 implementation the benefits of USBX may be slim. And even by choosing another SW stack you cannot avoid the need to study the MCU reference manual.
 
You are probably right bohrok.

Do you think that my issue could be related to incorrect IsoOutIncomplete() interrupt management? Ia admit that I have lost some confidence in the ST USB libraries when it gets a bit aside from the sterero 48k case. Having to dig in the different stack layers usb_device, usb_core, PCD, HAL,... was not my initial expectation.

I recognize that it must be feasible as you managed to get it work well: kudos :)

I looked at the implemented USBX IsoOutIncomplete() handling: "discard and retry". So better than nothing but not as per the MCU reference manual. And seems to be done by the Microsoft staff, not the ST USB peripheral specialist.

/* Incomplete, discard data and retry. */
HAL_PCD_EP_Receive(dcd_stm32 -> pcd_handle,
endpoint->ux_slave_endpoint_descriptor.bEndpointAddress,
endpoint->ux_slave_endpoint_transfer_request.ux_slave_transfer_request_data_pointer,
endpoint->ux_slave_endpoint_transfer_request.ux_slave_transfer_request_requested_length);

Several ST codes have nothing for the IsoOutIncomplete event, which is even worse.