High power consumption on nrf5340 custom board bluetooth mesh

Hi! 

I am experiencing higher than expected power consumption ~2  mA on a nrf5340 custom board (using Fanstel BT40E module) when attempting to configure it for a sleep mode. 

The custom firmware is configured with bluetooth mesh, mesh DFU, threads interacting with I2C and GPIO, a vendor model for sending and recieving data and commands.  

The procedure used for entering low power mode for the BT mesh firmware is: 

// Go to low power 
k_thread_suspend(thread1);
k_thread_suspend(thread2);
bt_mesh_prov_disable(BT_MESH_PROV_ADV | BT_MESH_PROV_GATT);    // disabling provisioning bearer
bt_mesh_suspend();    

k_sleep(K_MSEC(duration*1000));

// Undo low power
bt_mesh_resume();                                             
bt_mesh_prov_enable(BT_MESH_PROV_ADV | BT_MESH_PROV_GATT); 
k_thread_resume(thread1);
k_thread_resume(thread2);

This works fine on the nrf5340dk, but not on the custom board. 

The custom board has acceptable power consumption when using a low power sample such as system_off, but not with our custom firmware. 

When starting from a blank low power firmware and adding components, the power comsumption seems to jump to ~ 2 mA when adding DFU mechanisms CONFIG_BOOTLOADER_MCUBOOT=y. There is a mcuboot.conf file in child_image folder with CONFIG_LOG=n and CONFIG_SERIAL=n

Some measurements:

Custom board with system_off (soft_off or suspend to ram state) firmware sample: ~3 µA

Custom board with custom BT mesh firmware:  9 mA normal mode / 2 mA sleep mode

nrf5340 dk with same custom BT mesh firmware 4 mA normal mode / 4 µA sleep mode

The custom board measurements are done for only the microcontroller on the custom board using the PPK2.

I am looking for assistance on where to approach this problem to achieve a similar sleep mode power consumption on the custom board. 

NCS 2.4.0, also tested with 2.5 with similar result

Parents Reply Children
  • Hi Simon! 

    Ok thanks, I will investigate if VDDH pin not being connected is causing this problem. 

    To clarify, I have confirmed that the board has an acceptable power consumption when using system_off sample from nRF connect sdk and using PM_STATE_SOFT_OFF or PM_STATE_SUSPEND_TO_DISK. This measures 3 µA consumption for the MCU only and 100 µA when measuring the full board from battery, which is ok for this application.

    This makes me suspect that it is a software configuration issue and not hardware issue, however I am not 100% able to confirm this. 

  • Hi

    That would make sense, to me at least, because the VDD/VDDH pin won't be affected when in system off, so please make sure the VDDH pin is connected correctly and see if the issue still persists or not. Then we can entertain the thought of this being a SW issue.

    Best regards,

    Simon

Related