Bootloader taking higher current consumption upon power on

RE: Bootloader taking higher current consumption upon power on

Kenneth — Mon, 10 Feb 2020 12:13:06 GMT

I do not quite understand the request. I think it is a sensible recommendation to check the integrity of the firmware upon startup. I do not expect this will have any impact on the life time of the product, can you please explain why this is problematic?

Please also see my previous comment: "

I think we can conclude that it is the way it is in this case. A power cycle it not something we expect happen often, it should really only occur when replacing batteries, in which case doing a integrity check of the firmware make sense.

It could be interesting to know if you have enabled the softdevice in the bootloader and application with the same LFCLK (32kHz clock source).

RE: Bootloader taking higher current consumption upon power on

asr — Mon, 10 Feb 2020 02:49:48 GMT

Keneeth,

Do you have any other suggestions that we should try for resolving this issue. This task is marked as high priority. Please help us.

RE: Bootloader taking higher current consumption upon power on

asr — Wed, 05 Feb 2020 08:47:57 GMT

Sorry for the late response.

Today we tried creating the zip package by adding above mentioned option. But still we see the same behavior as mentioned above.

RE: Bootloader taking higher current consumption upon power on

Kenneth — Mon, 02 Dec 2019 10:54:46 GMT

Can you also try the DFU packet with NO_VALIDATION (skip CRC) for comparison?

RE: Bootloader taking higher current consumption upon power on

asr — Fri, 29 Nov 2019 04:24:23 GMT

Keneeth,

All the above power measurements that I captured in above ticket are power ON/power OFF button control that present in the nrfConnect Desktop App ( adding PPK to nrf52 DK ).

RE: Bootloader taking higher current consumption upon power on

Kenneth — Thu, 28 Nov 2019 14:44:17 GMT

I notice above that you sometimes do a software reset, and in other cases do a power on reset. If you try a power on reset for all cases, do you measure a difference then?

RE: Bootloader taking higher current consumption upon power on

asr — Thu, 28 Nov 2019 04:54:53 GMT

Hi Kenneth,

Yes, we enabled same clock source in both the BootLoader and Application.

we got some progress on this issue. we noticed one Preprocessor (define symbols) difference between the two projects (bootloader & Application) i.e CONFIG_NFCT_PINS_AS_GPIOS.

a) After flashing this newly built bootloader image( softdevice + bootloader) 300ms @ 7mA current issue got resolved. Below is the screenshot ( Application not flashed yet)

nrfjprog -f nrf52 –eraseall

mergehex -m secure_bootloader_ble_s132.hex s132_nrf52_6.1.1_softdevice.hex -o BLSD.hex

nrfjprog --family nrf52 --program BLSD.hex --verify --reset

b) Now we flashed application image using nrf Toolbox -> DFU ( file selected *.zip). Command we used for generating application *.zip file

nrfutil pkg generate --application BTM_BT_uC_Firmware.hex --application-version 1 --hw-version 52 --sd-req 0xB7 --key-file my_secret_private_key.pem BTM_BT_uC_Firmware.zip

After powercycle the nrf52 DK and capture the current consumption using PPK, issue is noticed again.

c) Now we erased entire flash chip and flashed softdevice & Application using following commands

nrfjprog -f nrf52 --eraseall
nrfjprog -f nrf52 --program s132_nrf52_6.1.1_softdevice.hex --sectorerase

nrfjprog -f nrf52 --program BTM_BT_uC_Firmware.hex --sectorerase --verify --reset
nrfjprog -f nrf52 --reset

after flashing softdevice I downloaded application alone to verify that 300ms @7.6mA current drawing is triggering or not.

I am trying to fix the issue with above steps a & b. Please guide me how i can resolve this issue. Is there any parameters are getting overwritten while flashing the application on top of softdevice + bootloder.

Here are the contents of the icf files.

a) Bootloader icf file contents

/*###ICF### Section handled by ICF editor, don't touch! ****/
/*-Editor annotation file-*/
/* IcfEditorFile="$TOOLKIT_DIR$\config\ide\IcfEditor\cortex_v1_0.xml" */
/*-Specials-*/
define symbol __ICFEDIT_intvec_start__ = 0x78000;
/*-Memory Regions-*/
define symbol __ICFEDIT_region_ROM_start__ = 0x78000;
define symbol __ICFEDIT_region_ROM_end__ = 0x7dfff;
define symbol __ICFEDIT_region_RAM_start__ = 0x200057b8;
define symbol __ICFEDIT_region_RAM_end__ = 0x2000ffff;
export symbol __ICFEDIT_region_RAM_start__;
export symbol __ICFEDIT_region_RAM_end__;
/*-Sizes-*/
define symbol __ICFEDIT_size_cstack__ = 2048;
define symbol __ICFEDIT_size_heap__ = 0;
/**** End of ICF editor section. ###ICF###*/

define memory mem with size = 4G;
define region ROM_region = mem:[from __ICFEDIT_region_ROM_start__ to __ICFEDIT_region_ROM_end__];
define region RAM_region = mem:[from __ICFEDIT_region_RAM_start__ to __ICFEDIT_region_RAM_end__];

define symbol __region_uicr_bootloader_start_address_start = 0x00000FF8;
define symbol __region_uicr_bootloader_start_address_length = 0x4;
define symbol __start_uicr_bootloader_start_address = __region_uicr_bootloader_start_address_start;
define symbol __stop_uicr_bootloader_start_address = __region_uicr_bootloader_start_address_start + __region_uicr_bootloader_start_address_length;
export symbol __start_uicr_bootloader_start_address;
export symbol __stop_uicr_bootloader_start_address;
define symbol __region_uicr_mbr_params_page_start = 0x00000FFC;
define symbol __region_uicr_mbr_params_page_length = 0x4;
define symbol __start_uicr_mbr_params_page = __region_uicr_mbr_params_page_start;
define symbol __stop_uicr_mbr_params_page = __region_uicr_mbr_params_page_start + __region_uicr_mbr_params_page_length;
export symbol __start_uicr_mbr_params_page;
export symbol __stop_uicr_mbr_params_page;
define symbol __region_mbr_params_page_start = 0x0007E000;
define symbol __region_mbr_params_page_length = 0x1000;
define symbol __start_mbr_params_page = __region_mbr_params_page_start;
define symbol __stop_mbr_params_page = __region_mbr_params_page_start + __region_mbr_params_page_length;
export symbol __start_mbr_params_page;
export symbol __stop_mbr_params_page;
define symbol __region_bootloader_settings_page_start = 0x0007F000;
define symbol __region_bootloader_settings_page_length = 0x1000;
define symbol __start_bootloader_settings_page = __region_bootloader_settings_page_start;
define symbol __stop_bootloader_settings_page = __region_bootloader_settings_page_start + __region_bootloader_settings_page_length;
export symbol __start_bootloader_settings_page;
export symbol __stop_bootloader_settings_page;

define block CSTACK with alignment = 8, size = __ICFEDIT_size_cstack__ { };
define block HEAP with alignment = 8, size = __ICFEDIT_size_heap__ { };
define block RO_END with alignment = 8, size = 0 { };

initialize by copy { readwrite };
do not initialize { section .noinit };

keep { section .intvec };
place at address mem:__ICFEDIT_intvec_start__ { readonly section .intvec };
place in ROM_region { readonly,
block RO_END };
place in RAM_region { readwrite,
block CSTACK,
block HEAP };

b) Application icf file contents

/*###ICF### Section handled by ICF editor, don't touch! ****/
/*-Editor annotation file-*/
/* IcfEditorFile="$TOOLKIT_DIR$\config\ide\IcfEditor\cortex_v1_0.xml" */
/*-Specials-*/
define symbol __ICFEDIT_intvec_start__ = 0x26000;
/*-Memory Regions-*/
define symbol __ICFEDIT_region_ROM_start__ = 0x26000;
define symbol __ICFEDIT_region_ROM_end__ = 0x7ffff;
define symbol __ICFEDIT_region_RAM_start__ = 0x20005618;
define symbol __ICFEDIT_region_RAM_end__ = 0x2000ffff;
export symbol __ICFEDIT_region_RAM_start__;
export symbol __ICFEDIT_region_RAM_end__;
/*-Sizes-*/
define symbol __ICFEDIT_size_cstack__ = 2048;
define symbol __ICFEDIT_size_heap__ = 0;
/**** End of ICF editor section. ###ICF###*/

initialize by copy { readwrite };
do not initialize { section .noinit };

RE: Bootloader taking higher current consumption upon power on

Kenneth — Mon, 25 Nov 2019 09:19:46 GMT

It could be interesting to know if you have enabled the softdevice in the bootloader and application with the same LFCLK (32kHz clock source).

RE: Bootloader taking higher current consumption upon power on

Jay_Shah — Fri, 22 Nov 2019 12:59:10 GMT

Hi Kenneth,

why is it the case that I don't see the crystal stabilization time in my application? The pattern in the attached image is the only thing I see when my application runs on the board.

Why is the initialization behavior different for bootloader and the application?

P.S.: The attached image is the capture of Softdevice + Application, no bootloader is present in it.

RE: Bootloader taking higher current consumption upon power on

Kenneth — Thu, 21 Nov 2019 17:11:18 GMT

I assume you may reduce the time by using the internal 32kHz RC oscillator instead of the external 32kHz. But do you expect your product to be power cycled frequently?

300ms @ 7mA equal about 200-300 advertising events, unless you power cycle your product many times a day I doubt it will have any impact on the battery life time.

RE: Bootloader taking higher current consumption upon power on

asr — Thu, 21 Nov 2019 16:02:23 GMT

We flashed bootloader+softdevice (*.hex) image using the J-link commander. Then we flashed the application (*.zip) image using the "nrf Toolbox" by using the DFU option. I flashed above images on the Nordic nrf52832 DK board and connected the PPK and captured the above screens. I see both the bulk transactions all the time whenever I do powercycle. In the dfu example we just disabled integrity check ( system OFF reset ) that all. No more changes.

With above reply I can conclude that I can't minimize or avoid both the burst transactions(300ms & 89ms) right?

Regards,

asr.

RE: Bootloader taking higher current consumption upon power on

Kenneth — Thu, 21 Nov 2019 11:00:54 GMT

If you are using an external 32kHz crystal the startup time may for instance be around 300ms, so that may be the first (typical 0.25sec):
https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/clock.html?cp=4_2_0_18_3_3#unique_1385509760

If you erase an flash page, then that can take around 90ms (max 89.7ms):
https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/nvmc.html?cp=4_2_0_10_7_0#unique_156661312

RE: Bootloader taking higher current consumption upon power on

asr — Thu, 21 Nov 2019 10:22:54 GMT

Hi Kenneth,

I did Skip the integrity check ( system OFF reset ) in sdk_config.h file by disabling the below configuration.

// <i> Only CRC checks can be skipped. For other boot validation types, the reset state is ignored.

#ifndef NRF_BL_APP_CRC_CHECK_SKIPPED_ON_SYSTEMOFF_RESET
#define NRF_BL_APP_CRC_CHECK_SKIPPED_ON_SYSTEMOFF_RESET 0
#endif

still I see it drawing higher current.

From the above PPK screenshots, when I do power cycle I noticed that for the duration of around 300ms drawing current about 6-7mA. In the second image about 90ms average current is around 7mA. Can I know what are these bust transactions that we noticed in above PPK screens even after disabling integrity check.

Regards,

asr

RE: Bootloader taking higher current consumption upon power on

Kenneth — Wed, 20 Nov 2019 12:10:55 GMT

The bootloader will do some checksum calculation that take some time during boot,the time will depend on the size of the application, this is a one time operation when chip is powered, and I think it is reasonable to check integrity of the application firmware. You can skip the integrity check for instance when wakeup from system OFF reset:

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_nrf5_v16.0.0%2Flib_bootloader.html&cp=5_1_3_5_0_3&anchor=lib_bootloader_app_start