STM32F7: DMA only relieable in first 64k of RAM?

[js23]

Posted on February 04, 2016 at 15:08

I just discovered some strange behaviour while working with the STM32F7 discovery: The SD card driver suddenly stopped working, because I added some additional buffers, variables in memory, nothing else. After investigation of the problem it looks to me that the problem was, that the SD DMA buffer moved from memory location 0x2000xxxx to 0x2001xxxx. So I simply used a fix location in memory for the buffer and decided to do some further investigation when I have more time.

Today I had some problems with the ethernet Driver. To my surprise I had a memory overlap because of some #pragma location=0x20002000 for the ethernet dma buffers in ethernetif.c (from the cube)

But after removing the pragma, ethernet did no longer work reliable.

All in all it looks to me that there is a bug in the STM32F7...

or am I the only one with that problem? But obvously the cube developers seemed to have it too... anybody else? Thanks for listening Hannes

[js23]

Posted on February 24, 2016 at 13:28

Just had some time to take another look at the problem. And now I am even more confused:

According to the datasheed, the DTCM is mapped to 0x20000000-0x2000FFFF. In my opionien, DMA should not be possible in the DTCM. My experience is, that it is the other way around. Could somebody from ST clearify this? Thanks, Hannes

[stm322399]

Posted on February 24, 2016 at 14:36

According 2.3 Embedded SRAM from RM0385:

DTCM-RAM on TCM interface (Tightly Coupled Memory interface) mapped at
address 0x2000 0000 and accessible by all AHB masters from AHB bus Matrix but
through a specific AHB slave bus of the CPU.

No wonder that you can DMA at 0x20000000. Regarding the 0x20010000 boundary, it sound related to the use of SRAM1, but can't tell why DMA cannot access it. Can you provide a *very* minimal code to be tested on discovery ?

[js23]

Posted on February 24, 2016 at 15:00

Thank you for the information. Now I know (and clearly see) what the small dotted line inside the CPU core means on the bus matrix schematic...

To reproduce the DMA-below-64k problem, it should be enough to remove the #pragma location / _attribute__ at in the lwIP sample for the F7 Discovery (lwIP_HTTP_Server_Netconn_RTOS - File: ethernetif.c).

[stm322399]

Posted on February 24, 2016 at 15:42

Location pragma or attributes are not there for aesthetic reasons.

You cannot move them randomly, without consequences. A quick look at the code showed me that region below 64K is uncached whereas upper region is cached. That's certainly the reason why a displaced DMA'ed buffer from low to high region is not working properly. DMA work with any part of SRAM. But wen the area is cached you *must* manage the cache to avoid incoherency. Otherwise keep buffer placed in uncached area. If your application grows, and overlaps reserved uncached area, you must reshuffle your data placement. Good luck.

[js23]

Posted on February 24, 2016 at 15:56

Great. That is the point: ''Otherwise keep buffer placed in uncached area''

I did not think of this. Thank you very much. Hannes

[Asantos]

Posted on December 14, 2016 at 13:20

Hi,

I had the same problem with the ethernet and I solve it using the ethernetif.c from cube examples.

https://community.st.com/0D50X00009XkaTjSAJ

 

Now I'm having this problem with QSPI with DMA.

Did you figure out how to solve this without having to keep the buffer in uncached area? 

Ari.

[Armelle Duboc_O]

Posted on December 20, 2016 at 11:54

Hello,

Maybe the data is stucked in the cache ? it could explain why you have issues with QSPI and Ethernet ...

Kind regards

[Amel NASRI]

Posted on December 26, 2016 at 11:20

Hello,

When datacache is enabled, it is recommended to pay attention to MPU configuration in order to ensure data coherency.

The

http://www.st.com/content/ccc/resource/technical/document/application_note/group0/08/dd/25/9c/4d/83/43/12/DM00272913/files/DM00272913.pdf/jcr:content/translations/en.DM00272913.pdf

 (Level 1 cache on STM32F7 Series) provides tips to efficiently configure MPU. It contains also an example with some suggested solutions that should be helpful depending on the situation and expected behavior.

In the particular case when DMA is used, we have following recommendations:

• If the software is using cacheable memory regions for the DMA source/or destination buffers. The software must trigger a cache clean before starting a DMA operation to ensure that all the data are committed to the subsystem memory. After the DMA transfer complete, when reading the data from the peripheral, the software must perform a cache invalidate before reading the DMA updated memory region.
• Always better to use non-cacheable regions for DMA buffers. The software can use the MPU to set up a non-cacheable memory block to use as a shared memory between the CPU and DMA.

-Amel-

[Asantos]

Posted on December 26, 2016 at 12:00

Hi Amel,

Can you show me the code to make all SRAM1 as non-cacheable?

Ari.