STM32G474 Clock Failure Recovery: A Running Core Does Not Restore Peripheral Timing

An STM32G474 can continue executing after an HSE clock failure while a timer slows down and another peripheral loses its selected source. Clock-security fallback preserves a path for rescue software; it does not restore the application’s original timing contract.

The scope is the HSE clock security system, or CSS, in RM0440 Rev 9, section 7.2.9. LSE clock security and backup-supply behavior are excluded. The examples are a clock-tree analysis and a proposed isolated fixture, not fault injection on operating equipment.

Separate detection, fallback and acknowledgement

When enabled CSS detects an HSE failure, the manual describes automatic HSE disable, a clock-failure event toward the specified timer break and HRTIM system-fault paths, and a CSS interrupt routed to the Cortex-M4 NMI vector.

If HSE supplies the system clock directly, or supplies the PLL that provides the system clock, hardware switches the system clock to HSI16. In the latter case, the affected PLL is also disabled. Preserve that condition: a design already using an independent system source does not require the same system-clock switch merely because it also enabled HSE.

The NMI remains repeatedly active unless software clears the CSS pending condition using RCC_CICR.CSSC. Clearing it acknowledges the event. It does not restart the oscillator, relock the PLL, restore communication timing or establish the required output state.

A rescue handler should therefore record the fault and follow the product’s bounded recovery policy. Avoid a log path that assumes the failed clock remains available; a blocking peripheral operation can be unsuitable precisely when the system needs fault reporting.

Trace each consumer through its selected source

Construct a hypothetical pre-fault tree with HSE feeding an 80 MHz system PLL, AHB division by one and APB1 division by one. A TIM3 counter with prescaler zero and ARR = 7999 has an 8000-clock up-counting period:

before failure: 8000 / 80000000 = 100 microseconds
fallback case:  8000 / 16000000 = 500 microseconds

This post-fault arithmetic assumes those dividers and timer settings remain unchanged and software has not yet reconfigured the tree. Section 7.2.13 states that an APB prescaler of one gives the timer the APB-domain frequency; other APB divisions require the documented doubled timer-clock rule.

The example does not assert that a real board had an exact 80 MHz clock or that every timer always becomes 16 MHz. It shows how unchanged timer counts can represent different elapsed time after the system source changes.

Now add two different consumers. A USART1 kernel deliberately selected from HSI16 does not inherit the 80-to-16 MHz source ratio above. An FDCAN kernel selected from HSE loses that selected source when HSE is disabled; CSS does not automatically reselect its kernel mux to HSI16. RCC_CCIPR documents these independent source choices.

Even an independently clocked UART still depends on software service, buffers and the rest of the system. A stable kernel source is useful evidence, but it does not guarantee uninterrupted application communication through an NMI or recovery transition.

Keep output protection distinct from timing restoration

The CSS event is routed toward the documented break inputs of TIM1, TIM8, TIM20 and TIM15/16/17, and toward hrtim_sys_flt. That routing must be interpreted with the selected output configuration and external circuitry. The continued execution of a diagnostic task cannot establish that a power-stage output reached its required electrical state.

This article does not redesign that protection chain or recommend automatic rearming. Its clock-recovery boundary is narrower: leave consequential outputs under the product’s approved inhibited-state policy while clock and peripheral assumptions are unresolved.

Use separate milestones for event acknowledgement, source health, PLL readiness, selected system source, peripheral timing reconfiguration and authorization to resume the application. Combining them into one Boolean called “clock recovered” hides which prerequisite is still missing.

Prepare a recovery acceptance trace

Before any hardware exercise, review the post-fault clock paths on paper. For each active peripheral, mark whether its source changes frequency, disappears or remains independently available. Include timer-derived timeouts and software timekeeping that consume the changed tree.

Only an approved, isolated bench fixture should induce a clock failure, with operational loads disconnected and an appropriate recovery method. Proposed observations include the CSS indication, actual selected system source, an inert timer period and the state of separately clocked interfaces. Do not infer those observations from a CPU-frequency variable that was never updated.

A later attempt to return to HSE needs verified oscillator readiness, valid PLL configuration and lock, legal clock-transition sequencing, and refreshed peripheral assumptions. Clearing CSSC is just one earlier step. No such recovery sequence was executed here; the deliverable is a per-consumer explanation of what the hardware fallback preserves and what the application must re-establish.