PLL falls out of lock 9s12xhz

[Quimney]

I am running a 9s12xhz512. It runns a short piece of startup code then sets the PLL to 40mhz bus speed (8mhz xtal) and sets the system clock to that. I then do a ram and rom test and everything is fine until I enable the RTI (and only the RTI). 2.1us after the RTI occurs the PLL falls out of lock and then 104us later it re-aquires lock but can only hold it for ~2us before falling out again. This falling in and out of lock continues forever even if I  disable RTI after the first failure.

I have verified that if I never enable the RTI it will hold lock forever. All that is in the RTI routine is clearing the RTI flag and toggling a pin on portb.

I am collecting this data with a scope using port pin toggles in the RTI and PLL_lock_interrupts.

I get the same results with or without the BDM connected.

We have checked our PLL component values and belive them to be correct. I have 5 other products using different circuit boards and different code and none of them are showing this issue. I can find no difference between them in either cicuitry, component values, or code related to the clocks and PLL.

I am really stumped here... any great ideas?

[DPB]

Hello

If the application uses Wait mode and PLLWAI is set then the PLL is disabled during Wait mode.

When code execution resumes following Wait then the PLL is automatically activated again. 

Repeated Wait mode entry could then cause it to repeatedly fall out of lock.

Is Wait mode is used in the application?

Is PLLWAI set?

DPB

[Quimney]

Thank you for your well reasoned response. Unfortunately we are not using wait mode at all.

CLKSEL = 0x80

PLLCTL = 0xE0

DKM

[Quimney · Accepted solution]

Eureka!

I think we have figured out what was happening to us.  We discovered that we had the compiler option "PPAGE register is used for paging" selected, however it was assigning the wrong address to the PPAGE register.  The address assigned to the PPAGE actually belonged to the REFDV register. It was set to 0x35 but it should have been set to 0x30 for the MC9S12XHZ512.

After comparing compiler listings with and without that option we discovered every interrupt routine was protecting that register value.  At the start of each interrupt it would push the register onto the stack and before leaving it would restore it from the stack.

In basic terms, this meant that every interrupt routine that ran was writing to the REFDV register. 

In the Freescale documentation there is a note that says:

”Write to this register initializes the lock detector bit and the track detector bit.“

It’s been difficult to determine precisely what this means but our testing has shown a write to REFDV will cause both the lock and track bits to be cleared for a time. Our PLL based PWMs had jitter that is gone now. I think that means we were restarting the tracking/lock mechanism with each interrupt

Bottom line; correcting the PPAGE register address in the compiler options resolved the issue. On a new CodeWarrior project this was set to 0x35 by default when we turned it on.