High current consumption in bootloader

[a.calatroni]

Hi everyone.

In our products I am using the dfu bootloader included in the SDK 10 with very minor modifications affecting only what is advertised. Within the bootloader operation, the current consumption is around 800 uA, which wouldn't be a problem, since the chip stays there very very shortly or only during firmware updates. When control is forwarded to the main firmware though, the current consumption doesn't decrease. I imagine that this is the case because there is no real reset, but just a jump to the firmware.

Now my questions are:

1) Is this current consumption in the bootloader normal? The chip starts consuming this much current only after calling "bootloader_dfu_start()".

2) What would be the best way within the regular firmware to kind of "reset" all possible devices which could cause the current consumption? I already tried to perform a SHUTDOWN of all high-speed timers with no success.

Best regards,

Alberto

[Hung Bui]

Hi Alberto, 

 

I don't think it's normal. 800uA matches with the current consumption of HFCLK or could be device is still in debug mode. 
Have you make sure you do a power reset after you flash the device to get it out of debug mode before you do any measurement ? 

Our bootloader shouldn't let any peripheral running before switching to application. Could you try to test again with unmodified bootloader and try to do DFU update a simple firmware, such as the blinky example ? 

 

 

[a.calatroni]

Hi Hung Bui and thank you for the prompt answer.

I exclude the debug mode issue, since I always power-cycle the sensor after flashing. Then I did my homework. I reverted everything to the original SDK 10. The bootloader alone consumes around 800 uA and the device appears as DfuTarg. Then I performed a DFU sending a firmware which in the main only has the following code:

for (;;)

{

    power_manage();

}

where "power_manage" is defined as usual:

static void power_manage(void)

{

    uint32_t err_code = sd_app_evt_wait();

    APP_ERROR_CHECK(err_code);

}

I checked that the bootloader doesn't run anymore, in fact there is no device named DfuTarg anymore. The power consumption is nevertheless unaltered, like if the bootloader couldn't gently shut down things that were used.

[Hung Bui]

Hi Alberto, 

 

I'm checking here with SDK v10 and S130v1.0 and don't see that the bootloader itself consumes 800uA.

If I change the advertising interval APP_ADV_INTERVAL in dfu_transport_ble to 500ms, the current consumption is around 100uA. 

Could you try the same on our nRF51 DK to measure the current consumption ? 

I suspect there was smth else on the board you test consuming current ? SDK v10 has been out for quite a while (2-3 years) we haven't got any similar report. 

[a.calatroni]

Hi Hung Bui,

I am using the bootloader in combination with S110 actually. The board has just the Nordic chip (embedded in a SiP by InsightSiP) and nothing else - I soldered one like that just to exclude other effects. Furthermore, if I put the "power_manage" loop directly in the bootloader at an early point (right before "bootloader_dfu_start"), the board consumes some 2 uA.

I will try with the precompiled bootloader hex including S130, although it would be a bit of a problem since I use S110 for all my projects still.
I will also double-check my compilation chain and see that all files which are compiled are really the original versions from Nordic. It should be the case since I have all in a GIT repo so I reverted all the stuff ;-)

[a.calatroni]

Hi Hung Bui,

after plenty of tests I can exclude the bootloader as a source for extra current consumption. I can also exclude my custom hardware, since I get around 200uA of current also on a board where only the SoC is soldered. I need to look into my firmware further then. If I flash the HRM example with S130 to the same board with only the SoC I get around 100 uA.