Zephyr nrfx Watchdog Channels: Hardware Channel IDs Do Not Create Independent Timeout Windows

Two workers with different monitoring deadlines cannot automatically obtain independent hardware timeout durations by installing two nrfx watchdog channels. In Zephyr v4.4.0, this driver keeps one timeout value for the instance. A later installation requesting a different maximum is rejected before another channel is allocated.

The consequence is an architecture decision: determine whether the requirement needs separate software deadlines or genuinely independent hardware timeout windows. Merely counting available channel IDs does not answer that question. This article examines the tagged nrfx watchdog driver; it does not enable a watchdog or test any reset behavior.

Identify which watchdog API owns the deadline

wdt_install_timeout() belongs to the hardware watchdog API. Its configuration includes window.min, window.max, flags and an optional callback. A successful return is a nonnegative channel ID used by later hardware-feed calls.

task_wdt_add() belongs to a separate service. The v4.4.0 task-watchdog implementation stores a per-channel reload period and an absolute deadline, scheduling a shared kernel timer around pending deadlines. Optional hardware fallback is another layer. Those software channel IDs are not interchangeable with IDs returned by the hardware driver’s installation function.

This distinction does not make software supervision equivalent to independent hardware timers. Its execution, timing and fallback coverage need their own qualification. The present question comes earlier: does the selected hardware API represent the requested timeout plan at all?

Trace a mismatched installation before counting free channels

Assume the first installation succeeds with a supported maximum of 250 milliseconds, zero minimum and WDT_FLAG_RESET_SOC. The driver stores that maximum in m_timeout. Suppose a second worker requests 1,000 milliseconds on the same device, with otherwise supported settings.

The second call compares its window.max with the stored value and returns -EINVAL because they differ. It reaches that decision before nrfx_wdt_channel_alloc(). An unused hardware channel therefore does not resolve the incompatible-window request.

Reversing the installation order does not represent both deadlines either. The first successful allocation establishes a different common value, and the second unequal request still fails. Selecting an order that makes one worker happy only changes which requirement remains unrepresented.

The example assumes successful initial allocation. The source writes the first timeout value before calling the lower-level channel allocator; it does not provide a general transactional rollback guarantee for exceptional allocation failures. Preserve actual return values instead of inferring a completely unchanged device from any failed setup step.

Reject incomplete monitoring coverage before global setup

The hardware API contract requires installation before wdt_setup(). In this driver, setup passes the one stored m_timeout as the hardware reload value and then enables the instance. A returned installation ID alone therefore does not mean the watchdog is already running.

Build the intended channel plan first and check every result. Accept channel_id >= 0, not only zero. Save the actual ID for its owner; never use a negative error value as a channel or overwrite every successful ID with a default zero.

If the second required installation failed, calling global setup for the first does not silently create the missing coverage. The application needs an explicit initialization-failure policy. This article does not prescribe continuing a product with only part of its required supervision active.

The source also distinguishes feeding an installed but not-yet-enabled channel: that call returns -EAGAIN. Installation after enable returns -EBUSY. These state checks answer different questions from whether the requested timeout is compatible.

Do not collapse every failure into insufficient channels

A nonzero window.min is rejected with -EINVAL by this driver. An invalid first maximum also produces that error. Unsupported flags return -ENOTSUP, while exhausted channel allocation is reported as -ENOMEM. Record the configuration and installation state alongside the result.

Do not invent one fixed channel count for every Nordic target. Use the linked hardware capability and actual allocation result. Likewise, this installation analysis does not establish how channel feeds combine inside every device, or claim that feeding one channel refreshes every other obligation.

If different software deadlines are required, review the task-watchdog service or another supported monitoring design against those requirements. If independently timed hardware supervision is required, verify hardware that actually provides it. Changing both workers to an arbitrary common maximum merely to make installation pass is not evidence that their detection requirements remain satisfied.

Treat reconfiguration as a supported lifecycle question

Do not assume an enabled instance can be stopped, rebuilt and restarted whenever a new deadline appears. The nrfx disable implementation is conditional on NRFX_WDT_HAS_STOP; its unsupported branch returns -EPERM. The generic API also warns that restart after disable is not universally supported.

A proposed mocked installation matrix should cover equal supported maxima, unequal maxima, nonzero minimum, exhausted capacity and installation after enable. Verify the returned IDs and whether the lower-level allocation point was reached. No such fixture was executed here.

The deliverable is a pre-enable compatibility decision: the proposed obligations either fit this driver’s single hardware timeout, or require a different qualified monitoring arrangement. No watchdog was fed, disabled or allowed to reset equipment, and no timeout accuracy or recovery guarantee is claimed.