Common mistakes

Informative

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

  • Passing a real pointer to Wdg_Init. configPtr MUST be NULL_PTR — a non-null pointer raises WDG_DEVERR_PARAM_POINTER (CHI-WDG-MUST-04). The configuration is selected at build time.

  • Calling a service before Wdg_Init (or initializing twice). Both raise WDG_DEVERR_DRIVER_STATE (CHI-WDG-MUST-06).

  • Exceeding maximum_timeout. Wdg_UpdateTimeout rejects a value above the configured maximum for the current mode with WDG_DEVERR_PARAM_TIMEOUT (CHI-WDG-MUST-06). Note that timeout = 0 is valid and forces a near-immediate reset.

  • Forgetting that Wdg_SetMode resets the timeout. Switching mode applies the new mode’s default timeout — refresh it with Wdg_UpdateTimeout afterwards if you need a different one (CHI-WDG-MUST-05).

  • Expecting Wdg_FeedHw to matter in the direct strategy. Wdg_FeedHw is only used by the logical strategy; with direct management you refresh via Wdg_UpdateTimeout and never call Wdg_FeedHw (CHI-WDG-MUST-01, CHI-WDG-SHOULD-02).

  • Assuming the driver runs its own timer. For the logical strategy the upper layer owns the periodic timer and calls Wdg_FeedHw; the WdgDrv does not set up timer hardware (CHI-WDG-SHOULD-02).

  • Racing Wdg_SetMode and Wdg_FeedHw on an external watchdog. Where both issue bus transactions (e.g. over SPI with no queue) they can conflict; the implementation must serialise them (CHI-WDG-MUST-03).

  • Trying to turn the watchdog off with a de-init. There is none — use WDG_MODE_OFF where the hardware supports it.