destremps wrote on Friday, June 26, 2009:
AVR32 UC3A0512 port. 200Hz RTOS tick rate.
I have whittled my app down to 1 task and two interrupts during my investigation. One of the interrupts is the FreeRTOS tick. The second interrupt is a 1kHz interrupt into a gpio pin. All the ISR service routine does is raise an IO pin (for the scope), a call to xSemaphoreGiveFromISR, clear the interrupt, and drop the IO pin. Takes about 35usec and we have been very careful to follow the ISR preemption conventions for this port.
The task is also very simple. Its priority is IDLE + 5 (can be idle + anything as it’s the only task). It is blocked on the semaphore. Normally when the ISR finishes (exits) this task runs immediately because it was made ready due to the semaphore give. All the task does is take the semaphore and toggle another IO pin. 99% of the time this task executes within 30usec from the completion of the ISR. Considered a sucessful preemption as we leave the ISR.
The problem is once in a while the preemption does not occur. The task executes 5ms later (think 200hz). I now am generating the 1kHz interrupt with a signal generator and as I vary the interrupt frequency the nature of the mishap changes (happens more or less frequently and pattern varies).
When the preemption is missed 4 or 5 more interrupts happen before the task runs. Those ISRs process much quicker that the 35usec normally observed. About 10usec is all they take. I believe the xSemaphoreGiveFromISR is executing much faster in that mode.
It is interesting that the task always runs exactly 5ms after the GPIO interrupt. I suspect this is a nested interrupt problem with the two interrupts.
UPDATE: I have fixed this problem (I think). And decided to post this anyway as is quite interesting. If you really want to see you RTOS work this simple setup is pretty neat to observe on a scope. THE FIX was to raise the hardware interrupt priority level of the FreeRTOS tick to above that of the GPIO interrupt. The AVR32 will nest interrupts. Apparently it is unacceptable for the tick ISR to be interruptted by the GPIO interrupt (doing the semaphore give and attempting a context switch). BUT it appears to be okay for the GPIO ISR to be interruptted by the tick interrupt. I know this port of FreeRTOS is not supposed to run with nested interrupts but thought by following the ISR conventions laid out for the port all would be good. I’m just happy it all works now!
Any comments appreciated.
Bob