App_timer expires immediately - SDK 10

RE: App_timer expires immediately - SDK 10

Nikolaus Wittenstein — Tue, 22 Mar 2016 18:21:01 GMT

nrf51. The counter value appears to jump when you set a timer with timeout greater than MAX_RTC_COUNTER_VAL/2. This is not a bug in the RTC module; it's in app_timer. If you never set any timers with a timeout greater than MAX_RTC_COUNTER_VAL/2, you'll never experience any problems. If you read through the comments and look at the patches I provided you can see where the problem is, but I really just recommend capping your max timeout (that's what I ended up doing).

RE: App_timer expires immediately - SDK 10

Krzysztof Chruscinski — Tue, 22 Mar 2016 18:13:26 GMT

Hi, i see that no one ask before: are you experiencing it on nrf52 or nrf51? It is very much unexpected that suddenly COUNTER value jumps. I would like to track that down.

RE: App_timer expires immediately - SDK 10

Nikolaus Wittenstein — Wed, 24 Feb 2016 13:45:06 GMT

No worries! I'm excited for the release of the new SDK :)

RE: App_timer expires immediately - SDK 10

Susheel Nuguru — Wed, 24 Feb 2016 08:41:58 GMT

Nikoloaus, the team said they are in a bit of a rush with the new SDK release work, so this case would have to wait few days.. sorry about that and i am also have little spare time, else i would have dug into it.

RE: App_timer expires immediately - SDK 10

Nikolaus Wittenstein — Tue, 23 Feb 2016 22:36:09 GMT

I've just discovered what looks like a bug in my solution—sometimes if I schedule a timer very quickly back-to-back it stops expiring correctly. Maybe the developer who maintains the module can tell what's wrong with my approach :) I'll be looking into it tomorrow and I'll let you know what I find.

RE: App_timer expires immediately - SDK 10

Nikolaus Wittenstein — Tue, 23 Feb 2016 13:54:14 GMT

Thanks Aryan!

RE: App_timer expires immediately - SDK 10

Susheel Nuguru — Tue, 23 Feb 2016 09:35:24 GMT

I have forwarded this to the developer who is maintaining this module. You will hear from him or me when there are updates to mention.

RE: App_timer expires immediately - SDK 10

Susheel Nuguru — Mon, 22 Feb 2016 17:40:43 GMT

oops, missed to follow this, will look into this tomorrow.. sorry, there lot of things in my plate. Thanks for the gentle reminder.

RE: App_timer expires immediately - SDK 10

Nikolaus Wittenstein — Mon, 22 Feb 2016 17:22:22 GMT

Aryan, did you get a chance to give this a look? Would something like this be able to make it into SDK 11?

Thanks!

RE: App_timer expires immediately - SDK 10

Nikolaus Wittenstein — Fri, 12 Feb 2016 14:18:17 GMT

Yeah, I had looked to see if SDK 11 was any different. We haven't moved to that yet anyway because of its alpha status. But maybe that means there's time to make some changes to app_timer? :)

Thanks a lot for taking a look!

RE: App_timer expires immediately - SDK 10

Susheel Nuguru — Fri, 12 Feb 2016 06:28:36 GMT

Hi Nikolaus,

Seems like you have done quite a bit of research here. I have not looked into the patch, but I was wondering if you tried to see if this bug existed in SDK11? I will go through your patch today ...

EDIT:

SDK 11 app_timer is almost same as SDK10 app_timer, so both should behave same ..

RE: App_timer expires immediately - SDK 10

Nikolaus Wittenstein — Thu, 11 Feb 2016 22:40:22 GMT

Okay, I think this patch fixes everything. Let me know what you think, Aryan!

The main difference is that elapsed_ticks_acquire returns the time since m_ticks_latest if no timers have expired. In this case, expired_timers_handler will already just subtract that value from the leading timer's ticks_to_expire. To get it to work nicely, there's now a distinction between needing to call expired_timers_handler (which now always happens) and needing to update the compare register.

I'm not seeing any instant expirations with this code.

Thanks!

RE: App_timer expires immediately - SDK 10

Wojtek — Thu, 11 Feb 2016 19:35:55 GMT

What is the timeout you want to achieve?

RE: App_timer expires immediately - SDK 10

Nikolaus Wittenstein — Thu, 11 Feb 2016 19:34:44 GMT

Do you know why timer_timeouts_check has a distinction between ticks_elapsed and ticks_expired? It looks like everything might just work if this distinction is removed; in other words, essentially if my patch above said if (true) instead of if (p_timer == NULL). I just tried it out and it seems to work great.

Next I'm going to figure out a way to fix this bug in list_insertions_handler.

RE: App_timer expires immediately - SDK 10

Nikolaus Wittenstein — Thu, 11 Feb 2016 19:21:38 GMT

My first patch assumed that we would only ever see ticks_to_expire == 0 when there was only one timer in the list. I had changed app_timer very slightly to keep RTC1 on at all times, so it was possible to be inserting a timer into an empty list while RTC1 was running.

For my latest comment I thought it prudent to roll back to stock app_timer and lock the timer on using a timer with a very long timeout to make sure that I could repro that instant-expire bug without my changes. Imagine my surprise when the instant-expiration bug reappeared. The problem is obvious: I was checking if we'd processed the whole list, which of course we hadn't because the second timer was so long.

RE: App_timer expires immediately - SDK 10

Nikolaus Wittenstein — Thu, 11 Feb 2016 19:12:37 GMT

I think there may also be something incorrect happening in list_insertions_handler. If no timer has expired for more than half of the RTC duration then m_ticks_latest won't have been updated during this time. list_insertions_handler will fail this check:

    if (
         ((p_timer->ticks_at_start - m_ticks_latest) & MAX_RTC_COUNTER_VAL)
         <
         (MAX_RTC_COUNTER_VAL / 2)
        )

delta_current_start will be set to a very large value, and the timer's ticks_to_expire will get set to 0.

This means that if you have a timer running with a timeout greater than MAX_RTC_COUNTER_VAL/2 and don't expire any timers for just over MAX_RTC_COUNTER_VAL/2, then setting a timer with a reasonable timeout will cause it to expire immediately.

This is also relevant because it doesn't work with my patch above. See next comment.

RE: App_timer expires immediately - SDK 10

Nikolaus Wittenstein — Thu, 11 Feb 2016 18:28:15 GMT

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?

RE: App_timer expires immediately - SDK 10

Nikolaus Wittenstein — Thu, 11 Feb 2016 18:23:01 GMT

When the RTC jumps like that and a timer gets scheduled, the timer's ticks_to_expire gets set to 0 in list_insertions_handler because the counter is so far ahead of m_ticks_latest.

Then, in timer_timeouts_check, ticks_expired is 0 because it gets set to the timer's ticks_to_expire. m_ticks_elapsed consequently gets set to 0, so m_ticks_latest never increases. At this point, any timer that gets scheduled will expire immediately.

A solution that appears to work is the addition of the following lines of code:

+        // If we processed all timers, then move the elapsed ticks counter all the way up to now.
+        if (p_timer == NULL)
+        {
+            ticks_expired += ticks_elapsed;
+        }
         // Queue the ticks expired.
         m_ticks_elapsed[m_ticks_elapsed_q_write_ind] = ticks_expired;

(see next comment)

RE: App_timer expires immediately - SDK 10

Nikolaus Wittenstein — Thu, 11 Feb 2016 17:19:52 GMT

We only have one board available right now, unfortunately, so I can't really send it out.

In the mean time I've been looking into things myself. I'm printing out (using RTT) the counter value from rtc1_counter_get inside of timer_timeouts_check. Here's a mysterious progression:

   ...
    0x0DEBA9
    0x0E5B26
    0x0E6F14
    0x8E6F5E
    0x8E6FCE
    ...

Somehow the high bit in the counter is getting set. This coincides exactly with when all timers begin to expire instantly (note the very close tick count gaps at the end there). Is there any possible way the RTC1 counter could get screwed up like this? I'm not using the counter at all except through app_timer.

I'll comment again when I have further results.

Thanks!

RE: App_timer expires immediately - SDK 10

Susheel Nuguru — Wed, 10 Feb 2016 18:31:21 GMT

i havent heard of this on SDK10, that is why it interests me so much. If you open a support ticket on my page, then i can assign it to myself and then i am bound to NDA, in that case you can send your project and custom board and I am bound to NDA automatically. I would like to help you, but first I need to see it myself.

RE: App_timer expires immediately - SDK 10

Nikolaus Wittenstein — Wed, 10 Feb 2016 18:15:58 GMT

It's proprietary software and it's running on a custom board. I'm not sure if I can send it to you, sadly, and I also don't know how you'd be able to run it. Is there anything else I could look at? Have you heard of this before? Thanks!

RE: App_timer expires immediately - SDK 10

Susheel Nuguru — Tue, 09 Feb 2016 12:04:58 GMT

is it possible for me to get the project and see it ? It would be easier for me to debug it.

RE: App_timer expires immediately - SDK 10

Nikolaus Wittenstein — Fri, 05 Feb 2016 14:25:10 GMT

I'm just using a dummy timer for now. I'm not using a scheduler.

RE: App_timer expires immediately - SDK 10

Wojtek — Fri, 05 Feb 2016 00:16:14 GMT

Actually I don't understand your problem, but again - why do you already use dummy timer? I also use RTC to keep the time, but I don't use any tricks to keep it alive... Also, are you using scheduler? Maybe scheduler queue is too small?