rtel wrote on Monday, August 27, 2012:
Ok - that is a completely different matter to anything discussed so far then because T0 (presumably used to create the tick interrupt) is an LPC2000 peripheral, and not part of the ARM7 core.
Based on what you posted above and the code, I cannot find anywhere in the code where the interrupt line of the scheduler’s hardware timer is enabled.
Can you tell me if, up to that point, the tick interrupt was firing and the xTickCount variable in tasks.c is non-zero?
The peripheral timer is configured in prvSetupTimerInterrupt() in port.c, which is called from xPortStartScheduler().
When the timer generates an interrupt (assuming configUSE_PREEMPTION is set to 1) vPreemptiveTick() in portISR.s executes to service the interrupt. The interrupt is cleared in that function (you will see the comments “; Clear the timer event” and “; Acknowledge the interrupt”).
Yes, the reference counter is restored currently but if the scenario above is followed - i.e., a forced context switch using an SVC while the scheduler is disabled for the task that is left -
By reference counter, I presume you mean the critical nesting counter.
By scheduler disabled, I presume you mean a in a critical section (disabling the scheduler has a different meaning in FreeRTOS).
I don’t know what you mean by “the task that is left” though. Do you mean the task that is being switched in, or the task being switched out?
the interrupt line is not actively enabled/disabled before the target task is switched in.
In one post before your last post, you said the global interrupts were enabled, so you are seeing that what you are saying you cannot see happen has actually happened. The global interrupt state is in the PSR register that is saved and restored - so by swapping the PSR register as you swap tasks you are enabling and disabling interrupts - there is not a separate instruction to do this, which is probably why you cannot see it.
If a task is swapped out with interrupts disabled, the PSR register is saved as part of that task’s context (with the interrupt enable bit in the register). If the task being swapped in has interrupts enabled in its copy of PSR, then interrupts are enabled when its own PSR copy is moved into the PSR register. Then, when the original task is eventually swapped back in, its saved PSR register is copied into the real register and, because it was saved with the interrupts disabled and the bit is in the PSR register, interrupts are once again disabled.
Again: the reference counter is restored, but not the underlying interrupt line of the processor does not seem to be adjusted according the latest status of the target task.
Maybe I’m not understanding you because two posts ago you said the interrupt enable line was being re-enabled, but the interrupt of T0 was disabled?