PIC18 usung PLL hangs

bobbosyn wrote on Friday, August 29, 2008:

I’m using FreeRTOS with a PIC10F87J11.  I have three tasks, an LCD task, an I2C task, and an application task.  All use queues to pass info back and forth.  The external clock source is 10 MHz, and the clock option is ECPLL.  All works well at 10 MHz.  My problem starts as soon as I turn on the 4x PLL (OSCTUNEbits.PLLEN).  The system hangs in several ways.  It can do constant resets, it can corrupt the scheduler suspend variable (uxSchedulerSuspended), or it will hang in the vListInsert function, specifically at the pxIterator for(;:wink: loop. I have checked for stack overflows and other obvious things.  Can this be a timer issue?  Does anyone have a suggestion as to what else to check into?

davedoors wrote on Friday, August 29, 2008:

Did you change the configCPU_CLOCK_HZ parameter in FreeRTOSConfig.h?

bobbosyn wrote on Friday, August 29, 2008:

Yes, I changed it to 40000000 to match the 40MHz core speed.  My tick frequency (configTICK_RATE_HZ) is 100, but I have tried it at 1000 and 500 with no difference in the problem.  I am using the clock interrupt source as is, with the CCP set to compare.  I don’t know if this works properly with the PLL.  I might change that to see what happens.

woops_ wrote on Friday, August 29, 2008:

Check the calculations in prvSetupTimerInterrupt (port.c) to see if the higher 4000000 number is causing an overflow in the timer compare value. Maybe you need to prescale the clock intput to the timer some more?

bobbosyn wrote on Friday, August 29, 2008:

if I set configCPU_CLOCK_HZ to 40000000, and configTICK_RATE_HZ to 500, I get 0x4E20 as the compare value.  I know that seting configTICK_RATE_HZ to 100 will cause a calculation overflow, but that should only cause incorrect tick timing.  I will explore the prescale suggestion, thanks!