Best practice to poweroff an nrf52840 that's using BLE?

We are developing a device that uses BLE, 4 contacts (buttons), a piezo connected via PWM and a realtime clock (RV3028).  It also stores event data on an external flash using LFS.

We've been using the nrf52840dk and have also started using a Xiao BLE nrf52840 as that will likely be the module we use for production.

Using a PPK and after a sys_poweroff(), the current draw floats around 550uA.  This seemed very high so we started isolating what was drawing so much power.  The first attempt was the flash as this seems to be a problem for a lot of people.  Using just flash and some tweaks got the consumption down to 20uA @ 3.3V and ~7nA(!?) @ 3.0V!  That seemed much more reasonable.  Same for PWM - enabling "zephyr,pm-device-runtime-auto" and CONFIG_PM_DEVICE=y also significantly reduced overall current.

Re-adding bluetooth seemed to be the culprit and running some of the samples seem to have the same issue when adding sys_poweroff().  Everything still floats at around 500uA.

So, what's the best way to ensure bluetooth is not drawing current after sys_poweroff()?

... or am I going down the wrong path?

Thanks in advance!

Parents
  • Hello,

    Sorry for the delayed response.

    Using a PPK and after a sys_poweroff(), the current draw floats around 550uA.  This seemed very high so we started isolating what was drawing so much power. 

    GPIO configurations are retained in System OFF mode. Therefore, when seeing higher than expected current in this state, it's usually due to a pin configuration issue or an external circuit. I suggest placing a breakpoint at sys_poweroff() and checking the GPIO registers to ensure all pin configurations are correct.

    Using just flash and some tweaks got the consumption down to 20uA @ 3.3V and ~7nA(!?) @ 3.0V

    It would be great if we could advertise a sleep current of only 7 nA, but that value is too low to be valid, unfortunately. Typical range is between .8 to 1.86 uA according the product specification (note: RAM retention in system OFF is not enabled by default). Are you using the PPK in ammeter or power source mode?

    Ref. (https://docs.nordicsemi.com/bundle/ps_nrf52840/page/_tmp/nrf52840/autodita/CURRENT/parameters.i_sleep.html )

    Re-adding bluetooth seemed to be the culprit and running some of the samples seem to have the same issue when adding sys_poweroff().  Everything still floats at around 500uA.

    So, what's the best way to ensure bluetooth is not drawing current after sys_poweroff()?

    It seems strange that enabling Bluetooth consistently leads to a higher system OFF current. Does your design include a front end module (PA/LNA) by any chance? 

    Best regards,

    Vidar

Reply
  • Hello,

    Sorry for the delayed response.

    Using a PPK and after a sys_poweroff(), the current draw floats around 550uA.  This seemed very high so we started isolating what was drawing so much power. 

    GPIO configurations are retained in System OFF mode. Therefore, when seeing higher than expected current in this state, it's usually due to a pin configuration issue or an external circuit. I suggest placing a breakpoint at sys_poweroff() and checking the GPIO registers to ensure all pin configurations are correct.

    Using just flash and some tweaks got the consumption down to 20uA @ 3.3V and ~7nA(!?) @ 3.0V

    It would be great if we could advertise a sleep current of only 7 nA, but that value is too low to be valid, unfortunately. Typical range is between .8 to 1.86 uA according the product specification (note: RAM retention in system OFF is not enabled by default). Are you using the PPK in ammeter or power source mode?

    Ref. (https://docs.nordicsemi.com/bundle/ps_nrf52840/page/_tmp/nrf52840/autodita/CURRENT/parameters.i_sleep.html )

    Re-adding bluetooth seemed to be the culprit and running some of the samples seem to have the same issue when adding sys_poweroff().  Everything still floats at around 500uA.

    So, what's the best way to ensure bluetooth is not drawing current after sys_poweroff()?

    It seems strange that enabling Bluetooth consistently leads to a higher system OFF current. Does your design include a front end module (PA/LNA) by any chance? 

    Best regards,

    Vidar

Children
No Data
Related