High power consumption on nrf5340 custom board bluetooth mesh

[teover]

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

[Simonr]

Hi

Since the difference in current is so big on the custom board vs. the DK, my guess is that the custom board has some detrimental differences in HW compared to the DK, for example poorly loaded external crystals or the lack of DCDC components while still trying to use the DCDC regulator in the application or similar.

Could you upload the schematics of your custom board so we could take a closer look and compare it with the DK files? Also, does the custom board perhaps have some other components on the board that might draw additional current? Other SoCs, chips, etc. Can you also show us how exactly you measure current on the custom board with a picture for instance.

Best regards,

Simon

[teover]

As the board is part of a commercial system under development, I am unable to share the schematic, however I will try to explain as best I can.

The board does have additional components that draw current, however the measurements above were done on the MCU directly,  with the PPK2 configured as ampere meter measuring current through VDD_nRF.
As mentioned, it is a BT40 from Fanstel, so no external crystals.
The internal DCDC is not in use, and I see no difference with CONFIG_BOARD_ENABLE_DCDC_[APP, NET, HV] is set to y/n

I noticed however that VDDH is not connected to VDD as specified in https://infocenter.nordicsemi.com/index.jsp?topic=%2Fps_nrf5340%2Fchapters%2Fsupply%2Fdoc%2Fpower_supply.html 

[Simonr]

Hi Tor Egil

If the VDDH pin is not connected to VDD on a board that is not set up to run on the high voltage mode, that will be an invalid/illegal configuration and that could very well be why the current consumption is not as expected. Based on your description it sounds like you should use Circuit configuration no. 3 from the product specification as reference in your case, so please double and triple check that you don't have any major deviations from it in your schematics.

Best regards,

Simon

[teover]

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. 

[Simonr]

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