k_uptime_get return a signed value

RE: k_uptime_get return a signed value

Håkon Alseth — Tue, 29 Jun 2021 08:59:40 GMT

[quote user="Depraz"]Thanks Håkon![/quote]

Always happy to help! Please let us know if there's anything else that should pop up.

Hope you have a wonderful day, Florian!

Kind regards,

Håkon

RE: k_uptime_get return a signed value

Depraz — Tue, 29 Jun 2021 08:32:04 GMT

Thanks Håkon!

RE: k_uptime_get return a signed value

Håkon Alseth — Fri, 25 Jun 2021 13:50:13 GMT

Hi Florian,

[quote user="Depraz"]

Once started (without the tickless option), can I safely assume that this counter won't restart to 0 unless the program runs for years and years (i.e. until 2^64 milliseconds) ?

I see that the driver is returning 32bit values. Once we reach 2^32 milliseconds, will we restart to 0 even if we are using k_uptime_get which should return an 64bit?

[/quote]

If we look deeper into how the ticks are handled, its a diff based on the last time the counter was updated:

https://github.com/nrfconnect/sdk-zephyr/blob/master/include/drivers/timer/system_timer.h#L124-L132

This is the call from k_uptime_ticks -> sys_clock_tick_get:

curr_tick + delta

The "curr_tick" is updated when function "sys_clock_announce()" is called.

As long as the sys_clock_announce() updates the curr_tick every 2^24 -1 ticks, (RTC max CC value), it should be able to run as expected.

Kind regards,

Håkon

RE: k_uptime_get return a signed value

Depraz — Fri, 25 Jun 2021 12:35:33 GMT

Thanks for the answer Håkon.

Once started (without the tickless option), can I safely assume that this counter won't restart to 0 unless the program runs for years and years (i.e. until 2^64 milliseconds) ?

I see that the driver is returning 32bit values. Once we reach 2^32 milliseconds, will we restart to 0 even if we are using k_uptime_get which should return an 64bit?

Best regards,
Florian

RE: k_uptime_get return a signed value

Håkon Alseth — Fri, 25 Jun 2021 12:11:13 GMT

Hi,

[quote user=""]

I would like to use k_uptime_get, however this is returning an int64_t where I would expect an uint64_t.

While looking in the function, I see that k_uptime_get calls k_ticks_to_ms_floor64(k_uptime_ticks()); which should be returning an uint64_t.

What is the reason for this cast?

How is this counter computed? Is it reading a hardware register? Can this counter return to 0 in some cases (apart from a reboot)?

[/quote]

I cannot specifically point directly to the source of the cast, unfortunately.

This change was introduced with the rework in upstream zephyr:

https://github.com/zephyrproject-rtos/zephyr/pull/23382

This timer is based on the NRF_RTC counter, and this is the nrf specific implementation that (eventually) is fetched by the kernel API:

https://github.com/nrfconnect/sdk-zephyr/blob/master/drivers/timer/nrf_rtc_timer.c

It can be read out as 0, but that is due to being called when its not configured as tickless:

https://github.com/nrfconnect/sdk-zephyr/blob/master/drivers/timer/nrf_rtc_timer.c#L386

Kind regards,

Håkon