nRF5340, enter low-power/sleep while timer enabled

RE: nRF5340, enter low-power/sleep while timer enabled

Hung Bui — Mon, 21 Oct 2024 08:16:36 GMT

Hi,
Sorry for confusion. No I do not mean that you should only put the k_sleep(K_FOREVER); to an independent thread. What I meant was to put the whole

while (true) {
execute_other_code(); // ... BUT DOESN'T EXECUTE UNTIL BEFORE NEXT INTERRUPT

k_sleep(K_FOREVER);
}

Into an independent thread just in case there isn't a way to get the main thread id. But you already find the k_current_get() so it's fine.

RE: nRF5340, enter low-power/sleep while timer enabled

esmart-engineering — Sat, 19 Oct 2024 02:53:42 GMT

I will consider that suggestion.

In the meanwhile, I wanted to circle back to your suggestion to "put the sleep forever into an independent thread". I tried this but it just kept the main thread running all the time. If I misinterpreted what you meant, I'd appreciate a clarification. A quick example would also be greatly appreciated if possible.

k_tid_t main_thread_id;

void wakeup_main(void)
{
    k_wakeup(main_thread_id);
}

void interrupt_handler(void)
{
  restart_timer();  // for example, with RTC, this is counter_set_channel_alarm()
  wakeup_main();
}

int main()
{
  main_thread_id = k_current_get();
  init_timer();

  while (true) {
    execute_other_code();    // ... BUT DOESN'T EXECUTE UNTIL BEFORE NEXT INTERRUPT
  }
}

#define STACKSIZE 1024
static void sleep_thread(void *arg1, void *arg2, void *arg3)
{
    int rc;
    ARG_UNUSED(arg1);
    ARG_UNUSED(arg2);
    ARG_UNUSED(arg3);
    
    k_sleep(K_FOREVER);
}
K_THREAD_DEFINE(sleep_thread_id, STACKSIZE, sleep_thread, NULL, NULL, NULL,
        K_LOWEST_THREAD_PRIO, 0, 100);

RE: nRF5340, enter low-power/sleep while timer enabled

Hung Bui — Fri, 18 Oct 2024 08:44:35 GMT

I'm happy to help. But I would suggest to keep your task outside of the main loop. I would prefer to have different threads/timer for your tasks instead of putting them into a main loop .

RE: nRF5340, enter low-power/sleep while timer enabled

esmart-engineering — Fri, 18 Oct 2024 03:40:22 GMT

So I made a simpler project doing this, but it behaved as I expected. I looked into it more on my project (which gets a little more complicated: performs SPI reads in interrupt handler, which completes in another interrupt handler, etc.) and ultimately fixed that issue. Did not find the root cause, but generally having main woken up a little earlier (i.e., before the SPI read) seemed to help.

Thank you for offering your help though!

RE: nRF5340, enter low-power/sleep while timer enabled

Hung Bui — Thu, 17 Oct 2024 08:06:06 GMT

Hi,
Could you provide your toggling code so I can test here.
Please explain what you are trying to do ? If you plan to execute some code periodically, can't you just use the timer and leave the main loop clean?

RE: nRF5340, enter low-power/sleep while timer enabled

esmart-engineering — Thu, 17 Oct 2024 03:34:46 GMT

I used k_current_get() to get the main thread ID, like so. But it seems to wakeup much later (just before the interrupt handler gets called again). I tried having the interrupts occur every 3ms or every 3 seconds, and it gave the same behavior. I also tried putting the k_current_get() and infinite loop in another thread using K_THREAD_DEFINE() but it also gave the same behavior.

k_tid_t main_thread_id;

void wakeup_main(void)
{
    k_wakeup(main_thread_id);
}

void interrupt_handler(void)
{
  restart_timer();  // for example, with RTC, this is counter_set_channel_alarm()
  
  wakeup_main();                  // DOES WAKE UP MAIN...
}

int main()
{
  main_thread_id = k_current_get();

  init_timer();

  while (true) {
    execute_other_code();    // ... BUT DOESN'T EXECUTE UNTIL BEFORE NEXT INTERRUPT

    k_sleep(K_FOREVER);
  }
}

I confirmed this using a logic analyzer (sampling rate of 25MHz). Red line toggles each time main() runs, and orange line toggles each time interrupt handler is just about to call k_wakeup(). I did confirm that if I do not call k_wakeup(), red line never toggles.

RE: nRF5340, enter low-power/sleep while timer enabled

Hung Bui — Wed, 16 Oct 2024 12:06:39 GMT

Hi,
Yes you can use k_wakeup() to wake up a sleeping thread. I believe you can wake up the main thread. You may need to find how to get the main thread ID. But an easy workaround is to put the sleep forever into an independent thread.

RE: nRF5340, enter low-power/sleep while timer enabled

esmart-engineering — Wed, 16 Oct 2024 03:17:30 GMT

(OP replying) Somewhat related question, but is it possible to cancel the remainder of a k_sleep() call within an interrupt handler?

void interrupt_handler(void)
{
  restart_timer();  // for example, with RTC, this is counter_set_channel_alarm()
  
  cancel_ksleep();                  // DOES SOMETHING LIKE THIS EXIST...
}

int main()
{
  init_timer();

  while (true) {
    execute_other_code();    // ... SO THAT THIS EXECUTES MORE THAN ONCE?

    k_sleep(K_FOREVER);
  }
}

I realize this may not be common to do; for example, I know that things happening periodically could just be put in the main loop with k_sleep(SOME_AMOUNT_OF_TIME). But it may be possible that my project would benefit from something like this what with the timers and other complex portions of our code.

RE: nRF5340, enter low-power/sleep while timer enabled

esmart-engineering — Tue, 15 Oct 2024 20:33:38 GMT

Yes, CONFIG_SERIAL=n seemed to do it. The LBS project seems to have its child image project files over in the sample HCI_RPMSG project (my local NCS installation path, zephyr\samples\bluetooth\hci_rpmsg). I edited the prj.conf there w/ CONFIG_SERIAL=n, rebuilt the project, flashed the build, and confirmed w/ PPK2 that when idle it's drawing roughly 3.5uA. I've attached the .ppk file here (sorry about that; I got confused between the Power Profiler's log and the session data).

devzone.nordicsemi.com/.../ppk2_2D00_session_2D00_data_2D00_nrf5340dk_5F00_hciRpmsgConfigSerialNo.ppk

Current measurement setup should be correct. When first making this post, I have been using an nRF5340DK, and did already cut SB40. I put PPK2's GND to DK's P21 negative pin, VIN to P22 'bottom pin' (close to SW9), and VOUT to P22 'top pin' (close to P23).

But thanks! I will take a look at the config from the LBS project, and see how I can apply it to my own project. Still need to check out the timer utilizing RTC; will reply again when I have an update.

RE: nRF5340, enter low-power/sleep while timer enabled

Hung Bui — Tue, 15 Oct 2024 07:55:52 GMT

Hi,
How did you use the PPK2 ? If you us the nRF Connect for Desktop -> Power profile app, you can click Save/export and save a .ppk2 file.

I assume you are measuring the current consumption on a DK ? Please let us know how did you do that, did you cut SB40.

Also, since you are measuring on the nRF53, please pay extra extension that you should turn off UART log on the network core.
you should set CONFIG_SERIAL=n on the child image project configuration. I think that's most likely the reason why you see high current consumption with lbs minimal project.

RE: nRF5340, enter low-power/sleep while timer enabled

esmart-engineering — Mon, 14 Oct 2024 21:49:28 GMT

I am fairly confident that I'm using prj_minimal.conf. For context, I use VS Code; when adding the build configuration I select board target as 'nrf5340dk_nrf5340_cpuapp' and base configuration files as 'prj_minimal.conf'.

I've attached the PPK2 log; before log started, board was already flashed with firmware and I have not done anything with it i.e., I haven't connected to it using nRF Connect for Mobile.

devzone.nordicsemi.com/.../ppk2_5F00_log_5F00_verbose_5F00_2024_2D00_10_2D00_14T21_5F00_13_5F00_10.988Z_2D00_log.txt

We were originally more worried about the resolution of 30us, rather than the accuracy. But, after discussing with my team, that may be fine.

A timer like that would be great. We'll take a look; thanks!

RE: nRF5340, enter low-power/sleep while timer enabled

Hung Bui — Mon, 14 Oct 2024 07:07:30 GMT

Hi,
Have you made sure you use the prj_minimal.conf when testing with lbs ?
Please send us your PPK2 log. You should see only about 2-4uA sleeping with lbs minimal configuration.

If you need a timer for event every 0.5ms I don't see a problem with RTC. If you have a 32kHz crystal, the accuracy can be 20ppm , meaning you have a tolerance of 0.00001ms. Or if you use RC the accuracy is 500ppm, it will be 0.00025ms.
But instead of using k_sleep you should set up a timer . It will use the RTC.

RE: nRF5340, enter low-power/sleep while timer enabled

esmart-engineering — Fri, 11 Oct 2024 16:45:48 GMT

We are using the timer to read data w/ SPI as quickly as every 0.5ms, so the accuracy is a high requirement.

I will try out the k_sleep() in a separate project momentarily. The 0.2mA I measured is from my project, which hasn't been fully optimized yet.

I tested that LBS sample (NCS v2.5.0, nrf/samples/bluetooth/peripheral_lbs/) and got about 461uA when sleeping, with roughly 5mA spikes every 100ms.

RE: nRF5340, enter low-power/sleep while timer enabled

Hung Bui — Fri, 11 Oct 2024 14:28:30 GMT

Hi,
The TIMER requires the 32MHz oscillator to run and that's the main reason you are seeing higher current draw.
Do you have a reason why you want to keep a TIMER running ? If you simply want to keeping the time and doesn't have high requirement on the accuracy you should use the RTC instead. It draws much less current. The k_sleep() function in Zephyr also use RTC.
When you call k_sleep() and when you don't have any other task running you should see about 2-4 uA current consumption (not 0.2mA)
Could you try to test with the periphreal_lbs sample (use prj_minimal.conf) and measure the current consumption with the PPK2 ?