Clock source, power consumption in sleep mode

RE: Clock source, power consumption in sleep mode

arikramon — Thu, 18 Jul 2019 14:06:21 GMT

Thanks

RE: Clock source, power consumption in sleep mode

Simonr — Thu, 18 Jul 2019 13:18:33 GMT

Then you're already using the RTC, correct? So timer-wise I guess that would be the best way to do it. But you could still make the application wake up by the press of a button too. These cases also have examples on how to sleep using FreeRTOS: tickless-idle mode & Idle_state_handle.

Best regards,

Simon

RE: Clock source, power consumption in sleep mode

arikramon — Thu, 18 Jul 2019 11:03:14 GMT

This is FreeRtos function

RE: Clock source, power consumption in sleep mode

Simonr — Thu, 18 Jul 2019 08:41:29 GMT

What timer are you using for this? The RTC is the only timer that can do this for you without using the HFCLK, so I suggest using that if you don't already. You could also make your application wake up at the press of a button.

Best regards,

Simon

RE: Clock source, power consumption in sleep mode

arikramon — Thu, 18 Jul 2019 03:55:18 GMT

Thanks Simon

Regarding answer #2: I enter sleep mode in order to wake up by a timer using xTaskNotifyWait.

Is there a better way of doing it?

thanks

Arik

RE: Clock source, power consumption in sleep mode

Simonr — Tue, 16 Jul 2019 08:33:10 GMT

Hi Arik

1. Yes, but synthesizing the 32.768 kHz clock only makes sense if the external 16MHz crystal is running, and you'll have to start that before enabling the LF clock in this instance. The RC clock will be a much better option to achieve a longer battery life in this instance.

2. Does the 610uA occur when using the RC clock as well? Because that should not be the case in System ON mode unless you're using a TIMER to wake up the device. Using the RTC would be a better option, as it uses the LFCLK and not the HFCLK.

When using the synthesized LF clock an HF clock will be running at all times which will use 250-470uA depending on the usage. I assume there is a peripheral/timer that isn't uninitialized properly that's causing the 610uA current consumption.

Due to the summer holidays in Norway, our support team is understaffed this week, and delayed replies must be expected. Sorry for the inconvenience!

Best regards,

Simon