STM32H750 RNG Seed Errors: Drain the Recovery Pipeline Before Returning Random Words

Clearing an STM32H750 RNG seed-error flag is only the first step of the documented recovery. The peripheral pipeline must then be drained before the application resumes normal output. A wrapper that clears the flag and immediately returns the next register value skips that boundary.

The scope here is STM32H750xB in RM0433 Rev 9, October 2026, sections 34.3.5–34.3.7, read on 19 October 2026. This is a source-derived state-machine design, not an entropy measurement, cryptographic certification or executed hardware recovery.

Separate readiness from a healthy output state

For ordinary operation, the manual requires no seed or clock interrupt error, represented by clear SEIS and CEIS, together with DRDY indicating data readiness. Readiness alone cannot authorize output when an error is present. The error-management section also warns against using data-register contents while the seed or clock current-status error is set.

The normal-read discussion includes a narrower race: a seed error can occur between polling RNG_SR and reading RNG_DR. It recommends checking that the returned value is nonzero. Incorporate that documented check in the normal-read path rather than treating a previously clean status snapshot as timeless permission.

A nonzero word is not evidence of cryptographic quality. These checks enforce the peripheral’s documented acceptance conditions; the larger system still needs its approved random-generation construction and qualification. Do not log generated words merely to demonstrate that they look varied.

Make recovery a no-output interval

For a seed error after RNG initialization, section 34.3.7 specifies this order:

enter recovery; withhold application output
clear SEIS by writing that bit to 0
read RNG_DR exactly 12 times; discard every word
confirm SEIS is still clear
return to the normal-read eligibility checks

The twelve reads are an exceptional pipeline-cleaning operation. They are not twelve successful random-number deliveries, and they are not the normal DRDY-gated read loop. A wrapper that waits for normal readiness before every discard changes the documented recovery sequence.

Keep the discard destination separate from caller-owned output. Even if one of those words appears nonzero or resembles an earlier good result, it remains recovery material and must not count toward the requested byte count. A debug or buffering layer must not accidentally publish it later.

The final check matters as much as the count. If SEIS has reasserted, recovery has not established the stated success condition. Do not return success merely because twelve reads occurred. If the flag remains clear, resume the normal eligibility checks; completion of the drain itself is not an instruction to reuse its last word.

Give one owner the recovery transition

An interrupt handler and a polling caller must not independently consume RNG_DR during this sequence. Otherwise, one context can steal discard reads, clear an error another context needs to observe, or deliver a value while the other believes output is inhibited.

Define a single peripheral owner or a serialized driver state transition appropriate to the firmware’s execution model. Record states such as normal, seed recovery, clock fault and unavailable. The exact locking mechanism depends on the RTOS and driver; this article does not prescribe an interrupt mask held across arbitrary waits.

Give repeated failures a bounded policy. If the device cannot regain an acceptable state within the product’s permitted attempts or time, return an explicit unavailable/error result. Do not silently fill the caller’s remaining buffer with counters, timestamps or stale data. Preserve the failure reason without claiming that a different-looking byte stream repairs the RNG.

Keep clock errors on their own path

A clock error uses CEIS and CECS, not the seed-recovery recipe. Section 34.3.7 directs software to correct the RNG clock configuration and then clear CEIS; CECS clears automatically when the clocking condition becomes normal.

Consequently, a twelve-read drain is not a repair for an invalid source clock. If both error classes are observed, the wrapper must preserve that combined failure rather than reporting seed recovery as overall success. Disabling the clock checker to make status appear clean would change the health-monitoring contract being relied upon.

Verify the software boundary before hardware qualification

A proposed mocked peripheral trace should count exactly twelve recovery reads, prove that none reaches the application, and require the final status check. Add a reasserted-seed-error case, a clock-error case and a normal-read zero-result case. These fixtures test control flow and output ownership; they do not simulate or validate entropy.

Record the actual device revision and compare its errata. ES0392 Rev 15, September 2025 was checked alongside this manual; no RNG-specific entry was found in that revision. That limited observation is not a promise about future errata or source quality. Hardware behavior and the product’s security requirements remain separate qualification work.