nRF54L10 with watchdog

[omt]

When I turn on watchod current consmuption rasises about 2uA ( it is  about 50% more than without watchdog) - I want to get lowest power consumption while waiting for semaphore.

Is it possible that simple watchgod uses so much current ?

Initialziation looks like this (30sec reload):

int WatchdogInit(void)

{

int wdt_channel_id;

int err;

    WdtDev = DEVICE_DT_GET(DT_ALIAS(watchdog0));

    struct wdt_timeout_cfg wdt_config = {

        .window.min = 0U,

        .window.max = WDT_TIMEOUT_MS,

        .flags = WDT_FLAG_RESET_SOC,  

        .callback = NULL

    };

   wdt_channel_id = wdt_install_timeout(WdtDev, &wdt_config);

   wdt_setup(WdtDev, WDT_OPT_PAUSE_HALTED_BY_DBG); 

   CLR_WDT();

   return wdt_channel_id;

}

I have an external 32 kHz crystal. And current consumption without watchodg is 4.3uA

[AHaug]

Hi,

This is as I understand it expected. The hardware based watchdog will cause some increased consumption.

4.3 µA idle without WDT is reasonable for System ON idle with LFXO running and RAM retained. +2 µA for the WDT is the cost of an always-running watchdog on this part. You already have the external 32 kHz crystal running (for GRTC), so the WDT is not adding an oscillator, it is just the counter/comparator logic in the low-power domain.

The current increase you see matches the current increase from active WDT: https://docs.nordicsemi.com/r/bundle/ps_nrf54l15/page/chapters/current_consumption/doc/current_consumption.html-unique_1647170005 

Kind regards,
Andreas

[omt]

Well, runing low frequency counter and its cost 2.2uA is very expensive. WDT is nessesary in each application, LF oscylator is already running, so why it takes so much current ?

[AHaug]

Hi,

The clock is not what you are paying for. Notice IWDT0 (2.8 µA) versus IWDT1 with LFXO (2.2 µA). The 0.6 µA difference is the 32.768 kHz RC oscillator.

The 2.2 µA is the WDT peripheral's own static current. A 32 kHz down-counter is not what draw the microamps. What costs the current is that arming the WDT keeps its supervision logic and its slice of the always-on power domain biased and powered continuously, so it can guarantee a reset from any state including the deepest sleep. That always-on bias, not the toggling of the counter, is the dominant term. It is essentially fixed static current, which is why it does not depend on your 30 s timeout and does not go away while you block on the semaphore.

If 2.2 µA is unacceptable for your power budget, the only real levers are architectural, i.e to drop the hardware WDT in favor of software supervision. This will however lose protection against a fully hung CPU. On this silicon the number is a documented characteristic,

Kind regards,
Andreas

[omt]

I understand the advanced mechanisms — power domain separation, independent supervision logic, and so on — but the practical consequence is that in a typical production use case, with LFCLK and WDT enabled, we lose on current consumption compared to the nRF52. I can't imagine shipping a production device with WDT disabled.

[AHaug]

Noted, thats fair. To be honest my recommendation is to have it enabled, but it will come with the additional consumption due to how the hardware watchdog is designed on the nRF54L05/L10/L15 devices. The WDT is running on a domain that will be more aggressively powered down in sleep/idle when WDT is not running, but when you add the WDT it will force this domain to be awake and this is what causes the increase in consumption.

On the nRF52 series, the hardware watchdog was running on an already powered up domain, so adding the WDT did practically add nothing w.r.t total consumption.

Kind regards,
Andreas

[omt]

Fair point on the domain isolation rationale — though it does make me wonder about consistency. By that same logic, you could technically report "System ON: 2 µA" as the headline and leave "but you need to power the domain feeding the CPU core too, +3 µA" as a footnote in chapter 18. WDT isn't an optional add-on like a second SPI channel — it's baseline for any production-grade application, so hiding its cost outside the main comparison numbers ends up following the same pattern.

Anyway, thanks for the straight answer — genuinely appreciated

[AHaug]

Happy to help

omt said:

though it does make me wonder about consistency. By that same logic, you could technically report "System ON: 2 µA" as the headline and leave "but you need to power the domain feeding the CPU core too, +3 µA" as a footnote in chapter 18.

That's fair. In general this sentiment is repeated for all peripheral AFAIK. On the RRAM and MRAM multi-core devices (nRF54) there's a larger amount of power domains, thus higher grade of separation between peripherals depending on how they are configured.

omt said:

WDT isn't an optional add-on like a second SPI channel — it's baseline for any production-grade application, so hiding its cost outside the main comparison numbers ends up following the same pattern.

Seen from the perspective of a device in field this is absolutely a valid argument, but seeing it from a purely hardware/peripheral perspective, the hardware WDT is technically an optional peripheral for users to add on their own demand and there exists a software option (which has its own set of strengths and weaknesses).

As you say though. For basically every scenario of a production grade application this a strongly recommended (and thus as good as mandatory) feature to include.

Kind regards,
Andreas

[omt]

That's actually a really nice piece of engineering — giving each peripheral its own power domain is elegant, and I'd genuinely compliment that design choice.

The WDT case is just different, though: unlike other peripherals where usage is genuinely optional depending on the application, WDT is something every production design should enable — so the "opt-in" framing doesn't really hold in practice. And in this case, that isolation ends up being a pure loss of precious current in exactly the kind of ultra-low-power designs Nordic is targeting.

Thanks again!