Common mistakes

Informative

Pitfalls when using the MCU driver, and how to avoid them. Each maps to a rule in Mcu — Requirements or an error in Errors.

  • Passing a real pointer to Mcu_Init. configPtr MUST be NULL_PTR — a non-null pointer raises MCU_DEVERR_PARAM_POINTER (CHI-MCU-MUST-02). The configuration is selected at build time.

  • Using the clock before it is distributed. Mcu_InitClock returns before the clock is stable. Poll Mcu_PollFunction and wait for Mcu_IsClockDistributed to return TRUE before starting clock-dependent drivers (CHI-MCU-MUST-05, CHI-MCU-MUST-06).

  • Busy-waiting for stabilisation yourself. Do not spin on a HW status register — that work belongs to Mcu_PollFunction; the driver is designed to never block in Mcu_InitClock (CHI-MCU-MUST-05).

  • Forgetting to call Mcu_PollFunction. Without it, clocks never distribute and any configured clock supervision never runs (CHI-MCU-MUST-07).

  • Reading the reset reason live from hardware. The cause is captured once by Mcu_Init and the HW register is then cleared; always read it via Mcu_GetResetRawValue (CHI-MCU-MUST-03, CHI-MCU-MUST-09). Called before Mcu_Init it returns 0.

  • Calling Mcu_PerformReset with interrupts enabled. The caller must guarantee no preemption during the reset sequence — disable interrupts first (CHI-MCU-MUST-10).

  • Expecting a de-init. The McuDrv has no de-initialization; it is brought up once, early in boot.

  • Assuming every reset bit exists. A vendor omits reset reasons the hardware cannot detect, and hardware without any detection reports MCU_RESET_POWER_ON (CHI-MCU-SHOULD-01). Mask for the bits you care about.