nRF54L10 with watchdog

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
  • 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

  • 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 ?

  • 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

  • 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.

  • 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

Related