App_timer expires immediately - SDK 10

[Nikolaus Wittenstein]

I am seeing a problem identical to what's described in this question. I'm using SDK version 10.

My timers work fine for a while, but then suddenly and seemingly at random all timers expire the instant they are started. Sometimes it goes away and the timers work again, but sometimes the only fix seems to be a restart.

I've seen two suggested solutions. One is to add a delay or a call to rtc1_compare0_set in compare_reg_update; I'm on SDK 10 and both solutions are already there:

    ...
    rtc1_compare0_set(rtc1_counter_get());  // this should prevent CC to fire again in the background while the code is in RTC-ISR
    nrf_delay_us(MAX_RTC_TASKS_DELAY);
    timer_timeouts_check_sched();
    ...

The only other solution I've found on the forum is to have a dummy timer that is always running. It's recommended in this answer.

Sadly, I do already have a dummy timer always running—I've been using it to force the RTC to stay on so I can use it for timekeeping.

Are there any other known problems or solutions with app_timer? I'm running out of ideas. Thanks!

[Nikolaus Wittenstein]

Here I'm checking to see if p_timer is NULL, which signifies that we've processed the whole list of timers. If we've done so, we add ticks_elapsed to ticks_expired so that the new total ticks_expired will be equal to the original ticks_elapsed before we started processing timers. Consequently, if all the timers in the list have a ticks_to_expire of 0, we'll still move m_ticks_elapsed forward. I think this should work as a general solution though I haven't put it through any sort rigorous testing. I haven't been able to reproduce the instant-expiration problem since adding it.

The question then becomes: why does the RTC jump like that? Any ideas?