STM32G431 DMA Buffers in CCM SRAM Need the System Bus Alias
A buffer can be readable by the STM32G431 CPU and still be addressed incorrectly by DMA. The important distinction is not simply whether the buffer is called CCM. It is which address reaches the shared physical storage, and whether the linker has accidentally allocated that storage twice.
Scope: STM32G431 category 2 devices, ST DS12589 Rev 6 and RM0440 Rev 9. The worked addresses below apply to this memory map, not to every STM32 with a CCM region. No DMA transfer, timing measurement, or linker build was executed for this article.
Original address diagram. The two windows represent the same 10 KB, not an extra allocation.
Separate storage capacity from address views
DS12589 describes 16 KB of SRAM1 at 0x20000000, 6 KB of SRAM2 at 0x20004000, and 10 KB of CCM SRAM at 0x10000000. CCM also appears at 0x20005800 through the system-bus view, accessible by the CPU and DMA masters. Those blocks total 32 KB; the alias does not increase that total. ST DS12589 Rev 6 section 3.5
RM0440 makes the DMA restriction explicit: DMA accesses CCM through its aliased address. For a CCM byte at offset 0x300, the CPU-oriented address is 0x10000300 and the corresponding system-bus address is 0x20005B00. The byte is the same; the access route differs. ST RM0440 Rev 9 section 2.4
This distinction changes the investigation when a transfer fails only after buffer relocation. Preserve the actual programmed DMA address, the symbol's linked address, its length, and the selected memory view. A debugger reading the symbol successfully establishes CPU visibility, not the DMA route.
Choose one allocation owner for each physical byte
The simplest policy for an application that does not need a separate CCM code region is to allocate its data through a deliberately defined system-bus RAM layout. Another valid design reserves CCM for selected code or CPU data and allocates DMA buffers only in explicitly partitioned remaining space. Neither approach requires guessing from a section name.
The dangerous arrangement is two apparently independent linker regions: a full 32 KB RAM interval starting at 0x20000000 and an additional 10 KB CCM interval starting at 0x10000000. Their numerical addresses do not overlap, so a conventional linker can accept both. Their physical storage does overlap. A stack or heap growing into the upper part of the first region can overwrite an object placed in the second.
Make the allocation policy visible in the linker script and map review. Reserve each CCM byte once, regardless of which address an accessor uses. If a separate CCM execution section is retained, reduce or partition the aliased general-purpose region accordingly. Do not rely on today's small heap to keep an overlapping layout harmless.
Normalize addresses before checking overlap
For a proposed static check, map both CCM address windows to a canonical physical identifier such as “CCM plus offset.” Compare those normalized intervals across code, data, buffers, stacks, and reserved capacity. The check should operate on lengths, not just start addresses.
A hypothetical 512-byte buffer beginning at 0x10000300 occupies CCM offsets 0x300 through 0x4FF. Its DMA view spans 0x20005B00 through 0x20005CFF. A second 512-byte allocation at 0x20005C00 overlaps the final 256 bytes even though its original numeric address appears unrelated to the first symbol.
Check zero lengths, arithmetic overflow, alignment, and the final byte against the selected region's boundaries. Reserve worst-case stack and heap limits, not only initialized objects listed in the image. The purpose of this check is physical allocation integrity; it does not validate transfer widths or peripheral request routing.
Make alias conversion an explicit interface
If CPU code deliberately retains a pointer in the 0x10000000 view, convert it to the DMA view only through a constrained helper that verifies the complete source interval belongs to CCM. Keep the conversion specific to this part's map. Blindly adding a fixed offset to arbitrary pointers can turn an unrelated address into a plausible but incorrect DMA target.
Alternatively, link the shared buffer directly in the system-bus view and pass that address consistently. This avoids repeated conversions and makes map inspection easier. Choose one convention for a module and document it in its buffer API rather than allowing each caller to invent a mapping.
An alias translation is not a memory copy. Do not create two ownership records that permit CPU and DMA writers to change the same bytes concurrently merely because their pointers differ. A producer, transfer engine, and consumer still need a handoff protocol for that single buffer.
Review startup and reset as part of placement
Inspect which startup table clears or initializes each section, and which address view it uses. A section intended to contain runtime data must be prepared before a peripheral reads it. An explicitly retained or uninitialized section needs a validity mechanism appropriate to its actual reset behavior; its name alone establishes nothing.
Also inspect any CCM protection or erase configuration already used by the product. Do not change option bytes simply to make a placement experiment pass. Keep those settings in the build and board record so an apparently identical image is not tested under an unexplained memory policy.
Close the issue with address and data evidence
On a controlled development target, use bounded buffers with distinct initial patterns and guard regions. Record the DMA register address, requested count, final status, and resulting data. Exercise the largest supported transfer and the edges of each allocated region. Reject unsupported pointer ranges in software rather than deliberately submitting them to hardware.
Retain the normalized map audit with that test record. A passing copy proves more when the same physical bytes have one owner, startup initializes them deliberately, and the DMA engine receives the correct alias. It does not establish a performance improvement, but it eliminates a concrete class of address and allocation errors.
