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

[RPuch.2]

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.

Unfortunately, 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).

[waclawek.jan]

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.

JW

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

[RPuch.2]

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.

[AScha.3]

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

in debug (when paused) -> SFRs

can see all peri. registers

[RPuch.2]

SAI and DMA registers:

[RPuch.2]

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

S0NDTR and SAI_ADR change after every pause.

Edit:

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?

[waclawek.jan]

You need to understand, what caching means and why is it a problem using it with DMA. Read https://community.st.com/s/question/0D53W00001Z9K9TSAV/maintaining-cpu-data-cache-coherence-for-dma-buffers and links from there.

JW

[Piranha]

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.

[RPuch.2]

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.

[Piranha]

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