with Arduino IDE, can the Seeed nRF52840 sense really consume less than 1mA when sleeping?

I struggle with my experimental project of breath and apnea detection. It works except that I cannot reduce the poser consumption bellow 1mA when powered on battery, despite trying to cut all unnecessary components.
The program sleeps every 100ms, and wakes up by RTC2 to read IMU and trigger actions. I cannot use system_off as I need to keep RAM. I need only the IMU, and some digital and analog pins. I tried multiple code  combinations to reduce significantly power usage. None works. I use the ‘non mbed ‘ version of the seeed core for nRF 52840 on Arduino IDE.

So, I wonder if this is due to this 'arduino’ setup , and if some libraires included by default activate unused modules,  evenj when I cut them , or if I make something wrong.

Past experiences on minimum current usage with this environnement would be super nice.


My project is on github (https://github.com/midibody/BreathTracker).

Note that I finally removed the code of functions that disable features before sleeping as they have only a marginal effet.

Parents
  • Hello,

    Even though you can’t use System OFF in your final application, it may still be worth trying to measure with your application and HW. This can help rule out other potential issues in the setup, such as leakage from external circuitry like the IMU, etc. I don’t have experience with the Arduino implementation you’re using, but if the floor current is around ~1 mA in sleep, that at least tells us the chip has correctly entered System ON idle. But there may still be a peripheral requesting the HF clock, or something being driven by the GPIOs that prevents you from getting in the 2-3 uA range.

    Best regards,

    Vidar

  • A big thank you Vidar for your advice,

    I investigated the issue further and found that the Seeed Arduino core for the nRF52840 uses FreeRTOS, and that the IMU library provided for this board (Seeed LSM6DS3) indirectly pulls in dependencies (Wire, system services, RTOS infrastructure) that result in additional FreeRTOS tasks being created.

    In particular, when the IMU library is used, or when Serial (USB CDC) is enabled, a USBD-related FreeRTOS thread is created, which keeps HFCLK running and prevents the system from reaching low-power idle states.

    By removing all calls to the IMU library and not using Serial, the USBD thread is not created, and I measure around 800 µA, versus ~3 mA when using the IMU library or USB Serial.

    After multiple additional investigations (attempting to suspend the USBD task via the scheduler and manually disabling USB registers), my conclusion is that with the current Seeed Arduino IMU/USB stack, it is not possible to fully benefit from the low-power capabilities of the nRF52840, mainly due to HFCLK being required by background RTOS/USB components.

    One possible option would be to replace the Seeed IMU library with a minimal custom driver, avoid Wire.h, and interface directly with TWIM in bare-metal style, ensuring that no USB- or RTOS-related services are pulled in.

    Another alternative would be to move to a Nordic-native environment (nrfx / nRF5 SDK / nRF Connect SDK) instead of the Arduino core, although this represents a significant additional effort.

    If readers have experience on this topic, happy to get advises on the best / simplest option Slight smile

    **********************************************************************
    For info, the threads running on Arduino/Seeed environment:


    Name     State    Prio
    loop     X          1
    IDLE     R          0
    Callbac  B          2
    usbd     B          3
    Tmr Svc  B          2

Reply
  • A big thank you Vidar for your advice,

    I investigated the issue further and found that the Seeed Arduino core for the nRF52840 uses FreeRTOS, and that the IMU library provided for this board (Seeed LSM6DS3) indirectly pulls in dependencies (Wire, system services, RTOS infrastructure) that result in additional FreeRTOS tasks being created.

    In particular, when the IMU library is used, or when Serial (USB CDC) is enabled, a USBD-related FreeRTOS thread is created, which keeps HFCLK running and prevents the system from reaching low-power idle states.

    By removing all calls to the IMU library and not using Serial, the USBD thread is not created, and I measure around 800 µA, versus ~3 mA when using the IMU library or USB Serial.

    After multiple additional investigations (attempting to suspend the USBD task via the scheduler and manually disabling USB registers), my conclusion is that with the current Seeed Arduino IMU/USB stack, it is not possible to fully benefit from the low-power capabilities of the nRF52840, mainly due to HFCLK being required by background RTOS/USB components.

    One possible option would be to replace the Seeed IMU library with a minimal custom driver, avoid Wire.h, and interface directly with TWIM in bare-metal style, ensuring that no USB- or RTOS-related services are pulled in.

    Another alternative would be to move to a Nordic-native environment (nrfx / nRF5 SDK / nRF Connect SDK) instead of the Arduino core, although this represents a significant additional effort.

    If readers have experience on this topic, happy to get advises on the best / simplest option Slight smile

    **********************************************************************
    For info, the threads running on Arduino/Seeed environment:


    Name     State    Prio
    loop     X          1
    IDLE     R          0
    Callbac  B          2
    usbd     B          3
    Tmr Svc  B          2

Children
  • No problem. Unfortunately it is difficult for me to give more concrete advice since I am not familiar with the Arduino implementation. ~3 mA matches the system current when the CPU is active with the DCDC regulator enabled and VDD at 3 V, so this current draw could indicate that the idle thread is never allowed to run when the USB and the IMU are enabled. Did you also try measuring the power consumption after setting NRF_POWER->SYSTEMOFF= 1;?

    System current with CPU running:

    https://docs.nordicsemi.com/bundle/ps_nrf52840/page/_tmp/nrf52840/autodita/CURRENT/parameters.i_cpu.html

  • I progressed a lot, and thanks to your advise to test the current with Systemoff=1, i saw that there was still more than 1mA burned when processor was off. I identified why: i was using input VIN of the Seeed board and it uses a different power regulator, that burns power even if CPU is off. so, i switched back to V Bat and miracle: in system off, current is now around 10 uA. 
    Now, when the code is running, power usage = 1,4mA. when i switch off the Accelero /Gyro and enter into ‘sleep’ mode (WFE), it goes down to 700uA. this now look much better. 
    I will now try to shut down other stuff. 
    One issue related to power optimisation with the Seeed board is that when cutting off the IMU (LSM6DS3) before sleep, then at wake up, after turning it on, i need to wait around 50ms before accelero and gyro values are stabilized . As I wake up cpu every 100ms to measure breath, at the end , cpu has to remain active half of the time …

  • It's good to hear that you have made progress on this. Perhaps the LSM6DS3 can be configured to run in a mode that consumes let power?

    troubadour06 said:
    i need to wait around 50ms before accelero and gyro values are stabilized . As I wake up cpu every 100ms to measure breath, at the end , cpu has to remain active half of the time …

    Do you have to run the CPU in a busy wait for these 50 milliseconds while waiting for the IMU to become ready?  

  • Yes Vidar, I have configured the IMU sampling rate at a low frequency that minimises the power usage for both the Accelero and gyro. I tried a WFE While the IMU stabilises but something else in the Arduino stick keeps HFCLK on, so no real gain. and now, I’m adding snoring noise detection that uses the PDM that also requires HFCLK! therefore, low power target seems less and less realistic in my context. As this is not a commercial project, I won’t flight to death for low power, and focus on fonctionnality Slight smile

Related