Sleep current with FreeRTOS

RE: Sleep current with FreeRTOS

Chongchun Moon — Mon, 06 May 2019 16:38:51 GMT

Hello,

Here is update.

After I changed GPIO(to wake up from sleep) setting. I changed GPIO accuracy setting.

Current consumption is 50uA now. I think it looks okay for now.

Now, problem is BLE doesn't work properly after re-enable soft device from sleep.

Maybe, I need to create another ticket.

Thanks,

Chongchun Moon

RE: Sleep current with FreeRTOS

Chongchun Moon — Sat, 04 May 2019 13:19:37 GMT

Hello,

Here is some update for this issue.

After disabling softdevice by calling sd_softdevice_disable(), Current consumption is reduced approx. 300uA.

There is no other interrupt occurred after that.

In 300uA current consumption, I guess that HFCLK draws 250uA as I checked register value.

How can I disable HFCLK block? I tried stop HFCLK block. But It doesn't work.

Thanks,

Chongchun Moon

RE: Sleep current with FreeRTOS

Chongchun Moon — Fri, 03 May 2019 15:36:20 GMT

Hello,

Thank you for respond.

Regarding to checking NVIC->ISPR[0] and NVIC->ISPR[1].

I already checked that part using GPIOs as you can see above.

In the port_cmsis_systick.c which I uploaded above, If There are some pending interrupt in NVIC->ISPR[0] and NVIC->ISPR[1], code will run outside of "while (0 == (NVIC->ISPR[0] | NVIC->ISPR[1]))" and GPIO 10 pin will be changed. But, It is not changed. So, It is supposed that there is unhandled interrupt from my application.

Do I need to check those register(NVIC->ISPR[0] and NVIC->ISPR[1]) in other way?

If so, Please guide me to do that.

By the way, What's average current of CPU when softdevice is used and CPU is sleep mode?

Thanks,

Chongchun Moon.

RE: Sleep current with FreeRTOS

Susheel Nuguru — Fri, 03 May 2019 11:01:32 GMT

Hi,

Your observations are correct.

the sd_app_evt_wait filters the SD events and makes sure that the application is not awake until there is any app specific interrupt/event.

The change we did to add #if 0 for (NRFFOSDK-11174) was on some specific chips which has poor sleep performance for sd_app_evt_wait. But it looks like you should not use this patch. Please change the codeto use sd_app_evt_wait in your case to get better

If your system is not going to sleep with sd_app_evt_wait, then I would suggest you to print out the value for NVIC->ISPR[0] and NVIC->ISPR[1] separately to see if there are any application specific interrupts that are pending and your application is not servicing them for some reason.