Buffer Ownership, Overruns, and Cache Coherency

The lessons so far lead to one rule: at any moment a DMA buffer belongs either to the CPU or to the device, never to both. Ownership passes at defined points:

• to the device when the program starts a transfer on it (or re-arms a channel with it);
• back to the CPU when the transfer completes (the interrupt, the half-transfer event, the busy flag clearing).

While the device owns a buffer, the CPU neither reads nor writes it: not to peek at the first bytes, not to clear it for next time. The Linux DMA API makes the hand-overs explicit: for a streaming mapping, dma_map_single() gives a buffer to the device and dma_unmap_single() returns it, while dma_sync_single_for_cpu() and dma_sync_single_for_device() pass ownership back and forth while a mapping is reused (coherent allocations need no hand-over, at the cost of uncached memory). Zephyr leaves both channel synchronisation and cache coherency to the caller. On a simple microcontroller nothing enforces the rule, which is why breaking it produces data that is right almost always.

Lessons 2, 4 and 5 showed three ways to lose data: a peripheral FIFO that overflows while the channel is held off, a ring buffer that the DMA laps, and a double buffer processed too slowly. None of them stops the system; each must be detected on purpose:

• peripheral flags: the RP2040 ADC sets OVER when its FIFO overflows; UARTs have overrun error flags (unit 10, lesson 2);
• DMA errors: a bus error stops an RP2040 channel with READ_ERROR or WRITE_ERROR set, and READ_ADDR or WRITE_ADDR (for a read or a write error) shows roughly where; the STM32 HAL reports transfer, FIFO and direct-mode errors through XferErrorCallback;
• counts that do not wrap: a position taken modulo the ring size can never show a lap, so compare a total instead (on the RP2040, bytes written = RELOAD − TRANS_COUNT, because the ring wraps only the address; on an STM32, count half- and full-transfer events), and count an overrun when a double buffer is handed over while the previous one is still marked busy;
• sequence numbers or sample counters in the data itself (unit 10, lesson 6).

Count every loss in a variable that a debugger or a log can show, like unit 9’s dropped counter. A counter that stays at zero is evidence; silence is not.

A core with a data cache keeps copies of recently used memory in fast cache lines. With a write-back cache, a CPU write updates only the cached copy (marking the line dirty) and reaches SRAM later, when the line is evicted. The DMA reads and writes SRAM directly and never sees the cache. The RP2040’s Cortex-M0+ cores have no data cache, so the problem does not arise there; Cortex-M7 cores, such as those in STM32F7 and STM32H7 parts, usually have one (it is an option of the core, which is why CMSIS tests __DCACHE_PRESENT). Two operations bring the copies back into agreement:

• clean: write dirty lines back to SRAM (the cached copy stays valid);
• invalidate: discard the cached copy, so the next CPU read fetches from SRAM.

Which one depends on who wrote last:

• transmit (the CPU wrote, the device will read): clean after the last CPU write and before starting the DMA;
• receive (the device wrote, the CPU will read): invalidate after the DMA finishes and before the CPU reads. Also make sure, before handing the buffer over, that no dirty line of it remains (invalidate or clean it then too), or an eviction during the transfer could write old data over the new.

↑ This step uses the figure at the top of the page.

With CMSIS on a Cortex-M7:

static uint8_t tx[256] __attribute__((aligned(32)));
static uint8_t rx[256] __attribute__((aligned(32)));    /* aligned, and a multiple of 32 long */

build_message(tx);
SCB_CleanDCache_by_Addr(tx, sizeof tx);        /* CPU → SRAM, then hand over */
start_tx_dma(tx, sizeof tx);

SCB_InvalidateDCache_by_Addr(rx, sizeof rx);   /* no dirty lines left to be evicted onto the data */
start_rx_dma(rx, sizeof rx);
/* … transfer complete … */
SCB_InvalidateDCache_by_Addr(rx, sizeof rx);   /* drop anything cached meanwhile, then read */

The CMSIS functions end with __DSB() and __ISB(), so the maintenance is complete before the next statement starts the DMA, and they compile to nothing on a core without a data cache. volatile does not help here: a volatile access still goes through the cache. The Linux API’s rule is the same in its own words: sync DMA_TO_DEVICE after the last modification and before the hand-off, sync DMA_FROM_DEVICE before accessing data the device may have changed.

uint8_t rx[100] lands at 0x2000_0414. Invalidating it covers

$$\left\lceil \frac{100 + 20}{32} \right\rceil = 4 \text{ lines}$$

from 0x2000_0400 to 0x2000_047F, 128 bytes.

The 20 bytes before the buffer (0x2000_0400–0x2000_0413) and the 8 after it (0x2000_0478–0x2000_047F) belong to other variables. If the CPU had just updated one of them and the line was still dirty, the invalidate discards that update: a variable that occasionally reverts to an old value, far from any DMA code. The fix is static uint8_t rx[128] __attribute__((aligned(32))): 28 bytes of padding buy four lines that belong to the buffer alone.