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

[Amel NASRI]

Posted on December 26, 2016 at 14:15

Hi

‌,

You can use following code to make all SRAM1 (and SRAM2) as non-cacheable:

MPU_Region_InitTypeDef MPU_InitStruct;/* Disable the MPU */HAL_MPU_Disable();/* Configure the MPU attributes as WT for SRAM1 and SRAM2 */MPU_InitStruct.Enable = MPU_REGION_ENABLE;MPU_InitStruct.BaseAddress = 0x20010000;MPU_InitStruct.Size = MPU_REGION_SIZE_256KB;MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;MPU_InitStruct.IsBufferable = MPU_ACCESS_NOT_BUFFERABLE;MPU_InitStruct.IsCacheable = MPU_ACCESS_NOT_CACHEABLE;MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE;MPU_InitStruct.Number = MPU_REGION_NUMBER0;MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;MPU_InitStruct.SubRegionDisable = 0x00;MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_ENABLE;HAL_MPU_ConfigRegion(&MPU_InitStruct);/* Enable the MPU */HAL_MPU_Enable(MPU_PRIVILEGED_DEFAULT);�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

- Amel -

[Asantos]

Posted on January 18, 2017 at 23:23

Amel,

This code only worked for me if:

MPU_InitStruct.TypeExtField =  MPU_TEX_LEVEL1;

 if

MPU_InitStruct.TypeExtField =  MPU_TEX_LEVEL0;

Occurs a HardFault Interrupt;

[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.