# Question about System.uptime()

**URL:** <https://community.particle.io/t/question-about-system-uptime/62436>\
**Category:** Firmware\
**Created:** [April 13, 2022, 8:56am UTC](https://community.particle.io/t/question-about-system-uptime/62436 "2022-04-13T08:56:42Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![stanleylio](https://avatars.discourse-cdn.com/v4/letter/s/4491bb/32.png) [@stanleylio](https://community.particle.io/u/stanleylio)\
**Post date:** [April 13, 2022, 8:56am UTC](https://community.particle.io/t/question-about-system-uptime/62436/1 "2022-04-13T08:56:42Z")

</div>

Is `System.uptime()` affected by sleep (STOP, ULP, HIBERNATE etc.)? Does it require that the RTC have the correct “true” time? I know that `millis` does not tick in sleep modes, and the RTC (I’m using Borons and Electrons on `2.3.0` LTS) won’t have the correct time until the first time the Particle device connects to cloud and do a clock sync.

The [doc](https://docs.particle.io/reference/device-os/firmware/#system-uptime-) doesn’t say much about `System.uptime()`. I suppose I can set up minimal programs to test these, but it’d be better if these behaviors are guaranteed by the doc so I can depend on them when upgrading DeviceOS.

---

<div class="post-metadata">

**Author:** ![rickkas7](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/rickkas7/32/8681_2.png) [@rickkas7](https://community.particle.io/u/rickkas7)\
**Post date:** [April 13, 2022, 9:24am UTC](https://community.particle.io/t/question-about-system-uptime/62436/2 "2022-04-13T09:24:49Z")

</div>

Uptime is literally `System.millis()` divided by 1000:

```auto
    static uint64_t millis() {
        return hal_timer_millis(nullptr);
    }

    static unsigned uptime() {
        return (hal_timer_millis(nullptr) / 1000);
    }

```

- It does not require a valid RTC time to work
- `System.millis()` behaves the same as `millis()` with regards to when it’s incremented, but the result is a `uint64_t` so it does not roll over to 0 after 49 days.

---

<div class="post-metadata">

**Author:** ![stanleylio](https://avatars.discourse-cdn.com/v4/letter/s/4491bb/32.png) [@stanleylio](https://community.particle.io/u/stanleylio)\
**Post date:** [April 13, 2022, 9:49am UTC](https://community.particle.io/t/question-about-system-uptime/62436/3 "2022-04-13T09:49:26Z")

</div>

So if `millis` does not increment in sleep modes (accord to [this post](https://community.particle.io/t/millis-or-another-time-function-while-in-sleep/25054/27)), that means neither `System.millis` nor `System.uptime` can keep track of time during sleep. So my only option of keeping track of time elapsed in sleep would be comparing `Time.now` before and after sleep. The difference between the two calls should give me the time elapsed during sleep, assuming I don’t connect to cloud and do a clock sync in between, am I correct?

---

<div class="post-metadata">

**Author:** ![rickkas7](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/rickkas7/32/8681_2.png) [@rickkas7](https://community.particle.io/u/rickkas7)\
**Post date:** [April 13, 2022, 10:16am UTC](https://community.particle.io/t/question-about-system-uptime/62436/4 "2022-04-13T10:16:45Z")

</div>

Yes, this is correct for Gen 2 (Photon, P1, Electron, E Series).

On Gen 3 devices (Argon, Boron, B Series SoM, and Tracker), the millis() counter does increment during sleep.

The reason is that on STM32, millis is implemented via the 1 millisecond MCU tick interrupt, not the RTC peripheral on the STM32.

On nRF52, there isn’t a dedicated RTC peripheral on-chip, it uses a real-time counter that does get incremented in sleep mode. This is used for both RTC and for millis().

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/flex026/uploads/particle/original/3X/6/4/64635adccc35238caa19e9b553ec3e98b163d026.png) [@system](https://community.particle.io/u/system)\
**Post date:** [May 13, 2022, 8:17pm UTC](https://community.particle.io/t/question-about-system-uptime/62436/5 "2022-05-13T20:17:21Z")

</div>

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.