RAM access by CPU and DMA - Page 1
Forum section: electronics / beginners

author: bonzer
author_rank: Regular Contributor
timestamp: August 22, 2024, 06:07:00 pm
content: Hi everyone, I'm curious whether popular ARM Cortex-Mx microcontrollers like STM32 or TI can encounter issues when both the CPU and DMA simultaneously access the same RAM addresses. For example, during a periodic RAM self-test as required by safety standards, could this overlap with DMA operations? What typically happens in such cases?

author: Siwastaja
author_rank: Super Contributor
timestamp: August 22, 2024, 06:21:10 pm
content: Since common microcontrollers implement single-port RAM, CPU and DMA have to compete for the access. Therefore on-going DMA transferwillslow down code that accesses the same RAM. And CPU accessing RAM will slow down the DMA, unless of course the DMA feeds some much slower peripheral with at least a minimal FIFO inbetween.For exact details, read the documentation of the microcontrollers in question. For example, off my memory, STM32 controllers have an arbiter which guarantees that CPU gets at least every other RAM cycle.In many (most?) projects possible slowdown isn't very dramatic if code is running out of FLASH (ordifferentRAM, e.g. ITCM) and only accesses a few RAM variables here and there, it can go totally unnoticed and not matter at all. But there are cases where the performance becomes a showstopper.

author: Jeroen3
author_rank: Super Contributor
timestamp: August 22, 2024, 06:27:08 pm
content: Yes, this can happen. They will have to shareIt can cause jitter and unnecessary delays (micro-optimizations)It's complicated though. Many modern ARM core have a bus matrix where simultaneous transactions can take place.For example in the STM32F407 the DMA1 can access SRAM1, DMA2 can access SRAM2 and the core can read instruction at the same time.However if both want the same memory region, there is a round-robin arbitration system.As you can see from this, using the core couple memory, not on the bus matrix at all can be very quick because you never have to wait. But you alos can't access it with the DMA. And if you put your instruction in SRAM2, there is apipelinebottleneck because instructions and data cannot be read at the same time anymore. Which it can for SRAM1 or FLASH.Penalty can get especially harsh when you access the AHB peripherals, because this bus can be slower. Meaning a longer wait.

author: bonzer
author_rank: Regular Contributor
timestamp: August 23, 2024, 03:55:18 pm
content: Thank you very much for the detailed answers, I'm taking this information into account. Currently, I'm working with the STM32U535. I'm going ahead with digging further into the documentation but it's huge. In case I have any updates I'm gonna post it here. If anyone has ever dealt with this microcontroller in the past and knows these aspects of it, let me know.

author: newbrain
author_rank: Super Contributor
timestamp: August 26, 2024, 12:48:27 pm
content: Quote from: bonzer on August 23, 2024, 03:55:18 pmNote that another point to take into account when sharing memory between multiple masters (CPU and DMA in this case) is caching.In your case, STM32U535 has both instruction and data caches.Unless you are DMAing code to be run, the I-Cache is not an issue.And, for this MCU, the D-cache is also not a problemunless you are using external memories, but for other MCUs it can be (STM32F7, H7 to stay with ST).AN4839, though specific for F7 and H7, gives a good explanation on how to make sure cache coherency is kept when using DMA - no worries if no external RAM is used, in your case.Another resource to understand the different behaviour of different memory types (M33 only has Normal and Device, Shareable or Not etc) is e.g.Arm's own M33 Generic User Guide, chapter 2.2.2