PLL problems, detection and recovery

[dwhite]

CPU: MC9S12XDT256

Xtal: 16MHz with PLL set for 40MHz

Compiler: Codewarrior v4.5

We have found that the pll is very sensitive to slight changes in capacitance. Touching the XTAL cap with a scope probe causes the PLL to lose its lock. So, I am implementing some detection and recovery logic. I have enabled the loss of lock interrupt and self clock mode change interrupt. In the lock ISR I just run through the PLL init code again and this seems to work. In the SCM ISR, I thought I should wait in a loop until CRGFLG SCM bit is cleared and flash LEDs to indicate a severe clock problem. When I ground the XTAL, it does seem to run from the self clock because one of my LEDs runs about 1/25th of the normal frequency but the SCM ISR never seems to run.

This is a real-time control system so this clock sensitivity must be handled properly. When I get these ISRs running and can understand what is going on, I will implement some fail-safing in these interrupts.

Bottom line, I really need to make sure that the PLL is robust as possible and recovers when it can and fails safe when it can't. If anyone can provided a recommended setup for this, please help.

My PLL code:

Code:

#define PLL_TIMEOUT 50000#define PLL_LOCK_STATUS (CRGFLG_LOCK)#define PLL_CLEAR_FLAGS (CRGFLG = CRGFLG_RTIF_MASK | CRGFLG_PORF_MASK | \CRGFLG_LVRF_MASK | CRGFLG_LOCKIF_MASK | CRGFLG_SCMIF_MASK )/* Initializes the system clock in the CRG module */void Init_pll(void){uWord counter=0;/* Set PLL to give 40MHz from 16MHz Xtal *///Init multSYNR = 4;//Init DivREFDV = 1;//Enable auto tracking mode, turn on pll, clock monitor, self clock modePLLCTL = PLLCTL_AUTO_MASK | PLLCTL_PLLON_MASK | PLLCTL_CME_MASK | PLLCTL_SCME_MASK;//Wait for PLL lockwhile((PLL_LOCK_STATUS == 0) &&(counter < PLL_TIMEOUT)){counter++;}//Clear interrupt flagsPLL_CLEAR_FLAGS;//Enable loss of lock interrupt & self clock mode change interruptCRGINT = CRGINT_LOCKIE_MASK | CRGINT_SCMIE_MASK;if(PLL_LOCK_STATUS){//Enable PLLCLKSEL |= CLKSEL_PLLSEL_MASK; } ECLKCTL_NECLK = FALSE; //turn on ECLK output} /* end Init_pll *//*************************************************************************************/#pragma CODE_SEG __NEAR_SEG NON_BANKED /* these functions have to be allocated in the non banked area */INTERRUPT void PLL_Lock_ISR(void){/* try to restart pll */Init_pll();_asm("bgnd");} /* end CPU12PLLLockISR */INTERRUPT void PLL_SCM_ISR(void){uWord i;/* wait here while in self clock mode */while(CRGFLG_SCM){_asm("bgnd");/* flash both red and green LED to indicate a severe problem */for(i = 0; i < 60000; i++);if(IS_PIN_HIGH( LED_PORT, RED_LED_PIN)){SET_PIN_LOW(LED_PORT, RED_LED_PIN);SET_PIN_LOW(LED_PORT, GREEN_LED_PIN);}else{SET_PIN_HIGH(LED_PORT, RED_LED_PIN);SET_PIN_LOW(LED_PORT, GREEN_LED_PIN);}} /* try to restart pll */Init_pll();} /* end CPU12PLLLockISR */#pragma CODE_SEG DEFAULT /* switch back to default segment */

 

Message Edited by Alban on 2006-08-10 08:16 AM

[Alban]

Hello,

I would be curious to know which kind of scope probe you are using.
Please state its characteristics and the values of the Capacitors you use with the XTAL.

It is completely normal and expected to have problem if you touch the crystal with usual scope probes.
If the scope probe is not dedicated to oscillators, you generally have 10pF of capacitance (compared to <1pF), this is NOT a "slight" change for the oscillator which is typically using capacitors around 22nF.

Still, it is very good practise to implement the clock monitor code in case of hardware failure in the oscillator (broken crystal with chock...).

To make sure the PLL is robust you should respect the state of the art in the choice of the oscillator components, the PCB layout of the oscillator and power/signal tracks, distance from the oscillator to the MCU.
Then you need a proper choice of PLL XFC Filter. This filter defines the reaction time and stability of the loop.

Finally, in case a Loss Of Lock occurs you can run some fail safe code to execute non time critical tasks. When the oscilator is back up there is nothing safer than doing a proper RESET of the whole MCU. If the external noise was high enough to crash the oscillator (which is not sensitive on the MC9S12XDT256), it could have created other trouble in your application.

Cheers,

Alban.

[dwhite]

We have a 16MHz loop controlled Pierce with 33pF on both XTAL and EXTAL to ground. The PLL filter has a 4.7K resistor and 1500pF series cap with a 100pF parallel cap. Is the full swing Pierce more robust? My hardware guy is reviewing things like conformal coating, PCB layout and component selection. It is somewhat disconcerting to know that the PLL loss of lock is "normal". But lets assume that we have to live with it.

My question was on the software not the hardware. Assuming that it is possible to loose the PLL lock, I need to determine if this mode can be recovered in time to not cause catastrophic effects on our control system (50-100uS) or if I just need to immediately go into fail safe mode. In the case of the self clock mode, I would like to use the self clock mode ISR to force the system into fail safe and then reset before our external watchdog times out. Could you please comment on the register settings required to do that and why my test code SCM ISR doesn't execute?

-Dan

[Alban]

The loss of lock is expected because by adding the probe you completely change the characteristics of the oscillator circuitry !

Nothing disconcerting that the oscillator changes when you put 10pF in parallel with 33pF... I doesn't happen in the applications life, so there is no worry to have.

It's really up to you to decide how you want the application to react. You could for instance if you lose LOCK only wait for it to come back, and if you lose the crystal go into SCM. These are two different cases and interrupts.

I don't have the time to check your code just now.

What do you think about having these two degrees of gravity ?

Loss of Lock = LOL => we wait for sometime and if not quick got to failsafe for instance

Loss of Crystal => SCM Self Clock Mode and call the dogs +  the police

Cheers,

Alban.