cancel
Showing results for 
Search instead for 
Did you mean: 

SCB_InvalidateDCache_by_Addr not operating correctly

FrankNatoli
Associate III

Using twin STM32H7B3I EVAL boards to develop master and slave firmware.

Found that slave board was experiencing overruns on SPI slave receive.

Revised SPI slave implementation to use DMA.

Found incredibly bizarre data corruption, after some number of good packets moved from EVAL master to EVAL slave.

SCB_InvalidateDCache_by_Addr was called after each DMA receive completion to invalidate the data cache for the receive buffer.

However, once data cache was completely disabled, data corruption of receive DMA packets ceased.

Are there any timing or special considerations for the use of SCB_InvalidateDCache_by_Addr?

26 REPLIES 26

The correct implementations were included in a H7 firmware package v1.9. Therefore the functions in v1.8 are broken. Of course, they can be used with a proper wrapper code.

I'm almost sure that SCM_clean/invalidate_by_Addr caused a fault for me with package v. 1.9. Will re-check when opportunity occurs.

Terrific.

I've just been dropped into the middle of a project using an STM32F746; RTOS and RNDIS. I am trying to gain an understanding of the cache management/mpu issues.

I am unable to open your demo firmware. I get a message about insufficient privilege and access denied. I searched for the message and it seems to be that it resides on an older hub.

Is it available anywhere else?

> I've just been dropped into the middle of a project ...

Congratulations!  Ain't it great?

Guidelines for data cache management to avoid nasty surprises:

- Align a buffer that's shared with an "active accessor" (e.g., DMA) to an address boundary equivalent to the data cache line length.

- Set the overall length of a buffer that's shared with an active accessor to be an integral number of cache lines.  Note that the entire length of these shared buffers may or may not be used by the active accessor but the "integral number of cache lines" length becomes very important when you ...

- Flush (terminology in use for decades before the silly, made-up "clean") the data cache before allowing/enabling an active accessor's read of the buffer.  The base address of the data cache flush operation is the cache-line-length-aligned address described above.  The length of the data cache flush operation is the overall length of the buffer (i.e., an integral number of cache lines) described above.  Note that the overall length of the buffer passed to the flush many not necessarily be the length of the memory area the active accessor sees but it must be an integral number of cache lines.

- Invalidate the data cache after an active accessor's writing to a (cached) buffer is complete.  The base address of the data cache invalidate operation is the cache-line-length-aligned address described above.  The length of the data cache invalidate operation is the overall length of the buffer (i.e., an integral number of cache lines) described above.

 

The reason for the (sometimes awkward) buffer alignment and length criteria are to prevent potential corruption of memory adjacent to the buffer due to the flush and invalidate operating on whole cache lines

Thank you very much for your kind reply

Piranha
Chief II

@DRega.1 , take a note that, after the discussion in this topic, I created an article about D-cache maintenance, which explains all of the requirements and shows a correct and complete example:

https://community.st.com/t5/stm32-mcus-products/maintaining-cpu-data-cache-coherence-for-dma-buffers/m-p/95746

@David Littell , for the flush/clean operation the buffer address and size alignment is not necessary, and for the invalidate operation doing it just after the reception is not enough - it must be done both before and after the reception. It is all explained in the link above and earlier posts in this topic.