# AVR32 UC3 Error in prvScheduleNextTick

**URL:** <https://forums.freertos.org/t/avr32-uc3-error-in-prvschedulenexttick/7804>\
**Category:** Kernel\
**Created:** [April 24, 2019, 5:34am UTC](https://forums.freertos.org/t/avr32-uc3-error-in-prvschedulenexttick/7804 "2019-04-24T05:34:34Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [April 24, 2019, 5:34am UTC](https://forums.freertos.org/t/avr32-uc3-error-in-prvschedulenexttick/7804/1 "2019-04-24T05:34:34Z")

</div>

**[meerkoetter](https://sourceforge.net/u/meerkoetter/)** wrote on [Wednesday, April 24, 2019](https://sourceforge.net/p/freertos/discussion/382005/thread/48e91d7259/#3663):

Hello,

I used a V7.x version of FreeRtos so far. Last week I tried to switch my project to V10.2.0. It compiled, but worked in a strange way. After some debugging I found that the function prvScheduleNextTick in port.c is broken. This function is used, if the tick irq is generated by the CPU internal count register (Option configTICK\_USE\_TC==0).  
In the V7.x version the code was correct, but now it assumes that the system register COUNT is free running and can be used to detect missed ticks. That’s not possible, the register is cleared to 0 at each compare match.  
This wrong assumption will lead to a completely wrong tick frequenzy.

---

<div class="post-metadata">

**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\
**Post date:** [April 24, 2019, 3:20pm UTC](https://forums.freertos.org/t/avr32-uc3-error-in-prvschedulenexttick/7804/2 "2019-04-24T15:20:35Z")

</div>

**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Wednesday, April 24, 2019](https://sourceforge.net/p/freertos/discussion/382005/thread/48e91d7259/#3663/1782):

I’ve just checked the latest version of FreeRTOS against version 7.5.0,  
and other than the data types having been updated to use stdint.h types,  
the port has not changed. I suspect your original code came from Atmel,  
not us, as they maintained their own version. Our original version was  
created for ES chips, and the behaviour of the chips changed, while  
Atmel updated their code there were some very elaborate usage of the  
pre-processor in their drivers that we were not able to figure out so  
were unable to update ours.