Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT


Delays not correct although Tick is accurate (PIC32)

Posted by erupter on June 10, 2014


I have setup my application and it's working fine. My peripheral clock is 40M, and the cpu clock is 80M. The tick is correctly generated at 1000Hz, I verified with a scope.

So even if everything appears correct, my task uses a delay of 500ms const TickTypet smallDelay = 500 / portTICKPERIOD_MS;

yet in reality the task is switched at 250ms. I tried with both delay and delayuntil, but the result is the same.

I am quite baffled by this, I don't get where this factor of 2 comes in. The only way to solve it is to put the peripheral clock in the FreeRTOSConfig at 80M. But that's not true:

#pragma config 		FNOSC    = PRIPLL       	// Oscillator Selection
#pragma config 		FPLLIDIV = DIV_2        	// PLL Input Divider (PIC32 Starter Kit: use divide by 2 only)
#pragma config 		FPLLMUL  = MUL_20       	// PLL Multiplier
#pragma config 		FPLLODIV = DIV_1        	// PLL Output Divider
#pragma config 		FPBDIV   = DIV_2        	// Peripheral Clock divisor
And the main OSC is an 8MHz xtal, so divided by 2 gives 4M, and multiplied by 20 gives 80M main clock. The peripheral clock is then divided by 2 so that gives 40M as correctly stated in the config.

#define configTICK_RATE_HZ			( ( portTickType ) 1000 )
#define configCPU_CLOCK_HZ			( ( unsigned long ) 80000000UL )
#define configPERIPHERAL_CLOCK_HZ		( ( unsigned long ) 40000000UL )

Anyone knows what's happening? And please how do I avoid code to appear in bold in this forum?

Delays not correct although Tick is accurate (PIC32)

Posted by rtel on June 10, 2014

[The mark up for the form take a single

as meaning header style 1 - which is the biggest. It is very annoying for a forum where a good proportion of the posts start
. To avoid it you can place your code between "pre" tags for pre-formatted (html tags). You can also put code between four tildas characters to have the same effect. Alternatively you can convert your code to html using a site such as http://hilite.me/]

It sounds like your tick interrupt is simply running at twice the frequency you think it is. I don't know which part number you are running on, but if it behaves differently than the part on which the official demo is running then maybe your peripheral clock is genuinely running at the same frequency as the core. In any case, hardware specific set up questions are outside the scope of this forum, so I would recommend asking on the Microchip forum. I would not confuse things on the microchip forum by mentioning FreeRTOS though - just stick to the hardware specifics saying you are generating an interrupt from the timer but it is running at twice the frequency you expect. That way you will get a more focused answer.


Delays not correct although Tick is accurate (PIC32)

Posted by erupter on June 10, 2014

Well thank you for the heads up.

For future reference here is a Microchip topic that covers the issue: http://www.microchip.com/forums/m638817.aspx

Delays not correct although Tick is accurate (PIC32)

Posted by tlafleur on June 10, 2014

Look at the demo code for the PIC32mx, it work! So this should be a base for you to work with.. Get it working first on a demo board. I Have use it as a starting point in a number of PIC32MX and now with PIC32MZ projects.. FreeRTOS works very well with the PIC32....

Add a bit toggle in the tick interrupt and re check the clock with a scope... Their are so many variables in setting up a PIC32, that it's very easy to miss something....

I have also found that some xtal do not oscillate at the correct frequency, causing issues...( I now only use external oscillators on my projects prototypes)


alternate (1781 bytes)

Delays not correct although Tick is accurate (PIC32)

Posted by chaabanemalki on June 16, 2014

I think that I had the same problem while ago. and I found out that vHardwareConfigurePerformance() function used by FreeRTOS demo configures the peripheral clock after the fuses configuration. If you're using prvSetupHardware() which include vHardwareConfigurePerformance() then check after executing it if the FPLLIDIV value changes.

[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]

Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS