SysTick interrupt dying

[zsmith]

Posted on March 26, 2009 at 17:59

SysTick interrupt dying

[zsmith]

Posted on May 17, 2011 at 13:07

I am using SysTick for my system timer. It starts up no problem and every x ms the SysTickHandler is invoked. But as my program runs there is apparently something in my code that is causing it to quit invoking the Handler. After a while the Handler just stops getting called.

I watch the SYSTICKCSR and I can see the Countflag get set when the timer counts to zero but the handler does not get called. When it gets to this state, the Interrupt Control State Register value is 0x0400F80F which I think means that the systick interrupt is pending. I can't figure out what would be causing it to quit invoking the ISR. Any ideas? Or any ideas on what I could check to try to figure this out?

[darcy]

Posted on May 17, 2011 at 13:07

Once you notice the problem has occurred, check the systick status registers to see whether the interrupt has actually been disabled. It would also be worth while checking the NVIC settings to see if it has been disabled there.

[zsmith]

Posted on May 17, 2011 at 13:07

The systick status register SYSTICKCSR says that it is still enabled. I am not sure what you mean my checking the NVIC settings.

[joseph239955]

Posted on May 17, 2011 at 13:07

1) Check that PRIMASK is not set. If it is set, then all interrupts are disabled. It might happen if you have code that disable all interrupt (e.g. __disable_irq()).

2) Beside from PRIMASK, ther are two other interrupt mask registers inside the Cortex-M3 called FAULTMASK and BASEPRI. If they are set they can disable the SYSTICK exception as well. 3) Check the IPSR (current interrupt number). You can find this in the bit 8 to bit 0 of Interrupt Control and State Register (ICSR) in the NVIC. There might be chance that one of your interrupt handler didn't do a correct interrupt return and hence the current priority level is stuck. If the IPSR is non-zero, check the handler assoicated with that exception number carefully to see if the interrupt return code is incorrect. 4) Bit 3 of Debug Halting Control and Status Register. This is suppose to be used by the debugger during debug. If this bit is set during operation it might affect the SysTick. (unlikely because debugger should not leave this bit on, unless the debugger has a bug or got disconnected from target unexpectedly). Hope this help.

[zsmith]

Posted on May 17, 2011 at 13:07

thanks for the replies. I will check those things. I will update if I find the problem.

[zsmith]

Posted on May 17, 2011 at 13:07

joseph, you are right, the IPSR is stuck at 15 (systick). hmmmm...

[zsmith]

Posted on May 17, 2011 at 13:07

Does anyone know if there is a way to write to the IPSR?

[joseph239955]

Posted on May 17, 2011 at 13:07

Hi again. If you do an interrupt return correctly, IPSR will be cleared and you don't have to write to it. You can only change IPSR by exception entry/exit, or by debugger.