Delays not correct although Tick is accurate (PIC32)

Hello 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)

[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
#define
. 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. Regards.

Delays not correct although Tick is accurate (PIC32)

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)

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)

Delays not correct although Tick is accurate (PIC32)

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.