MDF: HAL_MDF_AcqCpltCallback triggered in the middle of recording

[jenssiebertswarm]

Hey there,

I'm currently working on an audio application for the STM32U5A5 (which I'll later port to the STM32N657), using MDF.

The application closely follows the MDF/ADF examples for audio recording found in the U5/N6 Cube firmware packages, with the difference that it does not output the transformed audio signal immediately via SAI, but instead stores it in a large buffer to download it later via the STMCubeProgrammer.

Although the application generally works great, it does not record more than ~2 seconds of audio, even if I increase the size of the storage buffer (e.g., to a size corresponding to 4 seconds of audio recording capacity). No matter how large I set the buffer, the function HAL_MDF_AcqCpltCallback is called approximately 2 seconds after the recording starts. Within the implementation of this function, HAL_MDF_AcqStop_DMA is called to stop the recording.

I would be interested in the criteria according to which the HAL_MDF_AcqCpltCallback function is called. I would have assumed that this happens after the memory buffer is completely full, but that does not seem to be the case in my situation...

For reference, here's my configuration...

...of MDF:

...of GPDMA:

...of the clocks for MDF:

And here's the code to start the recording, from main.c:

(REC_BUFF_SIZE is currently set to 64000 elements, which should be enough for 4 seconds of 16-bit PCM @ 16 kHz).

Any hints or help would be greatly appreciated!

Best regards,

Jens

[Saket_Om]

Hello @jenssiebertswarm 

In this case, the relevant point is that MDF acquisition completion is tied to the DMA transfer length configured in DMAConfig.DataLength, not to the nominal recording duration expected from the application buffer. Here, DataLength is set to REC_BUFF_SIZE * 2, which corresponds to the size in bytes of a 16-bit buffer. If the MDF output is effectively transferred as 32-bit data units, this buffer only holds half as many samples as expected from a 16-bit PCM calculation. For example, a buffer of 64000 16-bit elements represents 128000 bytes, i.e. only 32000 32-bit samples, which at 16 kHz corresponds to about 2 seconds of acquisition. In that case, HAL_MDF_AcqCpltCallback() is called when this programmed DMA length is exhausted, and if HAL_MDF_AcqStop_DMA() is called in the callback, the recording stops at that point.

[jenssiebertswarm]

Hey @Saket_Om,

thanks for your reply!

I also experimented with the DMAConfig.DataLength parameter, since I had the impression that I might have made a mistake there as well. However, that didn’t get me any further.

I just conducted a simple experiment: if I double the size of the memory buffer (say, to 128,000 16-bit elements, which would result in a DMAConfig.DataLength of 256,000 bytes, which in turn should result in 8 seconds of audio), I would expect the length of the recorded audio to also increase to at least 4 seconds...

In my case, it doesn’t, and it remains at 2 seconds.

Other than that, shouldn't the DMA controller (or the HAL) take care that the data is being transferred correctly (i.e. 16 bit) if the data size parameter of the channel is configured to be "Half Word"?

[Saket_Om]

Hello @jenssiebertswarm 

Please refer to the example MDF_AudioRecorder in STM32CubeN6 package. 

[jenssiebertswarm · Accepted solution]

Hey @Saket_Om,

I think the root cause for this issue is the limitation of the DMA transfer size to 65.535 elements. According to the STM32U5 reference manual, the GPDMA_CxBR1->BNDT field can only take up to 16 bits resulting in this maximum transfer length, although the data type of the transfer length parameter in the call chain 

HAL_MDF_AcqStart_DMA -> HAL_DMA_Start_IT -> DMA_SetConfig

is always uint32_t, which is kind of puzzling.

Anyway, I guess it has to be some sort of small circular MDF receive buffer plus some DMA memory-to-memory transfer into the bigger recording buffer then...

Best regards,

Jens