Timer handler mess up application flow

RE: Timer handler mess up application flow

Hieu — Sat, 23 Apr 2016 18:22:52 GMT

So, as I mentioned, I did get a new idea. It is to simply halt the normal operation when I am running this new feature. The normal operation only require 5 minute precision, and the new feature's operation finishes within a second.

I will now have the compare value at whatever exact interval I need PWM toggling, says 560 or 935. Upon timer interrupt, I update the compare value and let the timer run again. Once the process is completed, I will simply reinitialize the timer to have the normal operation runs again.

I think this sounds way better than my previous approach. I feel like an idiot now that I looked at the big picture. Proper sleeps are really necessary for quality work after all.

Please feel free to give your evaluation of my new idea and any recommendation you have.

RE: Timer handler mess up application flow

Hieu — Sat, 23 Apr 2016 18:18:26 GMT

@rols: Thanks for the offer. I will try my best to explain my feature while staying conformed to my NDA. So please forgive me if things become cryptic because details are withdrawn. To be honest, I simply am not sure how much I can share in public forums. I think one would be able to guess what I am doing based on this much info anyway.

What I am trying to do is precisely turning on/off PWM and/or trigger GPIO event at varying intervals, usually 300-20,000us, with precision about 10us. The exact intervals varies by the situation. Also, this feature is not used all the time.

Because I also need my existing application work properly in the background, I decided to use a constant compare value that I could couple with a few counters to get both PWM toggling and my normal application working normally. As we have found out, that does not work so well.

RE: Timer handler mess up application flow

RK — Sat, 23 Apr 2016 16:54:46 GMT

Vo, the ARM6V reference manual gives you the basic interrupt latency, or just google for 'Cortex M0 Interrupt Latency' and it will point you to a reference. The softdevice spec tells you how many extra cycles are added for the trampoline, it's 49 cycles which is really just the softdevice working out what the interrupt is, working out it's external, loading up the interrupt table and jumping.

At this point however a better question is what are you trying to do? Interrupt timers on a 16MHz processor for a 10us event is pretty aggressive. Doing it while a higher priority softdevice is running, using generic timer code which is great but not really designed for 100kHz operation is going to break down, once you're in connection, it's going to really break down as the softdevice interrupts you. If you can say what you're trying to accomplish here it may be possible to suggest a better way.

RE: Timer handler mess up application flow

Susheel Nuguru — Sat, 23 Apr 2016 13:49:23 GMT

Hi Vo,

I have done little bit of digging in cortex M0 book and gone through this thread again. RK, You are right, It is not likely to have a stack overflow in this case because of the interrupt nesting. The AVI file Vo Thanh attached prroves that the printing thread is almost starving for CPU just after the timer interrupt is enabled. The rest of the two prints were printed normally. I have now deleted the confusing update i made ... This is most most likely that main thread is starving of CPU time.

RE: Timer handler mess up application flow

Hieu — Sat, 23 Apr 2016 13:14:37 GMT

@rols: I see now. Could you advise me where I could learn in-depth details like the number of cycles SoftDevice and Interrupt handling takes?

RE: Timer handler mess up application flow

RK — Sat, 23 Apr 2016 13:06:44 GMT

For exactly the reason Aryan mentioned above, it's 160 cycles. The M0 interrupt latency is 16, the softdevice adds 49, so basically you have 100 cycles left. If you look at the app timer code it's going to work its way down a linked list, work out which timers to fire, fire them by calling your service routine, remove them, reschedule the next one, shuffle them back into the list. And it does the servicing by raising another interrupt, so that's another 60 cycles. And that's before you actually do any work in your handler. I'm fairly impressed that it even managed to call your timer handler every 10us, back when it was basically a do-nothing handler, add any code and all you do is service the timer.

And even if it did work it wouldn't work really because the softdevice is going to interrupt and put huge big random 20-500us gaps in the timing, so you will miss many ticks.

RE: Timer handler mess up application flow

Hieu — Sat, 23 Apr 2016 12:49:35 GMT

@rols @aryan: Thanks for being so enthusiast about this case. I will get the application pointer for you when I get back to my office on Monday. @rols: You mentioned that a 10us interval is unfeasible. Could you please explain why you could tell that?

RE: Timer handler mess up application flow

RK — Sat, 23 Apr 2016 12:40:19 GMT

Aryan - if an interrupt is raised when one is already in progress, only if it's higher priority will it be taken, then, yes that interrupt handler stacks, runs and returns to the original running one. If the interrupt is the same or lower priority (which it would be if it's the same interrupt), then only the pending flag in the NVIC is set for it.

When the current interrupt returns, the highest priority pended interrupt is taken and stacked at that point (actually it just tail calls it but same effect)

So on the M0 you can theoretically only get 4 on the stack at the same time and only if you had a priority 3, then a 2 then a 1 and then a 0 interrupt in that order, each one interrupting the last before completion.

I expect in this case the timers are so short the code just ping pongs between the TIMER interrupt and the timer handler interrupt and never goes to do anything else.

RE: Timer handler mess up application flow

Susheel Nuguru — Sat, 23 Apr 2016 11:36:51 GMT

Vo Thanh Hieu, Could you please check if there is a stack overflow. It is easy to check by looking at the SP register after running your code for some time.

I am not 100% sure of how the stack is handled when the interrupt is pended while being serviced. I think what RK says makes sense but I would like to get the value of Stack Pointer just to be sure. RK, Congrats for being on the TOP of the devzone ranking. You are now most reputated user in this forum.

RE: Timer handler mess up application flow

RK — Sat, 23 Apr 2016 09:00:36 GMT

I don't see how the timer handler here is called recursively. The timer handler is called from inside the timer interrupt so by definition, even if another timer interrupt arrives, the first one is finished and returns completely before it's taken again.

I can see (and thought originally when I saw the 10us in the original post which was clearly infeasible) that the timer would be getting constantly called, ie as soon as it returns from one call, it's called instantly. I can therefore also see how the CPU ends up doing nothing but servicing the timer, stopping anything else useful from happening, but not recursively and thus not overflowing the stack.

Is there actual evidence here the stack overflowed as opposed to the CPU just being unable to keep up with the rate of timeouts it needs to handle and never really getting out of the TIMER interrupt code?

RE: Timer handler mess up application flow

Susheel Nuguru — Sat, 23 Apr 2016 08:30:55 GMT

Hi, Sorry for late replies, I really think 10us is not feasible. If you want such timing you should design something that do not need interrupt handlers using PPI and GPIOTE. Else use nRF52 where you have dedicated PWM modules which will be able to give any kind of complex PWM patterns. I will update my answer that the stack overflow happened and you could accept the answer. Think about using nRF52 instead.

RE: Timer handler mess up application flow

Hieu — Fri, 22 Apr 2016 17:07:22 GMT

By the way, should we update one of the answer with the conclusion that stack overflow happened?

RE: Timer handler mess up application flow

Hieu — Fri, 22 Apr 2016 16:35:53 GMT

That is indeed unfortunate. With TIMER0 occupied by SoftDevice, TIMER2 used for PWM, I am left with only TIMER1 to handle both PWM toggling and periodic app task timing. On the other hand my feature really need that 10us if not 5us, because PWM will need to be toggle at irregular interval.

I guess we won't be able to add that feature for now. Perhaps if I got more time later I will try to think of another solution, just got an idea actually but I ran out of time for this feature for now. Thanks for the help, Aryan.

RE: Timer handler mess up application flow

Susheel Nuguru — Fri, 22 Apr 2016 10:16:05 GMT

Yes, it could happen with the amount of code you have. More importantly, the chances are more if the timer interrupt latency is increased by having other interrupts. I think 10us is too short for reliable interrupt handling especially if this has to work with rest of the interrupts.

RE: Timer handler mess up application flow

Hieu — Fri, 22 Apr 2016 08:52:11 GMT

Aryan, that is all I could think of at the moment. Back when I failed with 1us and 5us interval, I also thought that the interrupt are fired too rapidly to be handled correctly. I was hoping that with 10us interval it would be different, and had also tried to make the handler work as light as I could make it of. What you see is literally everything in my timer handler, some conditional counter increments, some conditional flag sets. Do you think even with only so little code, stack overflow still happens?

RE: Timer handler mess up application flow

Susheel Nuguru — Fri, 22 Apr 2016 08:22:55 GMT

Hi,

10us is too short time interval to have an interrupt handler, with 10µs interval you only have 160 cycles per interrupt. With callbacks you easily exceeds this. You will then call the same function a multiple number of times until the stack is overflown and this is when the UART stops working. It has worked for me because i do not have any other interrupts and most probably my testing was very close with this border. When you have many other peripherals with interrupts enabled then most probably your stack has overflowed.

RE: Timer handler mess up application flow

Hieu — Thu, 21 Apr 2016 02:12:02 GMT

Unfortunately that idea of mine didn't work. I didn't realize the two channel will be sharing the same counter. If I have the 1ms channel reset the counter, it will ruin the precision needed for the 10us channel. If I have the 10us channel reset the counter, the 1ms channel will never get to the compare value at all.

RE: Timer handler mess up application flow

Hieu — Wed, 20 Apr 2016 08:19:00 GMT

Aryan, first of all, the 56 problem is fixed in my code after I discussed it over with Dan, but I forgot to change it in the post. Sorry about that. I will get it edited.

As for the double nrf_drv_timer_enable()calls, that is probably an error while I edited the post. Sorry about that as well. I will see that it get fixed.

I believe the problem should not lies in my I2C and PWM. They both worked before I added the "TROUBLESOME_CODE` into my timer handler. As I explained in the questions, I have a working application, and I am now just trying to toggle PWM on and off every 560us as a proof of concept for a new feature.

On other note, as I typed this comment, it occurs to me that I could use a second capture compare channel and thus have two timer handler cases, decreasing the amount of code need to run each interrupt. I will take a look at that option now.

RE: Timer handler mess up application flow

Susheel Nuguru — Wed, 20 Apr 2016 06:52:53 GMT

You are enabling the timer before configuring it and then after configuring it. This might result in false triggers before the timer is configured.

If you want 560 us then you should not use 560 as condition but 56 (56*10us = 560us)

void timer_event_handler(nrf_timer_event_t event_type, void* p_context)
{
    m_10us_cntr2++;
    if (m_10us_cntr2>= 56)
    {
         //        NOT EVEN DOING ANYTHING HERE YET
        m_10us_cntr2= 0;
    } 
}

I do not know what the last two if statements in the timer_event_handler are doing and i do not know that value of PERIODIC_TASKS_PERIOD so i removed the last if statement.

void timer_event_handler(nrf_timer_event_t event_type, void* p_context) { m_10us_cntr2++; if (m_10us_cntr2>= 56) { m_10us_cntr2= 0; nrf_gpio_pin_toggle(26); }
```
m_10us_cntr++;
if (m_10us_cntr >= 100000)
{
    m_second_counter++;
    m_10us_cntr= 0;
}
nrf_gpio_pin_toggle(25);
```
}

And i get the timer handler with good accuracy (the small error shown is interrupt latency)

And the debug log which is printed instantly (not half a minute)

timer_init
time_ticks = 160
end of timer_init()

The conclusion is there is something with your I2C or PWM handling. I am pretty sure you can exclude timer handling from the problem you have.

RE: Timer handler mess up application flow

Hieu — Wed, 20 Apr 2016 04:00:06 GMT

Dan, I was able to get more details on the issue. Please check my updated question for them

RE: Timer handler mess up application flow

Hieu — Tue, 19 Apr 2016 04:34:24 GMT

Hi Dan, I am currently out of office so I could not get more stack trace information at the moment. I just want to drop a comment about the "factor of 10" issue here:

Thanks for pointing that out. Initially I wrote the handler to run with a 1us capture compare period. However that didn't end well. For both 1us and 5us, the app encounter some problem running. It looks like I was able to notice and correct the counter target value for the 1s flag but still forgot to correct the 560us flag.

Once again, thanks for pointing that out. I will get that corrected once I got back to my office and more importantly I will get more crash details to update.

RE: Timer handler mess up application flow

Dan Danknick — Tue, 19 Apr 2016 04:16:37 GMT

To start with, all of your compares are off by a factor of 10 in timer_event_handler().

Can you give us more information on how your app crashes? For example, a stack trace from Keil and the type of "crash" - are you hitting a fault in error handler array?

RE: Timer handler mess up application flow

Hieu — Tue, 19 Apr 2016 02:50:31 GMT

Hi Aryan, I have updated my question with the information you requested. I am using SoftDevice S110 along with my application.

RE: Timer handler mess up application flow

Susheel Nuguru — Mon, 18 Apr 2016 08:52:44 GMT

Hi Vo Thanh Hieu, The code you gave does not give any good information. Can you please post the timer initialization code here. Also what is the exact place where the app fails? I could not see any debug_logs int he code you showed. You said you are using timer setup for 10us, then it is safe to assume that you are not using softdevice? Put more of your timer code so that I can look at it and try to analyse what happened.