We are working on a project using FreeRTOS on an Atmel AVR32 UC3A0512 CPU.  The sample FreeRTOS code supplied by Atmel is built on V4 of FreeRTOS.   I decided that we should upgrade to FreeRTOS V5, since it would be beneficial to get access to its stack and heap check features. I downloaded the latest V5 FreeRTOS, and have replaced all the FreeRTOS files with their V5 counterparts.  I also fixed all the FromISR() calls, as directed.  The project now builds, and even runs.  However, the FreeRTOS timer tick rate is incorrect.  I have configTICK_RATE_HZ set to 1000, and with V4 I got 1ms ticks very nicely.  With V5, I don’t.  With configTICK_USE_TC set to 0, I get a tick period of about 800ms!  With configTICK_USE_TC set to 1, I get a tick period of 0.5ms (better, but not quite). I also found that the new port.c references a symbol called "INT0", which does not appear to exist in any of Atmel’s header files.  I replaced it with AVR32_INTC_INT0, because that seemed a reasonable replacement (and it’s defined as 0).  There were more problems with exception.S, so I decided to keep my V4 version of exception.S. Any idea whether I’m doing something wrong, or whether maybe the V5 AVR32 port has not been fully tested? My thanks in advance for any suggestions. -- Bert Menkveld P.Eng. Greentronics bert@greentronics.com

Which V4 version do you have? Looking at http://www.freertos.org/History.txt would indicate it had not changed since V4.45.

Thanks for the pointer to this history log — I was looking for something like that. You’re right that the history log doesn’t mention any AVR32 changes since V4.5.0.  The Atmel release uses FreeRTOS V4.7.2, but it seems that Atmel may have updated some of the files themselves. Does anyone have any experience with upgrading the FreeRTOS version used in an AVR32 project? -- Bert Menkveld

Take a look at the "Known issues" list – there is only one thing on it at the moment and it is related to the IAR header file version!   http://www.freertos.org/a00104.html#knownissues There is a bit of a muddle at the moment regarding the AVR32 versions – the Atmel one has got out of synch and both the IAR and GCC tool chains have been updated and broken the builds.  There was a long thread about it recently.  I’m trying to get it straightened out.  Also note that there are different revisions of the AVR32 which require slightly different configurations. In the mean time I can supply you with old versions of the header files, which fixed the problem for somebody else.  I would also be interested in receiving the files you are using from the Atmel distribution – Source/Portable/[compiler]/[chip].  Email address is r *dot* barry [at] freertos.org. Regards.

Hi, converning the Tick Rate, I have exactly the same problem as you describe. I use a Atmel AVR32 UC3A0512 and I changed FreeRtos from 4.7.2 to 4.8.0 and the scheduling has become very slow. I have "configTICK_USE_TC " set to 0 in order to use the COUNT&COMPARE match interrupt. I saw the changes in port.c as well, but cant see why the timing goes wrong. Have you been able to fix that problem, or has anybody an idea on that item ? Thank you very much in advance. Best regards Karsten

Does this help http://sourceforge.net/tracker/?group_id=111543&atid=659633

No, I dont think so, because I use configTICK_USE_TC = 0. So the timer-counter is not used for scheduling. The COUNT&COMPARE match from the CPU is use instead.

Meanwhile I figured out something: static void prvScheduleFirstTick(void) { unsigned long lCycles;     lCycles = Get_system_register(AVR32_COUNT);     lCycles += (configCPU_CLOCK_HZ/configTICK_RATE_HZ);     if(0 == lCycles)     {         lCycles++;             }     Set_system_register(AVR32_COMPARE, lCycles); } The Compare-Reg is set to the COUNT-Reg + the value for the next tick. The Count-Reg is running since reset and has a huge value. -———————————————— static void prvScheduleNextTick(void) { unsigned long lCycles, lCount;     lCycles = Get_system_register(AVR32_COMPARE);     lCycles += (configCPU_CLOCK_HZ/configTICK_RATE_HZ);     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); } The Compare-Reg is set to the Compare-Reg + the value for the next tick. BUT, the Compare-Reg has not changed since the last time, AND die Count-Reg. was cleared automatically with the Count/Compare Interrupt. So the the new compare-value is now far-away from the counter-value. May be I´m totally confused, but I think this might be the problem. Why was the code changed since 4.7.2 on this item ? Best regards Karsten

Hi Bert,
I just tried to add the latest FreeRTOS version 5.4.2 to my application based on the ATMEL port on an EVK1100. I guess I am facing exactly the same problems. I can not yet say if the tick rate is right since I am unable to build the project. However, I replaced INT0 by AVR32_INTC_INT0, too and unfortunately get compile errors for the file exception.s. Did you figure out what was wrong in your case? One of the error messages says:
- invalid numeric expression `AVR32_SR_M0_OFFSET’
- invalid numeric expression `AVR32_SR_M0_SIZE+AVR32_SR_M1_SIZE+AVR32_SR_M2_SIZE’ Perhaps Richard or someone of the ATMEL team has an explanation? Thanks for helping!

The explanation is that there are two variables, and therefore 4 combinations.  The original demo was done with original silicon and early compiler versions.  Since then the libraries for both GCC and IAR have been updated in a way that introduces incompatibilities, and the silicon has been revised which also introduces incompatibilities. Its on my list to provide an alternative demo using the other set of variables.  For now you can take all the header files from the original compiler versions and patch them into the new compiler versions – but make sure you backup the new headers before you overwrite them. Regards.