rgrover1 wrote on Tuesday, June 22, 2010:
Hello,
I’m working with AVR32_UC3 and GCC. I’ve got a FreeRTOS port from Atmel at version 6.0.0; and it seems to work fine for a simple app which blinks LEDs.
I want to upgrade to 6.0.5; but my led-blinker app fails.
The problem is caused by the changes in port.c to the mechanism used to generate ticks.
It has to do with prvScheduleNextTick(); which replaces the previous scheme implemented by prvClearCcInt().
I’ll include the code from the two:
__attribute__((__noinline__)) static void prvClearCcInt(void)
{
Set_system_register(AVR32_COMPARE, Get_system_register(AVR32_COMPARE));
}
Vs.
__attribute__((__noinline__)) static void prvScheduleNextTick(void)
{
unsigned long lCycles, lCount;
lCycles = Get_system_register(AVR32_COMPARE);
lCycles += (configCPU_CLOCK_HZ/configTICK_RATE_HZ);
// If lCycles ends up to be 0, make it 1 so that the COMPARE and exception
// generation feature does not get disabled.
if(0 == lCycles)
{
lCycles++;
}
lCount = Get_system_register(AVR32_COUNT);
if( lCycles < lCount )
{ // We missed a tick, recover for the next.
lCycles += (configCPU_CLOCK_HZ/configTICK_RATE_HZ);
}
Set_system_register(AVR32_COMPARE, lCycles);
}
Reverting port.c in 6.0.5 to use prvClearCcInt() makes everything work like normal.
On the surface, it seems that prvScheduleNextTick() certainly has a minor bug about not taking counter wrap-around into consideration-when the COMPARE register value wraps around due to the increment we might end up generating the next tick TWO ticks later. But I can’t figure out why my app completely fails to work with the new scheme.
Can someone please help? Thanks.