RTC Compare Interrupt Doesn't Happen After Debugger Halted

RE: RTC Compare Interrupt Doesn't Happen After Debugger Halted

WestCoastDaz — Thu, 02 Apr 2015 23:47:42 GMT

RK, Thank you for your help on this. I guess I need to let go of my MSP430 experiences. I did consider setting the compare value to be a multiple greater than the clock.

RE: RTC Compare Interrupt Doesn't Happen After Debugger Halted

RK — Thu, 02 Apr 2015 23:42:58 GMT

I don't think I'd call that useless. Point is RTC keeps running during debug mode (which is why processors with a SysTick function often have a flag to disable it in debug) and your code doesn't defend against being late servicing the interrupt by more than the next timer delay. 1/128 second is pretty long so the chances of missing one outside debugging is pretty low, not zero however, if you end up using the softdevice that can in worst case take about 6ms, if you have other pending interrupts, you could miss it.

Many ways to fix it. If you need the interrupt, even late, then detect you aren't going to get it from the RTC because you missed it and just set the interrupt yourself to cause it to run again, you'll catch up soon enough. If you don't need every pulse then just ensure you add multiples of 256 until your next interrupt time is in the future (by at least 2 clock pulses).

RE: RTC Compare Interrupt Doesn't Happen After Debugger Halted

WestCoastDaz — Thu, 02 Apr 2015 22:20:42 GMT

RK,

You are right, the interrupt does occur after waiting for the counter to wrap. In my opinion this is pretty useless for debugging if you need to wait for the counter to wrap. I haven't encountered this in type of issues in my 10+ years of embedded system development.

RE: RTC Compare Interrupt Doesn't Happen After Debugger Halted

RK — Wed, 01 Apr 2015 06:17:07 GMT

So the registers show the interrupt is pending - not quite sure where you are at this point however. I don't think the interrupt enable registers are showing there so can't tell if it is or not, I'm assuming it is.

One thing which stands out, if you run that code and then break, what I'd expect to happen is the interrupt to pend, as soon as you resume the interrupt handler to get called, you add 256 to the CC[0] register but that represents 1/128 of a second, so you've already missed that starting and stopping the debugger. So I'd expect you not to see the next interrupt for about another 512 seconds (less the time you were stopped).

That's not what you described in the original post, but is that what you are seeing?

RE: RTC Compare Interrupt Doesn't Happen After Debugger Halted

WestCoastDaz — Wed, 01 Apr 2015 02:50:09 GMT

RK,

Thank you for talking the time to comment! I looked into the items that you detailed in point 2 of your comment and I can't find an interrupt of higher priority and interrupts don't appear to be disabled.

I have added main.c to this thread below as well as additional register views to the initial question.

RE: RTC Compare Interrupt Doesn't Happen After Debugger Halted

RK — Tue, 31 Mar 2015 04:07:28 GMT

works fine for me - do this all the time - doing it right now. I can stop the debugger as long as I like, no problem getting the compare interrupt afterwards.
As your display shows, the compare event is triggered and the interrupt enable bit is set. Whilst those things are true, the interrupt will be triggered. So either it's disabled, all interrupts are disabled, or you have another interrupt on another event, of higher priority, which is constantly triggering because the event isn't cleared.