cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H7 USB audio difficulties

Mttjcksn
Associate III

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

1 ACCEPTED SOLUTION

Accepted Solutions
Mttjcksn
Associate III

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..

View solution in original post

6 REPLIES 6
Mttjcksn
Associate III

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

Mttjcksn
Associate III

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..

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?

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.

How were you able to solve it and were you able to send it to the DAC?

Is it possible to share the project files with ioc?

I solved it by modifying the linker script to place the audio data into the D1 RAM section. Then the DMA was able to transfer the data to the DAC. I'm afraid I can't share any files because I do not own the source.