STM32G474 DMAMUX Overruns: Why a Clear Flag Can Hide a Lost Trigger

A zero DMAMUX overrun flag is not proof that every trigger reached an STM32G474 DMA pipeline. ST documents cases where the hardware omits an overrun indication, including a request-generator boundary that can also shorten the next generated burst.

This review applies to ES0430 Rev 9, June 2024, sections 2.4.1–2.4.3, for the listed G474 silicon revisions Z, Y and X. Table 2 maps them to REV_ID values 0x2001, 0x2002 and 0x2003. Table 3 marks the three limitations N on all three revisions: N means limitation present with no workaround, not unaffected. Read the detailed text as well, because section 2.4.2 supplies a timing-avoidance condition.

Separate a trigger from a served DMA request

In RM0440 Rev 9, section 13.4.5, a request generator starts a programmed request sequence after a selected trigger. Its count decrements when the DMA controller serves requests. The generated count is GNBREQ + 1.

Those are three different observations: an external trigger occurred, the generator emitted requests, and the DMA completed transfers. A DMA completion interrupt only describes the transfer operation that actually occurred. It does not establish that no input trigger was ignored earlier.

For example, a setting of GNBREQ = 3 requests four transfers per accepted trigger. Any monitor that treats the encoded field itself as the transfer count starts with an off-by-one error before the silicon limitation enters the analysis.

Recognize the last-request boundary

Section 2.4.2 describes a trigger arriving at the critical clock cycle when the last generated request is being served, at the end of the overrun condition. The expected OFx indication is not asserted. On the following trigger, the generator issues only one DMA request regardless of its programmed count.

The stated condition is more than two requests: GNBREQ[4:0] > 00001, equivalently an encoded value greater than one. Do not rewrite it as “two or more transfers.” With the illustrative four-request configuration, this failure can leave a following burst containing one request rather than four.

The detailed avoidance instruction is to make the trigger period longer than the time needed to serve the programmed requests. That interval must account for the actual DMA service path and contention. A nominal average measured with other traffic disabled does not establish a worst-case bound.

Review flag clearing across concurrent channels

A different limitation appears in section 2.4.3. While software writes DMAMUX_RGCFR to clear one request generator’s overrun flag, an overrun from another active generator can fail to raise its own flag. The problem crosses channels; a correct clear mask does not remove it.

The erratum lists no workaround and advises avoiding concurrent request-generator use when at least two channels can produce an overrun. Polling more frequently cannot recover a status bit that the hardware never set. Clearing only the intended channel remains good register discipline, but it is not a cure for this race.

Section 2.4.1 describes the corresponding synchronization-mode issue involving SOFx, DMAMUX_CSR and writes to DMAMUX_CFR. Keep this separate from request-generator OFx and DMAMUX_RGCFR. A log that labels both simply “DMA overflow” hides which mode and clear register are involved.

Make the operating restriction explicit

For each generator, record its trigger source, edge selection, encoded request count, DMA destination and maximum service interval. Identify other DMA traffic that can delay completion. Then record whether the supported trigger envelope rules out an overlap, including bursts and recovery transitions rather than only steady-state frequency.

For concurrent channels, list which ones can overrun and which handlers write the shared clear register. If the application requires simultaneous overrun-capable generators with reliable fault reporting, these limitations are a design constraint. Restructure the acquisition or select another supported mechanism rather than declaring the flag path reliable after a clean bench run.

RM0440 also requires GNBREQ changes with the generator disabled and states that writes to the generator control register mask triggers for three AHB cycles. Reconfiguration therefore needs its own controlled input boundary. Treating a live control write as a harmless way to resynchronize can introduce another explanation for missing events.

Validate counts independently of overrun flags

A proposed qualification fixture should compare an independently observed trigger count with DMA progress and expected data units. Include a sequence identifier in the stimulus or another suitable external observation when the application permits it. Do not use the same possibly affected flag as both fault detector and proof that the detector works.

Test around the selected service-time boundary and under the supported concurrent load, retaining trigger, transfer-count and status observations separately. Such testing can expose a bad assumption; it cannot repeal the erratum or prove an undocumented operating arrangement safe.

No hardware experiment was run here. The practical conclusion is to constrain the trigger and concurrency conditions before relying on diagnostic flags. A clear OFx says only that the flag is clear; on these documented paths, it does not certify a lossless trigger history.