Arduino millis() rollover after ~50 days: diagnosing subtraction reliability

Answer

Assuming an AVR-based Arduino core where unsigned long is 32 bits, (currentMillis - previousMillis) < interval remains valid across the millis() wrap provided the true interval is below 2³² ms (~49.7 days). The expression if (millis() >= triggerTime) does not reliably fire after rollover when triggerTime was captured before the overflow. For multiple rollover cycles, prefer interval subtraction over absolute timestamp comparison, or maintain a separate overflow counter.

Confirmed facts

• millis() returns an unsigned 32-bit value that wraps to zero after 2³² milliseconds.
• Unsigned subtraction wraps modulo 2³², so the difference between two reads is correct for intervals shorter than the wrap period.
• A direct >= comparison against a pre-wrap timestamp can produce a false negative after rollover because the counter restarts at zero.
• AVR millis() updates are not atomic with respect to Timer0 interrupt context.

Likely explanation

After wrap, currentMillis is small while previousMillis is large. Unsigned subtraction computes the forward distance across the boundary, but a magnitude comparison sees the small current value as less than the stored trigger and skips the action.

Steps to verify

1. Read unsigned long a = millis();, wait 1000 ms, read unsigned long b = millis();, and confirm b - a is 1000.
2. Set previousMillis near 0xFFFFFFFF, let millis() pass zero, and confirm the subtraction still reports the expected short interval.
3. Search all interrupt service routines for writes to previousMillis; if any exist, copy millis() to a local variable with interrupts disabled before subtracting.

Please confirm whether previousMillis is ever written by an interrupt after rollover; that determines whether atomic reads are required in addition to wrap-safe subtraction.