Skip to main content
M
Mttjcksn
Visitor II
December 29, 2018
Solved

STM32H7 USB audio difficulties

  • December 29, 2018
  • 2 replies
  • 2201 views

Hi there,

I'm trying to make a basic USB audio speaker from an STM32H7 Nucleo board. I am fairly familiar with the USB audio middleware having studied it for a few days, but am not having much luck receiving audio data. I intend to use the built-in DAC as an output, but have gone back to basics to try and find the root of this problem.

I start a new CubeMX project for the STM32H7 Nucleo144 board, add in the USB_FS and audio drivers on default settings. I then change the sample rate to 48KHz and generate the project.

In order to get the device to enumerate I have to add HAL_PWREx_EnableUSBVoltageDetector(); to the MX_USB_DEVICE_Init();. Once I do this, the WIndows 10 machine will see the device and allow you to select it as an audio output.

I can see the  AUDIO_Init_FS, AUDIO_DeInit_FS, and AUDIO_MuteCtl_FS, functions in the device struct are being called correctly, (when plugging in / unplugging and muting / unmuting) however AUDIO_AudioCmd_FS, which should be called when audio data is received from the host, is not being called at any time.

I have dug deeper into the USB audio middleware 'core' and the data in function that should call AUDIO_AudioCmd_FS is not being called at all.

I have used wireshark to look at the packets going back and forth and after enumeration, there is no more communication. Almost as if the PC doesn't know to send audio to EP1. I have tried sendig audio to the device from several different applications.

If anyone can help shed any light on what I might be missing, that would be a great help. I have already gone through usb examples for other boards, but can't see any differences that help.

Many thanks,

Matt

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

    If anyone is interested, it's turns out out that the CubeMX configurator generates a pretty unhelpful linker file that will put user data into DTCM memory. This section of memory is not accessible by DMA1 or DMA2, which the DAC uses. I modified the linker script to place data in the D1 section, and it works now..

    2 replies

    M
    MttjcksnAuthor
    Visitor II
    December 30, 2018

    Update:

    I removed the 'Enable SOF' option on the CubeMX USB audio configuration, and now the 'AUDIO_AudioCmd_FS' function gets called once after enumeration. Anyone know why this would have prevented the AudioCmd callback from being called? I now have a new problem...

    I can see isochronous audio packets being sent from the host to the device which contains sample data.

    Next I put the following line in the AUDIO_AudioCmd_FS callback:

    HAL_DAC_Start_DMA(&hdac1, DAC_CHANNEL_1, (uint32_t *)pbuf, size>>1, DAC_ALIGN_12B_R);

    However, the DAC only receives zeros. It appears pbuf is always empty. I have tested this in a few ways, including replacing pbuf with some known data, and the DMA > DAC process is working fine.

    Any suggestions as to why the data isn't getting through, or where to look?

    Many thanks,

    Matt

    M
    MttjcksnAuthorAnswer
    Visitor II
    January 13, 2019

    If anyone is interested, it's turns out out that the CubeMX configurator generates a pretty unhelpful linker file that will put user data into DTCM memory. This section of memory is not accessible by DMA1 or DMA2, which the DAC uses. I modified the linker script to place data in the D1 section, and it works now..

    V
    victagayun
    Explorer
    February 16, 2021

    Hi, is it the Heap size as described here?

    https://jonathan.engineer/posts/audio-dac-stm32/

    BTW, were you able to output the audio data via DAC?

    M
    MJack.1
    Visitor II
    February 16, 2021

    Hey, this was a couple of years ago now, but I don't recall having an issue with heap size. I believe I did get it working, yes.

    Terms & ConditionsAccessibility statement