Showing results for 
Search instead for 
Did you mean: 

Data acquisition from PDM microphones via SAI using DMA - problem with writing to PDM_buffer

Associate III

I have configured the readout of 4 PDM microphones through the SAI interface. I am using 1 slot of 32 bits per frame.


I have enabled DMA.

0693W00000aHesVQAS.pngUnfortunately, when reading PDM data, the first 6 and last 2 values of the array are filled with zeros. This happens regardless of the size of the PDM_buffer.


Do I have something misconfigured? What could be the cause?

Edit: If the PDM_buffer array is of type uint16_t, there are 2x more zeros (12+4 ), and in the case of uint8_t 4x more zeros (24+8).


Which STM32?

Read out and check/post content of DMA and SAI registers, perhaps at the point just before SAI gets enabled.

If DMA is circular, I see no reason why DMA buffer won't get filled entirely.


[EDIT] Although you did not tell us the STM32 model you are using, you enable caches in code, so mind cache coherency and DMA - read the related note here.

Associate III

I use STM32H743ZIT6 (Nucleo).

How can I read out content of DMA and SAI registers?

I work in CubeIDE and HAL library.

Edit: I have tried the first solution from the link and it doesn't work. Tomorrow I'll check the second one.


>How can I read out content of DMA and SAI registers?

in debug (when paused) -> SFRs

can see all peri. registers


If you feel a post has answered your question, please click "Accept as Solution".
Associate III

SAI and DMA registers:0693W00000aHfnbQAC.png0693W00000aHfnWQAS.png

Associate III

To see proper register values, I had to pause and resume debug process.

S0NDTR and SAI_ADR change after every pause.


None of the 3 solutions from the link worked.

After commenting out the SCB_EnableDCache() line, it populates the array correctly for me.

But can I just disable DCache like this with impunity? Will, for example, pdm2pcm work properly for me without it?

You need to understand, what caching means and why is it a problem using it with DMA. Read and links from there.


Disabling the D-cache will at least halve the performance. Such a desire rises a question of why do you chose one of the most complex MCUs out there, if you are not willing to learn how it works and actually use it's features.

Sound acquisition is just one of the components of my project. I chose H7 for several reasons: I need high performance (DSP, ANN), I couldn't handle DMA support in F7, I use interfaces that I didn't have in F4 and F7. The fact is that I am a layman in the subject of microcontrollers. So far, I've treated them as a tool that I don't have to delve into too much. This worked with F1, F4 and F7. Problems started with DMA in F7, so I changed to H7. Here I ran into more problems.

> I need high performance

And loosing half the performance is somehow OK?

> Problems started with DMA in F7, so I changed to H7. Here I ran into more problems.

You took a pretty complex Cortex-M7 based MCU, run into issues and, instead of learning how it works, you then took an even more complex Cortex-M7 based MCU and, of course, ran into even more issues. Your actions are against the common sense...

Performance comes at a price and that price is complexity. Either you learn it or you will not have an access to the full performance.