STM32H7 SAI + DMA + Cache enabled: nothing works as before

[Mdi c]

Hello, I am working on a project where I implemented various peripherals including a SAI configured in DMA mode. I have defined a 1024 samples buffer and used the Half and Full callbacks to fill it. Everything worked perfectly. However, I quickly realised that the performance of the H7 were incredibly disappointing and I decided to enable the caches to look for improvements.

I have followed the advice of making a SCB_CleanDCache_by_Addr after every half buffer fill but my application now suffers from worst problems. When I see the output of the SAI peripherals, the waveforms look like noise instead of sinewaves. If I try to decrease the buffer length this has an effect on the audio output , the smaller is, the "cleanest" is the output. This makes me thinking about a cache coherency issue.

Do you have an idea about a possible reason ?

thanks

[Piranha]

> dsize is length in bytes... :\

Yes, but those cache management functions together with CPU hardware effectively expand the begin/end addresses of that range to the next lower/higher 32 byte multiples. Read my discussion with Pavel here:

https://community.st.com/s/question/0D50X0000AnsIJeSQM/how-to-get-ethernet-working-again-after-upgrading-to-firmware-fwh7v140-

And also my posts here:

https://community.st.com/s/question/0D50X0000CEr14wSQB/h745-memory-regions-attributes-cache

Take a note that BUFFER_SIZE must also be a multiple of 32. And to operate on half buffer that also, which means that the total buffer size must be a multiple of 64. But that's only for receiving buffers on which SCB_InvalidateDCache_by_Addr() must be called. On transmission buffers SCB_CleanDCache_by_Addr() must be called, which don't need any special alignment. That's because alignment and size of receiving buffers already rules out invalidate/clean conflicts and therefore flushing some additional data on the sides of the buffer will not damage anything.

Take a note that both of those cache management functions must be called before passing the buffer to peripheral. Yes, that's true also for a receive buffer invalidation because otherwise cache eviction can damage those by writing back dirty lines, which can happen during reception time.