BMD-300 EvK with ublox BMD-360 module and nRF52811 power off consumption higher than expected

Hello I'm trying to get the lower consumption with this EvK in power off mode. I was expecting around 0.5uA but the minimum I get is 1.8uA ~ 2uA.

The measure has been done with a nRF Power Profiler and an SMU Keithley 2450.

I've used the "ram_retention" example. (nRF5_SDK_17.1.0_ddde560) but modifying the main function to go directly to power off mode:

int main(void)
{
    bsp_board_init(BSP_INIT_LEDS);

    bsp_board_led_on(READY_PIN_NUMBER);
    nrf_delay_ms(1000);
    
    // Enter System OFF and wait for wake up from GPIO detect signal.
    NRF_POWER->SYSTEMOFF = 0x1;
    // Use data synchronization barrier and a delay to ensure that no failure
    // indication occurs before System OFF is actually entered.
    __DSB();
    __NOP();

    // This code will only be reached if System OFF did not work and will trigger a hard-fault which will
    // be handled in HardFault_Handler(). If wake the up condition is already active while System OFF is triggered,
    // then the system will go to System OFF and wake up immediately with a System RESET.
    display_failure();
}

I've tested using Keil uVision, without softdevice using these ROM, RAM addresses and directives :

  • IROM1: Start: 0x0 / Size: 0x30000  //  IRAM1: Start: 0x20000000 / Size: 0x6000
  • BOARD_PCA10040 BSP_DEFINES_ONLY CONFIG_GPIO_AS_PINRESET FLOAT_ABI_SOFT NRF52 NRF52811_XXAA NRF52_PAN_74 __HEAP_SIZE=8192 __STACK_SIZE=8192
  •  --cpreproc_opts=-DBOARD_PCA10040,-DBSP_DEFINES_ONLY,-DCONFIG_GPIO_AS_PINRESET,-DFLOAT_ABI_SOFT,-DNRF52,-DNRF52811_XXAA,-DNRF52_PAN_74,-D__HEAP_SIZE=8192,-D__STACK_SIZE=8192

I've also tested with a softdevice (s112 - 7.2.0) using these ROM, RAM addresses and directives :

  • IROM1: Start: 0x19000 / Size: 0x17000 //  IRAM1: Start: 0x20001A50 / Size: 0x45B0
  • BOARD_PCA10040 BSP_DEFINES_ONLY CONFIG_GPIO_AS_PINRESET FLOAT_ABI_SOFT NRF52 NRF52811_XXAA NRF52_PAN_74 NRF_SD_BLE_API_VERSION=7 S112 SOFTDEVICE_PRESENT __HEAP_SIZE=2048 __STACK_SIZE=2048
  •  --cpreproc_opts=-DBOARD_PCA10040,-DBSP_DEFINES_ONLY,-DCONFIG_GPIO_AS_PINRESET,-DFLOAT_ABI_SOFT,-DNRF52,-DNRF52811_XXAA,-DNRF52_PAN_74,-D__HEAP_SIZE=2048,-D__STACK_SIZE=2048

Here some screenshots from the Power Profiler Kit:

  

Thanks in advance Slight smile

Parents
  • Hi,

    Can you flash the unmodified pwr_mgmt example instead, and schedule System Off by pressing button 1. What do you measure now?

    regards

    Jared 

  • Hello Jared,

    Thanks for your answer.

    I loaded the pwr_mgmt example code on the nRF52811 and the OFF mode current is ~300nA at VIO = 3V, which shows that the hardware may not be the problem.

    However when loading the nRF with my actual code, which is based on the ble_peripheral\ble_app_template code with an added custom profile, I measure the idle current (between the BLE connection intervals) to be ~5uA, which is higher than the 1.1uA that I should be able to obtain considering the data simulated in the Nordic Power Profiler (devzone.nordicsemi.com/.../online-power-profiler-for-bluetooth-le)

    Would sharing the sdk_config.h file help to find what could lead to this excessive consumption ?

    Thanks in advance Slight smile

    Best regards

  • Hi there,

    Sorry for the late reply.

    Do you perhaps have the example available with another IDE such as Segger SES? I'm having difficulty running it with the latest Keil µvision for some reason. I'll try to solve this but in the meantime it would be great if you could either provide the pre compiled hex so that I can flash a DK with the fw.

    Either way, there isn't really anything such as a peripheral that uses 5 µA. The excess current could for example be due to your measurement setup. Could provide a plot that shows the current?

    regards

    Jared

  • Hi Jared,

    Sorry I do not have Segger SES installed and I don't know how to do the porting from the Keil project to it...

    Did you manage to compile the code with Keil ?

    Best regards

  • Hi again Jared,

    BTW we have now received our board and the problem is somehow different on this one:

    • u-blox BMD-360 EVK: the leakage is ~5 µA whatever the power supply voltage (tested at 1.8V and 3.0V)

    • On our PCb the leakage is ~8µA at 1.8V and ~16µA at 3.0V, which make me think of a resistive leakage of ~250 kOhm, but I disconnected every connections between the BMD-360 module and the rest of the board. The module power supply is also isolated from the rest of the board

    The further I get, the more confused I am ;)

    Does that remind you of something you know ?

    Thanks in advance.

    Best regards

  • Hi there,

    I discussed your plots along with my own measurements with a colleague, and we suspect that the extra current might be consumed by the peripheral power domain.

    In short, you can try 2 things:

    1. Disable UART by setting NRF_LOG_ENABLED = 0 in your sdk_config.h file.
    2. Modify the code in main.c so that it uses GPIO PORT event instead of GPIO IN_EVENT. See this thread.

    Enabling logging or using GPIO IN_EVENT will turn on the peripheral power domain which seems to be consuming the extra current. Could you try to implement these suggestions?

    regards

    Jared 

  • Hello Jared,

    Sorry for the late answer I was on holidays.

    I finally had the opportunity to test your solution and it does work ! I have now decreased the idle consumption below 1µA, which is great as it leads to a connection interval happening every 7.5 seconds (high slave latency). Thank you so much !

    BTW both UART debug and IN_EVENT must be disabled for the peripheral power domain to be switched off, which makes sense.

    I checked and the MCU does wake up with .hi_accuracy set to false so it seems to be going well.

    Thanks a lot !

    Best regards

    Eric

Reply
  • Hello Jared,

    Sorry for the late answer I was on holidays.

    I finally had the opportunity to test your solution and it does work ! I have now decreased the idle consumption below 1µA, which is great as it leads to a connection interval happening every 7.5 seconds (high slave latency). Thank you so much !

    BTW both UART debug and IN_EVENT must be disabled for the peripheral power domain to be switched off, which makes sense.

    I checked and the MCU does wake up with .hi_accuracy set to false so it seems to be going well.

    Thanks a lot !

    Best regards

    Eric

Children
No Data
Related