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

[Tesla DeLorean]

Posted on February 17, 2018 at 16:35

Seeing as we are two years on here it might be worth expanding this,

The TCM RAM isn't cached because it is already fast and tightly coupled to the core, caching it just wastes resources that are better applied to slower memory subsystems. Being uncached is particularly helpful for use with DMA RX which can change the content outside the purview of the core. Write-through behaviour is important to DMA TX as it ensures that data you have written makes it to the memory the DMA acts upon.

The Cortex-M7 does not have hardware to implement coherency and monitor the bus traffic. You can mark an area as uncached, and also invalidate the cache if you know the memory you want to look at has been changed by hardware/peripherals. The latter is helpful if the buffer address is more dynamic and the penalty of marking large areas as uncacheable is undesirable for performance reasons.

The newer F76xx/77xx parts has 128KB of TCM RAM at 0x20000000, the H743 also has 128KB.

Consider having different memory pools to allocate memory based on what you're using it for. Use linker scripts or scatter files to describe the different memories, and use #pragma or attributes to direct particular variables, structures, etc into appropriate memory areas.

You can invalidate memory regions based on 32-byte aligned memory addresses

 SCB_InvalidateDCache_by_Addr()

[Richard I]

Posted on April 18, 2018 at 14:02

Thanks for explaining this Clive, but something still doesn't add up. I experienced exactly the same problems asthe original poster: as SRAM requirements grew, first the Cube-generated Ethernet code stopped working, then the SD-card followed. In both cases, the DMA buffers had crossed the

64 kB

SRAM boundary. The MCU I use is a STM32F777, whichspecifies

128 kB

TCM! I couldn't find any reference to any DMA limitation related to a 64 kB boundary. Anyway, for me the fix was, in both cases, to add a RAM section straight afterflash section in the GCC linker script, and definitely before the .data section: /* DMA data section */ .low_ram (NOLOAD) : { . = ALIGN(4); *(.low_ram); /* .data sections */ *(.low_ram*); /* .data* sections */ } >RAM

Then mark every DMA buffer thusly, (top line is modified fatfs.h structure, only the DMA-related buffer is touched with __ALIGNment, bottom line is the same struct declaration in some .C file):

__ALIGN_BEGIN BYTE win[_MAX_SS] __ALIGN_END ; // ensure 4 byte alignment in FATFS in the header file
FATFS fs __attribute__((section('.low_ram'))); // ensure the entire struct is contained in TCM RAM�?�?

This works fine, but in order to maintain my sanity, I'd still love to know why the DMA crashes at the 64 kB boundary.

[Manish Sharma]

Posted on May 31, 2018 at 12:31

Hi All,

I was doing SPI DMA Transmit Operation and i captured some observations which confused me. Please help.

 

Observation 1:

I was using global buffer ( uint8_t txBuf[5] ; ) and I enabled (using STM32CubeMx) D-Cache inside main() then to perform DMA, I need to call SCB_CleanDCache_by_Addr((uint32_t*)&txBuf[0], 5) before HAL_SPI_Transmit_DMA(&hspi4, txBuf, 5) otherwise DMA doesn't work or need to configure MPU_Config() for the DMA to work.

Observation 2:

I was using global buffer ( uint8_t txBuf[10] ; ) and I didn't enable (using STM32CubeMx) D-Cache inside main() then to perform DMA , I don't need to call SCB_CleanDCache_by_Addr((uint32_t*)&txBuf[0], 5) before HAL_SPI_Transmit_DMA(&hspi4, txBuf, 5)

and DMA works fine.

 

I am confused with the results and i checked it 10-20 times. I am unable to reach to conclusion as i am new to it.

Regards

Manish

[Tesla DeLorean]

Posted on May 31, 2018 at 14:03

Perhaps review some texts on coherency, ie holding data in two places, and the content not always being the same at the instant that it is important.