Tick timing error – V5.3.0 AVR32_UC3 port.c
After upgrading an AVR32 UC3A project to use the latest FreeRTOS V5.3.0, I noticed that the delays generated by vTaskDelay were half as long as expected. Further investigation revealed that when the default configuration in FreeRTOSConfig.h has:
#define configTICK_USE_TC 1
#define configTICK_TC_CHANNEL 2 // Note: actually any channel would have the same issue
that the initialization of the timer counter in waveform mode has a mistake. Specifically, when the RC register is loaded on line 446 of port.c, the expression for the value to be loaded into rc assumes that the timer/counter TIMER_CLOCK2 has a frequency of PBA clock/4. The actual rate of TIMER_CLOCK2 is PBA clock/2 per section 12.4.1 of the latest UC3A datasheet.
So, I believe that line 446 of port.c should be:
tc_write_rc( tc, configTICK_TC_CHANNEL, ( configPBA_CLOCK_HZ / 2) / configTICK_RATE_HZ );
With this change made, the timer ticks occur at the expected rate.
David Squires,
Squires Engineering, Inc.
Melbourne, FL
Tick timing error – V5.3.0 AVR32_UC3 port.c
There has been an on going saga with the AVR32 demo due in part to the compiler versions changing and breaking the build and also in part to different silicon revisions working in different ways. I think these are noted in the bug tracker.
Tick timing error – V5.3.0 AVR32_UC3 port.c
Ah, this I can well believe. In researching the parameter values for setting up the UC3A Timer/Counters in waveform mode for my project I noticed that some of the bitfields have different encodings based upon the silicon revision.
So I will add for completeness that my observations apply to an UC3A0512 which is silicon rev I.
Also, I am using AVR32 Studio V2.02 along with the gnu toolchain that was distributed by Atmel for that release.
Thank you for the information.
Dave Squires
Squires Engineering, Inc.