USBD_LL_PrepareReceive or similar after a USB Class specific SET_CURRENT request where USBD_CtlPrepareRx is used? Otherwise setup packets are no longer received.

[chrischrisWhereDidThisNameCome]

Hi,

So the way the USB class drivers are implemented is that USBD_ClassName_Setup for a SET_CURRENT request will call USBD_CtlPrepareRx to receive the SET_CURRENT data payload and then the request will be processed from the USBD_ClassName_EP0_RxReady function.

The problem I am having is that it seems that after one such SET_CURRENT request, no more setup packets are received. Its as if USBD_LL_PrepareReceive should be called from the USBD_ClassName_EP0_RxReady so that future setup packets can be received, however, the examples from STM32CubeMX don't do this.

1) If I was to try calling USBD_LL_PrepareReceive or similar from EP0_RxReady, what parameters? Does this sound like the problem or am I on the wrong track? Its hard to believe that something so obvious would have been overlooked

[waclawek.jan]

Its as if USBD_LL_PrepareReceive should be called from the USBD_ClassName_EP0_RxReady so that future setup packets can be received, however, the examples from STM32CubeMX don't do this.

First the Status-stage packet has to be sent up.

> The problem I am having is that it seems that after one such SET_CURRENT request, no more setup packets are received.

One of the reasons may be that the host does not send any more setup packets.

I'd recommend you to get some USB bus sniffer (or equivalent, e.g. a decoder to a digital oscilloscope or LA, if they support such), it's an invaluable tool in developing USB.

JW

[chrischrisWhereDidThisNameCome]

Hi Jan, thanks for your reply,

I have already looked at it with a host software side sniffer (Device Monitoring Studio), the host does still send out/down setup packets but the USBD_ClassName_Setup is no longer called after a single USBD_CtlPrepareRx as a result of a SET_CURRENT request.

BTW this happens on the minimal USB Audio project from STM32CubeMX project. Let me be more detailed:

1) STM32CubeMX Version 4.26.1, STM32Cube V1.0, using firmware package STM32Cube MCU Package for STM32L4 Series 1.12.0 (22 May 2018)

2) New Project, STM32L476RE, USB Device, class for FS IP Audio Device class, configure RCC + 3 GPIO's because of how my development board is setup and thats it.

3) Generate TrueStudio project and open with Atollic TrueSTUDIO for STM32 v9.1

4) Run / Debug

5) Windows enumerates the USB Audio Device

6) Click the Mute button on the Windows volume on the taskbar to send a SET_CURRENT request to mute the device, packet can be verified on the Device Monitoring Studio

7) The first SET_CURRENT request arrives at USBD_AUDIO_Setup. However, if you put a breakpoint there, USBD_AUDIO_Setup never gets called again, even when clicking the mute again. You can see on Device Monitoring Studio that down packets are still sent.

[chrischrisWhereDidThisNameCome]

Realised this should probably go under the HAL section so moved it there. https://community.st.com/s/question/0D50X0000AFoaLtSQJ/

[waclawek.jan]

After unmute the host probably wants to send some data. Is your ISO out pipe working OK?

JW

[chrischrisWhereDidThisNameCome · Accepted solution]

Hi JW,

Just found out it was fixed from STM32CubeL4 v1.12 to v1.13....

https://community.st.com/s/question/0D50X0000AFoaLtSQJ/bug-stm32cubemx-usb-audio-class-example-not-handling-usb-setrequests-properly

Anyway, thanks for your help, much appreciated.