Interrupt stops scheduler - FreeRTOS 5.3.0

bugtraker wrote on Monday, November 02, 2009:

Hi all,

I’m running freertos on AT91SAM7S64. I run a system with few tasks (no interrupts yet): reading keypresses, using 1x16lcd, led blinking.
Now I want to add RTT, so interrupt has to be involved. Because I use GCC I use wrapper, and ‘naked’ all fine.
So, I let the system to run for ~10sec, all tasks switch ok, and when first RTT interrupt trings, the system stops switching tasks. But it does not crash. Last system settings are visible e.g. text on LCD, and RTT interrupt is working as programmed: it triggs every 1sec, and blinks LED. So my guess is that somehow my RTT irq disables the scheduler, how do I fix this?

rtel wrote on Monday, November 02, 2009:

I would guess (and it is a guess) that the RTT interrupt is not being cleared correctly.  It has to be cleared in both the RTT itself and also to AIC.

Does the RTT share the system interrupt, or does it have its own interrupt vector?


bugtraker wrote on Tuesday, November 03, 2009:

That was helpful. RTT wasn’t cleared properly, because it shared interrupt with SYS. So now I have modified SYS interrupt so that RTT is checked.
However, now system reboots randomly if I serve RTT in SYS irq without any function calls. If I do call a function that serves RTT then I get a data_abort.

As I said I use GCC, but no preemption, so do I have to SAVE and RESTORE context?
What bad can happen when other interrupt shares vector with SYS?

davedoors wrote on Tuesday, November 03, 2009:

Search far back in this forum, there have been threads on sharing the system interrupt before.

bugtraker wrote on Wednesday, November 04, 2009:

I did search back, and a suggestion was made to add a ‘dispacher’ but in freertos 6.0 shared interrupts for SYS are still not supported.

bugtraker wrote on Thursday, November 05, 2009:

OK that is the thread I’ve found . All fine and I’ve done the same, but I’m still gettings random crashes. This is modified portISR:

void vNonPreemptiveTick( void )


unsigned portLONG ulDummy;

/* Increment the tick count - which may wake some tasks but as the

preemptive scheduler is not being used any woken task is not given

processor time no matter what its priority. */

                if (0 != (AT91C_BASE_PITC->PITC_PISR & AT91C_PITC_PITS))

                    ulDummy = AT91C_BASE_PITC->PITC_PIVR;

                if (0 != (AT91C_BASE_RTTC->RTTC_RTSR & AT91C_RTTC_RTTINC))
    ulDummy = AT91C_BASE_RTTC->RTTC_RTSR;
                    ulDummy = AT91C_BASE_RTTC->RTTC_RTVR;
/* End the interrupt in the AIC. */



The only difference is that I’m using non preemptive kernel.


bugtraker wrote on Wednesday, November 11, 2009:

Found the problem - spurious interrupt. For whatever reason PIT and RTT together where causing spurious irqs.

In pvrSetupTimerInterrupt() I have added`        AT91C_BASE_AIC->AIC_SPU = AT91C_BASE_AIC->AIC_SVR;`
And that fixed the problem. I will change this to specific spurious irq handler, but for time being it does the job - system does not crash at all.

jon_newcomb wrote on Thursday, July 22, 2010:

Out of interest, what did you set you default handler to?

In the end I created my own…
__irq __arm void

(For IAR). but I’m not sure how to test it… or if it is going to upset FreeRTOS…

Found the following, but can’t see how the provided solution works… (no __irq keyword…),15/t,3180/
(Title: “Odd interrupt enabling / disabling issues causing chip reset”)