STM32G474 Injected ADC Queues: Submit One Complete Context per JSQR Write

An STM32G474 injected ADC queue changes the meaning of a configuration write. When the context queue is enabled, writing ADC_JSQR submits a context. Updating the trigger and then updating individual ranks can therefore submit several different sequences instead of constructing one sequence in place.

Use a complete context as the software submission unit. This review covers externally triggered, non-discontinuous injected sequences using RM0440 Rev 9, section 21.4.21 and UM2570 Rev 2, the injected-queue LL API. It supplies a register-model review, not tested target firmware.

Build the context away from the peripheral

The context includes trigger selection, trigger edge, sequence length and the injected channel ranks. Assemble all of those choices in ordinary software data before the single submission write. Treat channel availability and trigger routing as separate validity checks against the selected ADC instance.

For a hypothetical pair of acquisitions, context A requests two valid channels from one hardware trigger; context B requests one valid channel from another hardware trigger. Those descriptions are complete application intentions. A partially edited register image that combines A’s ranks with B’s trigger is neither intended acquisition.

UM2570 explicitly warns against using separate injected-trigger and channel setters for a queued sequence. Its LL_ADC_INJ_ConfigQueueContext() interface groups the complete context into one write. Match that documented interface to the exact headers used by the build before adopting a call. The broader parameter list includes software triggering, but queued conversion itself supports external triggers only.

Review every writer to JSQR, including initialization helpers, diagnostics and interrupt paths. A second owner that performs a harmless-looking read-modify-write can submit another context. Reading JSQR reports the active context; it does not return a software-editable image of every queued entry.

Work the overflow trace before choosing a refill policy

Begin the following illustrative trace with an empty queue and external triggers held inactive:

1. Submit complete A. The first context becomes active and occupies the first queue position.
2. Submit complete B. The two-context queue now contains A followed by B.
3. Attempt complete C before a sequence finishes. The write is ignored, JQOVF is asserted, and A/B remain unchanged.
4. Allow A’s matching trigger and wait for its full sequence to complete. B becomes the active context for the next sequence.

The useful failure distinction is that C was not accepted. Clearing an overflow indication does not insert C afterward. A software scheduler that increments its accepted-context counter unconditionally can consequently label B’s measurements as C’s measurements.

Keep submission acceptance and sequence completion as separate records. Inspect the documented overflow status through one serialized owner; a stale flag or racing writer makes attribution ambiguous. Design the refill policy from accepted writes and completed sequences, rather than treating an interrupt count as a direct hardware occupancy register.

A deliberate overflow test belongs in a software model or controlled development fixture. It is unnecessary to expose a production acquisition to an untracked extra context merely to prove that the flag exists.

Decide what happens after B finishes

ADC_CFGR.JQM changes the drain behavior. With JQM = 1, completing the final queued context leaves no active queued acquisition, and subsequent hardware injected triggers are ignored until another context is written. With JQM = 0, the last context remains available for further valid triggers.

These choices imply different application promises. A finite A/B measurement transaction can use an explicit empty-after-drain contract. A repeating background measurement may deliberately retain B. The consumer must know whether another B result is expected repetition or evidence that a new request was never accepted.

RM0440 also warns about resynchronization when a newly written context applies immediately. A trigger very close to that write can still launch the previous context. Gate the trigger source around that transition according to a reviewed timing procedure; the manual does not supply a universal software delay that makes every trigger arrangement safe.

Make reconfiguration and acceptance observable

The LL guide permits changing the queue-mode setting only when neither regular nor injected conversions are ongoing. Changing JQDIS flushes the queued contexts and clears JSQR. Treat this as a configuration transition that invalidates pending software requests, rather than an ordinary update preserving the work list.

A proposed register-model fixture should record complete accepted contexts, rejected submissions, active context and sequence-end events. Check A/B/C overflow, both drain policies, and an immediate-context replacement with the trigger deliberately inhibited. Then qualify the real firmware’s initialization, trigger routing and completion handling separately.

No ADC conversions were executed here. The acceptance artifact is a trace in which each intended acquisition has one complete submission, every rejected write is accounted for, and returned samples retain the identity of the context that actually ran.