Zephyr Warm-reset after propietary freeRTOS enabled bootloader

RE: Zephyr Warm-reset after propietary freeRTOS enabled bootloader

Susheel Nuguru — Mon, 27 May 2024 12:46:06 GMT

[quote user="Armand La Flent"]What I can see is that I need to stop the RTC on a SYS_INIT operation before any other Zephyr core initialization to get k_sleep to work fine.[/quote]

That is strange, can you show me the code snippet and the context of this change? Can you connect a debugger and put a breakpoint early in your application at SYS_INIT and view the RTC registers to see if you see the values cleared as expected?

RE: Zephyr Warm-reset after propietary freeRTOS enabled bootloader

Ignacio — Mon, 27 May 2024 11:52:01 GMT

Hi Susheel

Thanks for your reply. Are the RTC register clear when you jump from a proprietary bootloader? What I can see is that I need to stop the RTC on a SYS_INIT operation before any other Zephyr core initialization to get k_sleep to work fine.

RE: Zephyr Warm-reset after propietary freeRTOS enabled bootloader

Susheel Nuguru — Mon, 27 May 2024 11:10:57 GMT

I thought that MCUBOOT_CLEANUP_ARM_CORE is deprecated as my understanding was that this needed to be true for latest MCUBoot builds and I do not see any such option on the application side.

In Zephyr, the Real-Time Counter (RTC) is typically used for timing services of the kernel, such as k_sleep() and the kernel timer API. This is usually a Real-time counter peripheral (RTC1) on Nordic SoCs and SiPs (nRF91, nRF53, nRF52 Series).
The Zephyr kernel timer, used when you are using functions like k_cycle_get_32, is also based on the same RTC as discussed in this thread.

RE: Zephyr Warm-reset after propietary freeRTOS enabled bootloader

Ignacio — Sat, 25 May 2024 16:22:05 GMT

I added the below code on the main to eliminate the timing conflict:

static int nrf52_sys_init(void) {

// Stop RTC1 to avoid conflit with

// propietary bootloader RTC1 config

NRF_RTC1->TASKS_STOP=1; return 0;

}

SYS_INIT(nrf52_sys_init, EARLY, 0);

My observation is that if a proprietary code fiddles with RTC1 configuration will affect the normal running of k_sleep on Zephyr. I am currently working under NCS v2.6.0. Is that the expected behaviour?