Dear list,
I'm currently developing an USB-Audio composite device with the help of an stm32L4.
As composite is not really supported in the cube firmware, I have adopted the stack to support that meanwhile.
The device consists of an virtual com-port and 2 audio devices.
Everything is recognized well and is also basically working the most time.
Unfortunately there is one single problem left which seems to be a timing issue somehow:
Sometimes when doing a EP0-IN transfer because of a descriptor read or a audio-ctrl read (e.g. reading the frequency of the clock unit), I see an endpoint-stall status (-EPIPE) on wireshark although the corresponding data is appended in the packet. Yes: There is a packet with a -EPIPE status but containing the data requested.
I don't have any clue where this could originate from, as all breakpoints that I try to generate examining the STALL (e.g. where it is set) do not come true.
So may that be something in the core?
Is there any further Idea where / what to examine where this single stall status could come from although "USBD_CtlError" is not hit?
I see that a stall condition is also set on end of a successfull transfer of the data-in endpoint and is reset on a new Setup-Packet. But as the whole stack seems to be interrupt-based (from the same interrupt source), I'm wondering who could interfere here.
I just added one dissected trace which shows the problem:
Here you can see 2 tries to get the Manufacturer-String-Descriptor.
The 1st one fails, the 2nd one come true although this is completely the same request.
The same happens for other control-in transfers.
Maybe s.o. has some ideas how to debug this further. If one needs further information (code-parts, descriptors, wireshark-dissections) pleas contact me.. I just didn't want to flood the board.
Thanks in advance.
Best Regards
Pascal
