cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F7 DTCM, DMA cache

S A
Associate II
Posted on June 27, 2017 at 04:50

Hi, I am working on a 26x10 RGB LED matrix connected to a STM32F746 through SPI.

The data is located inside the DTCM memory (0x200003E0 address to be precise) and sent through DMA to the shift registers. It all works as long as the Data Cache is disabled.

If I enable the data cache it messes everything up.

If then I clean the cache of the particular location AFTER sending the data through DMA then it works again.

Question is, as long as I understand, the DTCM is not cacheable plus the data to the peripheral will be send through the AHBS bus without involving the Dcache at all...

I fail to see why cleaning the cache after calling the DMA transfer makes everything work again and why actually the cache is affecting this operation at all.

Any help will be appreciated!

3 REPLIES 3
Posted on June 27, 2017 at 10:31

Dear S A,

You may missed to put variables on DTCM region(might put SRAM1/SRAM2 region).

Please confirm your scatter/linkerscript file to use appropriate section.

S A
Associate II
Posted on June 27, 2017 at 11:06

Hi, thanks for the reply.

I looked into that and it was a bit surprising to see that ST actually didn't split the RAM into regions.

I am using the ST provided script with a bootloader region added but the RAM is the same as they do. They basically don't separate anything and start from 0x20000000 which is actually the DTCM region and where all my variables are.

I am attaching the linker script file for your reference.

Santiago

________________

Attachments :

linker_script.lds.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HyCc&d=%2Fa%2F0X0000000b9o%2FudXEotGtO2kcq37KJ7MZSSE_ENhxCesUrh_al_CB6ZM&asPdf=false
Posted on May 04, 2018 at 19:11

1) A good way to tell where your buffer ends up beyond looking at the .map file is to use the build tool in Atollic (it's free). 

2) I have found clean cache to not work in my case.  I had to use invalidate cache and call it just before the call to start the DMA process.  Also in my case (not using DTCMRAM), it made no difference if the Cache was enabled or disabled (both I & D).  If I did not use invalidate cache before the HAL_DMA call, the data out the UART was not what I put in the buffer.  Using invalidate cache allowed me to have both Cache types enabled.