High current consumption after creating a new task on freertos

[kevinlam]

Hello,

MCU: 52832

SDK: nRF5_SDK_17.0.2_d674dde

I am currently using ble_app_hrs_freertos_pca10040_s132 as starting point with SEGGER Embedded Studio as debugger. Below is the current consumption sequence with different modifications:

1) ~7.3mA - Original Code

2) ~3.5mA - After adding below code

// Set power mode
err_code = sd_power_mode_set(NRF_POWER_MODE_LOWPWR);
APP_ERROR_CHECK(err_code);

// set dcdc mode
err_code = sd_power_dcdc_mode_set(NRF_POWER_DCDC_ENABLE);
APP_ERROR_CHECK(err_code);

3) ~40uA - After set NRF_LOG_ENABLED to 0

4) ~3.5mA - After creating new task

I am suspecting that there is idle / sleep issue on FreeRTOS after creating a task, same issue happened for NRF log task. Please advise how can I fix this issue and getting a normal current consumption.

Thanks and best regards,

Kevin

[Susheel Nuguru]

Can you please add the code for the new task so that i can check why it is consuming so much power? Is the task yielding properly?

[kevinlam]

Make it simple, I think you can use the original code and set power mode and dcdc mode like me, then see the current is ~3.5mA or not. It may give you a clue that why it is consuming so much power when a task (NRF Logging) is running.

Besides, I am studying that how to use NFC energy harvesting power output to power up 52832, the power output from energy harvesting is around 14.5mW around, which is around 4.4mA at 3.3V, it seems not enough power to power up 52832, am I correct? If so, what can I do to reduce the power up current?

Thanks and regards,

[Susheel Nuguru]

Hi Kevin,

Sorry for the late reply, I was OoO.

Regarding your first question, I tried the example. Most likely the heap is used up in kernel internal structures and the two tasks that are created. When you are creating the new task, you most likely get an error NRF_ERROR_NO_MEM asserting and looping in the assert handler (not sleeping). You need to increase the configTOTAL_HEAP_SIZE in ble_app_hrs_freertos\config\FreeRTOSConfig.h file so that the kernel can allocate stack from this heap. After changing that, i only do not see high power consumption after creating this new task. NRF_LOGS with default UART/RTT backend keeps the HFCLK on for the logs to work, so that is the reason you do not see low power even in sleep since HFCLK is not powered down when CPU sleeps since UART is still powered on and locks the HFCLK on.

Regarding your output power of 14.5mW. I am guessing that there is no control circuitry in your harvester that limits this power output and shuts it down when max is reached. If there is no control circuitry and you have chosen the right series resistance, then due to this max 14.5mW power output, the decoupling capacitors on the nRF are going to take longer time to charge and hence the boot up time for the SoC is going to be a bit longer.It actually could be more beneficial to leave at 3V and put the chip in system OFF if you do not want to charge the decoupling caps all the time.