through RTC i am trying it but it is not happening can you give any propre example one for the sleep mode enabling and wakening up from the sleep mode.
through RTC i am trying it but it is not happening can you give any propre example one for the sleep mode enabling and wakening up from the sleep mode.
Hello,
Unfortunately, it is not possible to wake the nRF5340 from systemoff using the RTC. This is only possible on the nRF54L-series, which has a GRTC. Other nRF devices will not be able to have the RTC running in SystemOff, and hence, it is not possible to wake up from it. If you need to wake on a timer, you need to use systemOn-Idle.
You can read about systemoff on the nRF5340 here:
https://docs.nordicsemi.com/bundle/ps_nrf5340/page/chapters/reset/doc/reset.html#ariaid-title5
So from systemOff, the only things that can wake up the nRF5340 are GPIO interrupts, reset pin, power on reset or NFC. If you need to wake it up from a timer, you need to have an external timer module that can give a pulse after a given amount of time.
Best regards,
Edvin
Hello Edvin,
Thank you for the detailed explanation — it’s clear now.
So to confirm my understanding:
__WFE(), k_sleep(), and k_cpu_idle() will all enter SystemOn-Idle.
The main advantage of using k_sleep() is that it integrates with the scheduler and handles wakeup timers.
As long as all threads are waiting (sleep/semaphore/etc.), the CPU will automatically go into SystemOn-Idle.
I’ll go through the Bluetooth samples (like peripheral_uart) as you suggested to see this in practice.
Best regards,
Lalith
Hi
If it is an battery overrented one then which one you will suggest.
Best regards
Lalith
lalith88 said:So to confirm my understanding:
Yes. All of those are correct.
lalith88 said:If it is an battery overrented one then which one you will suggest.
We don't have any recommendations for 3rd party products. Besides, this will very much depend on your device. How much current your application is drawing, and how long you want the battery to last, decides what capacity you would need.
The only thing that comes to mind is that you can look at the BOM for the Thingies that we have, such as the Thingy 53:
https://www.nordicsemi.com/Products/Development-hardware/Nordic-Thingy-53/Downloads?lang=en#infotabs
Look for the "Hardware Files", which contains the BOM.
Best regards,
Edvin
Hello Edvin,
Sorry for the confusion in my previous question — I wasn’t asking about batteries.
What I meant was:
If I want to explicitly put the CPU into SystemOn-Idle, which method is recommended in Zephyr on the nRF5340?
Using k_sleep()
Using k_cpu_idle()
Or calling __WFE() directly
From your previous reply, I understand they are functionally similar, but I’d like to know which one is considered best practice when writing Zephyr applications (for example, in terms of scheduler integration, power management, and maintainability).
Best regards,
Lalith
I would use k_sleep for regular wakeups, and k_cpu_idle if you are going to sleep, just waiting for some event. If that event is a button press, and you are not doing any BLE activity, you can use system off (sys_poweroff()). If it needs to wake up without external sources, use k_sleep() if you are waking on a timer, or k_cpu_idle() if you are waking on something else.
When you are using the softdevice controller for BLE activity, the softdevice will wake up what it needs to to maintain that connection/advertising/scanning. It will wake up the radio core on it's own, and if there is an event that is propagated to the application (incoming data, for instance) then the radio core will wake up the application core.
Best regards,
Edvin
I would use k_sleep for regular wakeups, and k_cpu_idle if you are going to sleep, just waiting for some event. If that event is a button press, and you are not doing any BLE activity, you can use system off (sys_poweroff()). If it needs to wake up without external sources, use k_sleep() if you are waking on a timer, or k_cpu_idle() if you are waking on something else.
When you are using the softdevice controller for BLE activity, the softdevice will wake up what it needs to to maintain that connection/advertising/scanning. It will wake up the radio core on it's own, and if there is an event that is propagated to the application (incoming data, for instance) then the radio core will wake up the application core.
Best regards,
Edvin