How to make the Intermittent application with GRTC and LFXO while asleep.

[shibuta]

Hi.

I have been investigating how to use GRTC and LFXO for LFCLK with nRF54L15DK.
In my goal, I would like to make the Intermittent application with sleep and GRTC that works with LFXO even if the MCU stay asleep.

I found the library(nrfx_grtc.h), but I couldn't find the sample named 'GRTC' with the library from ncs 3.0.0.

Do you know how to manipulate the API of GRTC, and properly to write the prj.cof ?

Best regards.

[Vidar Berg]

Hello,

The system clock in Zephyr is already running off the GRTC (or the RTC if you're using a nRF52/53/91 series device). So, let's say you have a single threaded application, you can make it wake up periodically using Zephyr primitives such as k_msleep(). It will be in System ON mode  between the wake ups.

int main(void)
{
    while (1) {
        printk("Woke up. Going back to sleep\n);
        k_msleep(1000);  // Sleep for 1000 ms
    }
    
    return 0;
}

https://docs.nordicsemi.com/bundle/ncs-3.1.0-preview1/page/nrf/test_and_optimize/optimizing/power_general.html 

Best regards,

Vidar

[shibuta]

HI.
Thank you for replying, but where did you find GRTC automatically works responding to power state?
Indeed, I see the k_sleep() go sleep, but I couldn't find that automatic clock source change in your URL document.
The document seemes to state some techniques for power saving.

Anyway, I will try obeying your suggested document.
If I confirm the power consumption become lower, I will report them.

Best regards.

[Vidar Berg]

The only modification you need to make to the SDK sample is to add CONFIG_GRTC_WAKEUP_ENABLE=y and CONFIG_GPIO_WAKEUP_ENABLE=n to the prj.conf. The reason you are not getting any log messages is that you have enabled logging over RTT instead of UART.

[shibuta]

Hi.

With ''nrf54l15dk/nrf54l15/cpuapp', I could see it works normally by using PPK2.

But, I would like to make it with 'nrf54l15dk/nrf54l15/cpuapp/ns'.

Why does not this example work ?

[Vidar Berg]

Hi,

It does not work with then /ns target because the app running in the non-secure processing environment does not have access to the REGULATORS and MEMCONF registers which both are used by sys_poweroff(). Any direct access made to these register from the app will lead to a fault exception.

I'm not sure how we will expose this functionality to the app yet, but there is an open task internally to address this limitation.

[shibuta]

Hi.
I guess the difference between nrf54l15dk_nrf54l15_cpuapp and /ns is whether it has the .overlay file or not. 

Once, I succeeded in building with 'nrf54l15dk_nrf54l15_cpuapp/ns' after building 'nrf54l15dk_nrf54l15_cpuapp'.

Then, I copied the content of prj.conf (below) 

CONFIG_PM_DEVICE=y
CONFIG_GPIO=y
CONFIG_CRC=y
CONFIG_POWEROFF=y
CONFIG_HWINFO=y
CONFIG_GRTC_WAKEUP_ENABLE=y
CONFIG_GPIO_WAKEUP_ENABLE=n

and the content of CMakeLists.txt

target_sources(app PRIVATE src/main.c)
if(CONFIG_APP_USE_RETAINED_MEM)
  target_sources(app PRIVATE src/retained.c)
endif()

and retained.c/.h from systemoff sample.

Then, I added the writing below in myapplication(nrf54l15dk_nrf54l15_cpuapp/ns).overlay. 

/ {
	cpuapp_sram@2002e000 {
		compatible = "zephyr,memory-region", "mmio-sram";
		reg = <0x2002e000 DT_SIZE_K(4)>;
		zephyr,memory-region = "RetainedMem";
		status = "okay";

		retainedmem0: retainedmem {
			compatible = "zephyr,retained-ram";
			status = "okay";
		};
	};

	aliases {
		retainedmemdevice = &retainedmem0;
	};
};

&cpuapp_sram {
	/* Shrink SRAM size to avoid overlap with retained memory region */
	reg = <0x20000000 DT_SIZE_K(184)>;
	ranges = <0x0 0x20000000 0x2e000>;
};

I succeeded in building, but my application failed with the log when it entered SYSTEMOFF mode
(when calling sys_poweroff() ).

[00:00:41.625,824] <err> os: ***** BUS FAULT *****
[00:00:41.625,843] <err> os:   Precise data bus error
[00:00:41.625,847] <err> os:   BFAR Address: 0x0
[00:00:41.625,857] <err> os: r0/a1:  0x00000000  r1/a2:  0x00000001  r2/a3:  0x00000000
[00:00:41.625,863] <err> os: r3/a4:  0x400cf000 r12/ip:  0x00000000 r14/lr:  0x00064c79
[00:00:41.625,867] <err> os:  xpsr:  0x41000000
[00:00:41.625,875] <err> os: s[ 0]:  0x00000000  s[ 1]:  0x0006509b  s[ 2]:  0x20013830  s[ 3]:  0x00050b13
[00:00:41.625,882] <err> os: s[ 4]:  0x20013cc0  s[ 5]:  0x00000000  s[ 6]:  0x00000000  s[ 7]:  0x00050477
[00:00:41.625,889] <err> os: s[ 8]:  0x20013100  s[ 9]:  0x00046401  s[10]:  0x00000004  s[11]:  0x00000000
[00:00:41.625,897] <err> os: s[12]:  0x2001be44  s[13]:  0x00000000  s[14]:  0x00000020  s[15]:  0x00064fc5
[00:00:41.625,911] <err> os: fpscr:  0x20013ce8
[00:00:41.625,915] <err> os: Faulting instruction address (r15/pc): 0x0004ebda
[00:00:41.625,934] <err> os: >>> ZEPHYR FATAL ERROR 25: Unknown error on CPU 0
[00:00:41.625,951] <err> os: Current thread: 0x20013830 (main)
[00:00:41.733,093] <err> os: Halting system

Is it also the main cause of the difference board configuration?

I'd like to investigate the cause and use the SYSTEMOFF and GRTC reset.

Best regards.

[Vidar Berg]

Yes the overlay will not be applied unless you append "_ns" to it. E.g., "nrf54l15dk_nrf54l15_cpuapp_ns.conf". But the problem as mentioned in my previous comment, is that the app does not have access to the MEMCONF and REGULATORS registers when you build for the */ns target. This is a limitation with our current TF-M integration.