Config all AXI-SRAM as write-thru or Disable DCACHE?

[Asantos]

Hi,

If I configure all AXI-SRAM as write-thru.From the performance point of view, Is the same as disable DCACHE?

[TDK]

No, it still caches and will be faster than with cache disabled. It will also have the same cache coherency issues when working with DMA functions.

[Asantos]

So, if I configure the AXI-SRAM as write-thru I still have to deal with cache coherency issues using SCB_CleanDCache_by_Addr and SCB_InvalidateDCache_by_Addr functions?

[Asantos]

So, if I configure the AXI-SRAM as write-thru I still have to deal with cache coherency issues using SCB_CleanDCache_by_Addr and SCB_InvalidateDCache_by_Addr functions?

[TDK]

In general, you won't need to clean with write-thru, but you will need to invalidate when reading memory that the DMA just populated. This can cause issues if your CPU writes to a cache block the same time as the DMA. Align the buffer to a 32-word boundary to avoid this.

[Piranha]

No, in that case you will have to deal only with SCB_InvalidateDCache_by_Addr(), which means you'll still have to know how cache works. By the way on Cortex-M7 enabling D-cache approximately doubles the CPU performance. Therefore not enabling it has a rather huge impact.

So how about actually learning how to use the thing? 😉 The rules are actually pretty simple:

1. The addresses and sizes of Rx buffers must be aligned to D-cache line size.
2. Invalidate the D-cache on Rx buffers before passing them to DMA.
3. Clean the D-cache on Tx buffers before passing them to DMA.
4. Invalidate the D-cache on erased sectors after FLASH erase.

In all cases use ***_by_Addr() functions.

[Piranha]

> invalidate when reading memory that the DMA just populated

It's the other way around - invalidation must be done before passing buffer to DMA and it does matter. Otherwise cache eviction can damage the buffer data during the reception time or later.

[Asantos]

So, a function that receives a buffer pointer as a parameter and has to transmit the buffer using DMA by the SPI for example, is mandatory to copy the buffer to another buffer with the address and size multiple of 32bytes and allocated in the AXI-SRAM . If there's no guarantee that the function pointer is in AXI-SRAM address space and 32bytes align. So, sometimes it is better to avoid DMA in the H7. 

I was in hope that configuring the AXI-SRAM as write-thru, I could avoid using SCB_InvalidateDCache_by_Addr and with that, avoid having to copy the buffer. 

[TDK]

It's not the other way around. Clean writes to memory if it's needed. Invalidate will delete what's in the cache and read from memory.

[Piranha]

I'm talking about before vs after invalidation for receive buffers. And I'm not talking about cleaning but eviction. That is when the CPU cleans dirty cache lines on it's own, because it needs to free some of the cache for a new data.

AN4839 page 4:

• If all the lines are allocated, the cache controller runs the line eviction process, where a line is selected (depending on replacement algorithm) cleaned/invalidated, and reallocated. The data cache and Instruction cache implement a pseudo-random replacement algorithm.

Real life example and more details:

https://community.st.com/s/question/0D50X0000C9hGoz/weird-cache-writeback-behavior-for-stm32f7508