Rigado BMD-340 - NRF52840 sleep current

RE: Rigado BMD-340 - NRF52840 sleep current

Simonr — Thu, 19 Sep 2019 09:20:29 GMT

Ok, 950uA in sleep mode is way too high. Do you disable all the peripherals before going to sleep? It might seem like the UART is still running from looking at your main loop, please make sure you uninitialize this and any other peripherals you're not going to use while in sleep mode. Also, I suggest you test the application on the DK to confirm/dismiss any suspicion of current leakages as soon as possible.

Best regards,

Simon

RE: Rigado BMD-340 - NRF52840 sleep current

VECA_LV — Wed, 18 Sep 2019 13:42:29 GMT

Hi Simon, yes we have a DK and plan to run the application on it to compare power consumption

The current is measured with a true RMS amperemeter, in series with the batteries. We have clear steady-state situations, where the device is awake (drawing 7.5 mA) and in sleep mode (950 uA)

RE: Rigado BMD-340 - NRF52840 sleep current

Simonr — Wed, 18 Sep 2019 08:25:55 GMT

Do you have a DK available? You could flash the application to the DK and measure the current to see if it yields a similar result to what your custom chip is, to see if this is hardware or software-related. You can see how to measure current consumption on a DK in the DK user guide (chapter 9).

Also, how are you measuring the current on your device? Are you using the PPK, a power analyzer, or something else?

Best regards,

Simon

RE: Rigado BMD-340 - NRF52840 sleep current

VECA_LV — Tue, 17 Sep 2019 18:36:23 GMT

Hi Simon,

I checked the guide already, without major improvements

In the mainloop, we have:

// Enter main loop.
    while (true)
    {
      thread_instance_init();

      initUdpListenSocket();
      open_udp_socket();
      
      while(1)
      {
        nrf_drv_wdt_channel_feed(wdt_chan);
  
        if ( nus_sent == 1 )
        {
          NRF_LOG_INFO("Sending nus data" );
          nus_data_send(msgbuff+8, (uint16_t )datalength);
          nus_sent = 0;
        }
  
        if (NRF_LOG_PROCESS() == false  && !otTaskletsArePending(thread_ot_instance_get()))
        {
          thread_sleep();
        }

        thread_process();
        
        app_sched_execute();
        power_manage(); 
        
      }

      thread_instance_finalize();
    
  }

To disable thread, I comment out call to thread init and process.

Is there anything else that we can do?

RE: Rigado BMD-340 - NRF52840 sleep current

VECA_LV — Tue, 17 Sep 2019 18:27:04 GMT

I ran our board with an empty firmware running for(;;){__WFE();}

The power consumption shows 450mA, which should be a hardware leak. The plan is to further reduce the number of components and check if there is some further drop possible

RE: Rigado BMD-340 - NRF52840 sleep current

Nguyen Hoan Hoang — Sun, 01 Sep 2019 04:00:44 GMT

The first thing you need to do before trying to optimize your firmware for power is to actually validate your hardware leakage. This is done with an empty firmware running a __WFE() in a while loop. It must run without a debugger connect to it. If this is more than 5uA, you have hardware leaking some where. Next step after is to find out which by turn off io devices one by one. There is no point trying to optimize the firmware code if you don't know your hardware power profile.

RE: Rigado BMD-340 - NRF52840 sleep current

Simonr — Fri, 30 Aug 2019 08:34:11 GMT

I asked one of our Thread experts if there were any issues like this, and he says that in sleep with no TX/RX peaks, the current will stay below 5uA, so there should not be any issues with OpenThread in the 3.0.0 version of the Zigbee and Thread SDK.

How are you measuring the current of your device? You can check out this guide for just about any way to reduce current consumption as well. Could you also show me what you do to disable/enable OpenThread?

Best regards,

Simon

RE: Rigado BMD-340 - NRF52840 sleep current

VECA_LV — Thu, 29 Aug 2019 10:15:43 GMT

In our application, we are running Openthread. Disabling the Openthread messaging, the current consumption drops from 1mA to a value around 500uA. Reading through this link, there have been issues on low power consumption with Openthread in the past, but should be solved with the newer openthread libraries. What we see is 1 mA of current consumption when openthread is enabled. Disabling drops this to 500uA. The libraries we are using is one of the latest (3.0.0). Unless there have been more issues related to Openthread and low power sleep current? Any input welcome

RE: Rigado BMD-340 - NRF52840 sleep current

Simonr — Wed, 28 Aug 2019 12:25:35 GMT

Please add a loop after calling SYSTEM OFF. Something like this should do the trick.

int main(void)
{
NRF_POWER->SYSTEMOFF = 1;

for(;;){__WFE();}
}

Best regards,

Simon

RE: Rigado BMD-340 - NRF52840 sleep current

VECA_LV — Wed, 28 Aug 2019 12:22:43 GMT

Second question: when the NRF52 is running in sleep, I get around 1.3mA of current drawn. Disabling SAADC lowers this value to 1.1 mA. Disbaling all UARTS, you would expect the device to drop the power consumption significantly. We only get it down to 950uA. We disbaled in the above sdk_config all NRF_LOG entries and disabled al UART channels. Any idea how to debug this further? Any inputs welcome...

RE: Rigado BMD-340 - NRF52840 sleep current

VECA_LV — Wed, 28 Aug 2019 12:06:12 GMT

I turned off logging, without effects on the current drawn.

RE: Rigado BMD-340 - NRF52840 sleep current

Turbo J — Thu, 22 Aug 2019 15:12:30 GMT

The UART is enabled as NRF_LOG backand, and this triggers the HF clock being permanently turned ON. If you don't need UART logging, you can safely turn the UART support off.