Skip to main content
chrischrisWhereDidThisNameCome
chrischrisWhereDidThisNameCome
Associate III
January 18, 2019
Solved

[BUG] STM32CubeMX USB Audio Class example not handling USB SET_REQUESTS properly

  • January 18, 2019
  • 5 replies
  • 2836 views

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.

It looks like calling USBD_CtlPrepareRx (because of needing to receive the SET_REQUEST data stage via USBD_AUDIO_EP0_RxReady) messes up the default control pipe / endpoint 0 so that future setup packets don't arrive at the USBD_AUDIO_Setup function.

Surely there must be a way to restore the endpoint 0 after USBD_CtlPrepareRx and USBD_AUDIO_EP0_RxReady?

Note: If you comment out USBD_CtlPrepareRx in USBD_AUDIO_EP0_RxReady then multiple SET_CURRENT requests can be sent by clicking the mute button. Otherwise, the setup stage freezes up / no longer gets called after the first SET_CURRENT request completes.

This topic has been closed for replies.
Best answer by chrischrisWhereDidThisNameCome

I have just downloaded STM32L4 v1.13 (instead of the 1.12 I was using) and.....

it works.

Courtesy of lines 1084 to 1087 of stm32l4xx_hal_pcd.c, its the only lines that got changed from v1.12 to 1.13

        if ((USBx_OUTEP(0U)->DOEPINT & (1U << 5)) != 0U)

        {

         CLEAR_OUT_EP_INTR(epnum, (1U << 5));

        }

Can confirm this was the problem by commenting it out, behavior is the same as with v1.12.

I feel like crying. This is one of the most classic problems in the book (always make sure you are using the latest version), but I started with this around the beginning of December last year and I think at the time 1.12 was the latest... At any rate, when this problem came up, upgrading to latest versions wasn't my first thought....

5 replies

chrischrisWhereDidThisNameCome
chrischrisWhereDidThisNameComeAuthor
Associate III
January 18, 2019

I'm still investigating this.

I'm looking at the registers that are needed for control 0 out transfers / Setup packets as per RM0351 47.16.5 for whats necessary for control 0 to receive setup packets.

These generally have the values

DAINT 65536

DOEP 65536

DIEP 65536

GRXFSIZ 128

STUPCNT 2

while the setup stage is working. However, after EP0_RxReady, these are as follows:

DAINT 0

DOEP 0

DIEP 0

GRXFSIZ 128

STUPCNT 3

Surely some re-initialization is needed after EP0_RxReady... .

chrischrisWhereDidThisNameCome
chrischrisWhereDidThisNameComeAuthorAnswer
Associate III
January 18, 2019

I have just downloaded STM32L4 v1.13 (instead of the 1.12 I was using) and.....

it works.

Courtesy of lines 1084 to 1087 of stm32l4xx_hal_pcd.c, its the only lines that got changed from v1.12 to 1.13

        if ((USBx_OUTEP(0U)->DOEPINT & (1U << 5)) != 0U)

        {

         CLEAR_OUT_EP_INTR(epnum, (1U << 5));

        }

Can confirm this was the problem by commenting it out, behavior is the same as with v1.12.

I feel like crying. This is one of the most classic problems in the book (always make sure you are using the latest version), but I started with this around the beginning of December last year and I think at the time 1.12 was the latest... At any rate, when this problem came up, upgrading to latest versions wasn't my first thought....

waclawek.jan
waclawek.jan
Super User
January 18, 2019

Oh, so ST shot themselves into their foot with the undocumented bits...

https://community.st.com/s/feed/0D50X00009XkVuPSAV

https://community.st.com/s/question/0D50X00009XkaAaSAJ/l4-otg-the-mysterious-bit-15-in-doepint-and-otgcoreid

JW

Sami1
Sami1
Associate II
October 7, 2022

I am having a similar problem. Can anyone help me please?

I am trying to implement a simple soundcard from using STM32F407G-DISC1 board.

It utilizes STM32F407. I am using CubeIDE version 1.10.1

I configured the USB to be Full-speed Device Only. And I configured the middleware as Audio class.

I set the the heap size at 0x4000, and stack size at 0x2000.

When I connect it via the USB, Windows surely recognizes it as "Speakers".

I know that when the microcontroller receives Audio data, I should have access to the samples in the "AUDIO_AudioCmd_FS" function.

The problem is that, when I send Audio data to the microcontroller, the AUDIO_AudioCmd_FS function gets called only once, and it does not get called again.

No matter how many times I resend Audio data from the PC to the microcontroller, the AUDIO_AudioCmd_FS function does not get called again.

Please help!!

Sami1
Sami1
Associate II
October 7, 2022

My problem is solved!

I want to point out 2 things:

  1. I was looking at the wrong function. "AUDIO_PeriodicTC_FS" is the function that I should use to get access to the audio samples
  2. I used the default Audio USB code that is generated by the CubeMX. This code turned out to be not stable. I got a more stable code from https://github.com/sdima1357/stm32f401cdu6_Audio

I copied the following files into my project:

/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_pcd.c

/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_pcd_ex.c

/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_ll_usb.c

/Middlewares/ST/STM32_USB_Device_Library/Class/AUDIO/Src/usbd_audio.c

/Middlewares/ST/STM32_USB_Device_Library/Core/Src/usbd_core.c

/Middlewares/ST/STM32_USB_Device_Library/Core/Src/usbd_ctlreq.c

/Middlewares/ST/STM32_USB_Device_Library/Core/Src/usbd_ioreq.c

/USB_DEVICE/App/usb_device.c

/Drivers/STM32F4xx_HAL_Driver/Inc/stm32f4xx_hal_pcd.h

/Drivers/STM32F4xx_HAL_Driver/Inc/stm32f4xx_hal_pcd_ex.h

/Drivers/STM32F4xx_HAL_Driver/Inc/stm32f4xx_ll_usb.h

/Middlewares/ST/STM32_USB_Device_Library/Class/AUDIO/Inc/usbd_audio.h

/Middlewares/ST/STM32_USB_Device_Library/Core/Inc/usbd_core.h

/Middlewares/ST/STM32_USB_Device_Library/Core/Inc/usbd_ctlreq.h

/Middlewares/ST/STM32_USB_Device_Library/Core/Inc/usbd_def.h

/Middlewares/ST/STM32_USB_Device_Library/Core/Inc/usbd_ioreq.h

Now it works.. I think :)

Terms & ConditionsAccessibility statement