Maximum Reload time for WDT

RE: Maximum Reload time for WDT

Stian Røed Hafskjold — Wed, 02 Dec 2020 14:10:18 GMT

Hi, the base current is a little bit higher on 833.

I_{ON_RAMOFF_EVENT}

System ON, no RAM retention, wake on any event

1.1

µA

So 1.1 + .23 = 1.33 uA, which is the expected typical current. And yes, if you get higher (or lower) current it's because of process variation.

RE: Maximum Reload time for WDT

deknoob — Wed, 02 Dec 2020 07:24:19 GMT

Hi Stian,

I am actually using nRF52833 which doesn't have ULP mode. Best result is 1.4uA when I select LFXO. As you can see I use 1000 second WDT reload timeout, to enable longer startup time for LFXO. But I don't see variation if I wait for longer. With RC oscillator I am measuring 1.9uA.

I use NRF Power Profiler for measurement, VDD is 3V.

Is this the best I can get with 52833? Or maybe my consumption is higher because of process variation?

1.4uA is still an improvement compared to 2.3uA sleep current measured in the past when I simply use timer to wakeup and with full RAM retention

    NRF_CLOCK->LFCLKSRC = 1; // LFXO
    //NRF_CLOCK->LFRCMODE = 1; // ULP mode
    //NRF_CLOCK->LFCLKSRC            = (CLOCK_LFCLKSRC_SRC_RC << CLOCK_LFCLKSRC_SRC_Pos);

    NRF_CLOCK->TASKS_LFCLKSTART = 1; // Start LF clock
    while(!NRF_CLOCK->EVENTS_LFCLKSTARTED){
    }
    NRF_CLOCK->EVENTS_LFCLKSTARTED = 0;
    NRF_WDT->CRV = 32768000; // WDT wakeup every 100 sec
    NRF_WDT->TASKS_START = 1; // start WDT
    for(int i = 0; i < 8; i++){
        NRF_POWER->RAM[i].POWERCLR = 0x3; // Turn off RAM block 0-7
    }
    NRF_POWER->RAM[8].POWERCLR = 0x3F; // Turn off RAM block 8
    
    for(;;){
        __WFE();
    }

RE: Maximum Reload time for WDT

deknoob — Tue, 01 Dec 2020 05:18:15 GMT

That sounds so good, thank you so much for having a look at this. I will test this as soon as possible and report results.

regards

Kerim

RE: Maximum Reload time for WDT

Stian Røed Hafskjold — Mon, 30 Nov 2020 16:50:45 GMT

The WDT needs the LF clock to be running. LFRC consumes 0.3uA in ULP mode (LFXO is at 0.25uA, but requires much longer startup time)

0.97uA (sys on, no RAM) + 0.3uA = 1.27 uA. (typical value)

I did some measurements here and I actually got a bit lower; 972 nA in sleep:

In my test the WDT is resetting every 10 seconds.

The wakeup charge is 5.9uC:

This gives an additional average current of 5.9uC / 3600 sec = 1.6 nA if the WDT is resetting the chip every 1 hour. Which is of course negligible, but with more advanced initialization code, this should maybe be taken into consideration. Here is my test code:

int main(void)
{
    NRF_CLOCK->LFCLKSRC = 0; // LFRC
    NRF_CLOCK->LFRCMODE = 1; // ULP mode
    NRF_CLOCK->TASKS_LFCLKSTART = 1; // Start LF clock
    while(!NRF_CLOCK->EVENTS_LFCLKSTARTED){
    }
    NRF_CLOCK->EVENTS_LFCLKSTARTED = 0;
    NRF_WDT->CRV = 327680; // WDT wakeup every 10 sec
    NRF_WDT->TASKS_START = 1; // start WDT
    for(int i = 0; i < 8; i++){
        NRF_POWER->RAM[i].POWERCLR = 0x3; // Turn off RAM block 0-7
    }
    NRF_POWER->RAM[8].POWERCLR = 0x3F; // Turn off RAM block 8
    
    for(;;){
        __WFE();
    }
}

RE: Maximum Reload time for WDT

deknoob — Mon, 30 Nov 2020 11:12:14 GMT

Hi Kenneth,

Yes, but 0.97uA in that link sounds better than 1.5uA 🙂

- System ON, no RAM retention, wake on any event => 0.97uA

In my design, battery has to last 10 years, hence nanoamps count. And my device spends 90% of time sleeping.

Thing is that with no RAM retention only reset wakeup will work, where WDT comes handy.
You didn't answer my question, is it feasible what I propose?

Regards

Kerim

RE: Maximum Reload time for WDT

Kenneth — Mon, 30 Nov 2020 10:12:34 GMT

You can find some current consumption values listed here:
https://infocenter.nordicsemi.com/topic/ps_nrf52840/_tmp/graviton/autodita/CURRENT/parameters.i_sleep.html

The current consumption with an RTC clock (LFCLK) running can get as low as I_{ON_RAMOFF_RTC} , typical 1.5uA. That equal about 13mAh a year.

Best regards,
Kenneth

RE: Maximum Reload time for WDT

deknoob — Mon, 30 Nov 2020 09:37:35 GMT

Hi Keneth,

I also want to put device to sleep for 1 hour, but with current even lower than ~1.7uA. Please let me know if this is feasible:

- disable all peripherals except WDT
- disable interrupts
- reload WDT with 1 hour wakeup
- Power off all RAM blocks
- halt the CPU

After one hour there will be reset, right. I can't do that with wakeup every 100sec. Is that correct?

Best regards

Kerim

RE: Maximum Reload time for WDT

Kenneth — Wed, 04 Sep 2019 11:17:51 GMT

Thanks for the details RK! I have reported the WDT overflow calculation internally now. It will take some time to fix this as always, so directly writing to WDT registers as you suggest is the way to go for now.

Best regards,
Kenneth

RE: Maximum Reload time for WDT

RK — Wed, 04 Sep 2019 10:59:44 GMT

well no not really. You should read the nRF datasheet which documents the registers, if you want to set them directly it'll be something like WDT->CRV = 0x12345678. Alternatively if you check through the code for the current watchdog module, the one I took that line above from, you can take that as an example, it's short, and it uses the hardware abstraction functions like nrf_wdt_reload_value_set() to actually write the registers. This should be simple enough that just looking at that code should be enough.

RE: Maximum Reload time for WDT

Shagan — Wed, 04 Sep 2019 06:58:22 GMT

Gotcha,
Is there an official place to see how to program the registers directly to achieve this?

RE: Maximum Reload time for WDT

RK — Wed, 04 Sep 2019 06:49:04 GMT

I'd call that a bug, yes. Possibly never noticed as people tend to run the watchdog for seconds or possibly minutes and not hours.

well .. me I'd just not use the driver and program the registers directly, it's not a very complex peripheral. The hardware abstraction is nice but honestly for what you want it's what .. 20 lines of code?

I'm sure one of the Nordic guys on this thread .. well Kenneth :) will report it as a bug but I don't know if you're likely to see it fixed before you need it so I would just roll my own.

RE: Maximum Reload time for WDT

Shagan — Wed, 04 Sep 2019 06:34:50 GMT

Good catch! yes, that is exactly I think what's happening.

Is this a bug? How do we handle this then?

RE: Maximum Reload time for WDT

RK — Tue, 03 Sep 2019 10:24:11 GMT

I can't make any of this make sense. 6,000,000 ought to trigger at 183 seconds, not 100 and obviously 8,000,000 should be longer still. So my first thought is that your constant is having bits trimmed for some reason, however I can find no obvious trimming of the bits which could lead to those results.

and then I went and looked at the source code for the wdt module, here's where it sets the reload time

  nrf_wdt_reload_value_set((p_config->reload_value * 32768) / 1000);

so clearly the reload value passed to the driver is supposed to be in milliseconds (and in fact that's what the documentation says). So for your case you want one hour which is 3600 seconds which is 3,600,000 milliseconds. So that's what you want to set the reload value to if you're using the watchdog driver.

However I haven't actually convinced myself that calculation doesn't overflow badly, need to look at some assembler. I think it may do. If I multiply 6,000,000 by 32768, truncate it to 32 bits, then divide by 1000 I get 3,309,568 which would be 101 seconds. If I do that with 8,000,000 I get 4 second which is sort of close to 10 I guess. That would explain your findings.

So basically the driver wants milliseconds and I'm not actually sure it works for anything over 131,000 ms or 131 seconds because that calculation overflows in the middle.

RE: Maximum Reload time for WDT

Shagan — Tue, 03 Sep 2019 09:24:54 GMT

Hi Kenneth,

I did use the example as a reference. Please look at my comment on the previous reply. I did try using the example as a reference.

The reason why we are trying to do 1 hour, is to make sure the device indeed wakes up after 1 hour, in case the timer for 1 hour was not set right after sending data to server. I have seen some conflicts in running multiple timers at the same time. so this is just a catchall watchdog.

regards

Shankar

RE: Maximum Reload time for WDT

Shagan — Tue, 03 Sep 2019 09:22:16 GMT

Hi,

Thanks for your reply.
I used the APIs example. Didn't change the registers themselves.

void ible_watchdog_init(void)
{
  uint32_t err_code = NRF_SUCCESS;
  nrf_drv_wdt_config_t config = NRF_DRV_WDT_DEAFULT_CONFIG;
  config.reload_value = 6000000;
  err_code = nrf_drv_wdt_init(&config, wdt_event_handler);
  err_code = nrf_drv_wdt_channel_alloc(&m_channel_id);
  nrf_drv_wdt_enable();
  APP_ERROR_CHECK(err_code);
}

/**
 * "Feed" the watchdog, resets the watchdog timer.
 * This must be called after watchdog initialization or the program will reset.
 */
void ible_watchdog_feed(void)
{
  printf("feeding wdt..\n");
  nrf_drv_wdt_channel_feed(m_channel_id);
}

this 6000000 is triggering at 100 seconds. But if I try to increase it to 8000000, it triggers in like 10 seconds.
Is there an example online in using CRV register directly?

regards

Shankar

RE: Maximum Reload time for WDT

Kenneth — Tue, 03 Sep 2019 08:51:22 GMT

I am not sure what is the problem here, but there is watchdog example in the SDK that should be possible to use as reference.

As a side comment, have you done any calculation on the current consumption?

The system ON idle current with an RTC running is ~1.7uA depending on how much RAM you retain during sleep.

If you wakeup every 100 seconds for ~50us then the average increase is ~0.002uA. In other words there is no difference in battery life whether you wakeup every 100 seconds or 1hour, because the idle current is about ~1000x larger.

Best regards,
Kenneth

RE: Maximum Reload time for WDT

RK — Tue, 03 Sep 2019 01:44:40 GMT

The counter reload value can be specified up to 0xFFFFFFFF which is over 4 billion which is plenty. I suggest you debug through the watchdog code and find out what you're actually setting the CRV register to, perhaps you're truncating a value in your code.