MCF52259 PLL fails to lock after change to MCF_CLOCK_SYNCR

[Dr_YanivL]

I'm running the MCF52259 on my own board with a 48 MHz crystal.  Npormally, I'm dividing down to 8 MHz, then multiplying up to 80 MHz.  Here's the code I run out of reset:

MCF_CLOCK_CCHR = 0x05; // The PLL pre divider - 48MHz / 6 = 8MHz

MCF_CLOCK_SYNCR = MCF_CLOCK_SYNCR_MFD(3) | MCF_CLOCK_SYNCR_DISCLK | MCF_CLOCK_SYNCR_CLKSRC| MCF_CLOCK_SYNCR_PLLMODE | MCF_CLOCK_SYNCR_PLLEN ;    //80 MHz clock

while (!(MCF_CLOCK_SYNSR & MCF_CLOCK_SYNSR_LOCK))
    {
    }

So far, so good.  Now I'm trying to change the PLL setting once the processor is running (in order to reduce power con sumption).  In order to do this, I change the CCHR pre-divider to 8 (7+1), MFD to 0 and RFD to 7, resulting in a system clock of: 6MHz / 32 = 187500 Hz.  Replacing the previous startup code:

MCF_CLOCK_CCHR = 0x07; // The PLL pre divider - 48MHz / 8 = 6MHz

MCF_CLOCK_SYNCR = MCF_CLOCK_SYNCR_MFD(0) | MCF_CLOCK_SYNCR_RFD(7) | MCF_CLOCK_SYNCR_CLKSRC| MCF_CLOCK_SYNCR_PLLMODE | MCF_CLOCK_SYNCR_PLLEN;    //6 MHz / 32 = 187.5 kHz clock

while (!(MCF_CLOCK_SYNSR & MCF_CLOCK_SYNSR_LOCK))
    {
    }

which appears to run just fine.  I am able to use this system clock as input to the RTC with MCF_RTC_RTCGOCL = 0xB71B and this causes my little LED to blink happily at 1 Hz.

So now I try this same code while running at 80MHz.  This time, there are no more happy blinky-LEDs.  The power draw does go down, but this may be because the system clock is not functioning.  If I set a debugger breakpoint at the while () loop, I get a trace/breakpoint exception.  If I don't set a breakpoint, I get nada.  I't not stuck in the while() loop; it;s not even getting to the loop.  Just seems like the PLL fails to lock and the core stops executing instructions. after the write to MCF_CLOCK_SYNCR.

According to the Ref Manual, changes to RFD should not cause the PLL to lose lock, so I tried tried limiting the changes to RFD and leaving MFD alone, to no effect.  I also tried disabling the PLL before making changes, but this did not do it either.

I might try making moire gradual changes to frequency, say one RFD or MFD value at a time, in the hopes that a gradual change will be easier to recover from.  The documentation seems to indicate that when the PLL loses lock, it's just a  matter of time before it will eventually regain lock.

Any ideas?

Thanks,

Yaniv

[Dr_YanivL · Accepted solution]

I did get it to work in the end by avoiding changes to CCHR.  Changing MFD and RFD works just fine and the PLL regains lock.  I was able to transition from 80MHz down to 250 kHz and back with no issues. 

[scifi]

I would not be comfortable with adjusting PLL on-the-fly. When PLL is unstable, you can have out-of-spec (too short) pulses at CPU clock input. Such pulses can lock up the CPU.

You should switch to a different clock source, adjust the PLL, and switch back to PLL as clock source.