K22 PLL status strange behavior - PLL stay locked without input signal

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

K22 PLL status strange behavior - PLL stay locked without input signal

1,206 Views
laluquethibaut
Contributor III

Hi,

We made some tests on FRDM-K22 dev board and we have observed a strange behavior regarding the PLL lock status (MCG_S_LOCK0 flag). It seems that the PLL stay locked without valid input signal.

Our configuration is the following :

  • the XTAL crystal oscillator of our FRDM-K22 board has been removed and replaced by a digital clock generator that provide a 38.4MHz on EXTAL0.
  • MCGOUTCLK is configured to use the internal 4MHz clock.
  • OSC0 module is configured in external clock mode.
  • The PLL is configured to use this external clock to produce a 120MHz clock (div 16, mult 50).It's enabled by MCG_C5_PLLCLKEN0 = 1 bit. Module is configured to generate interrupt on PLL lock out (MCG_C6_LOLIE0 = 1 and NVIC MCG_IRQ enable).
  • The FLL is configured to use external clock to produce 96MHz (div 1024, mult 2560).
  • Low power is disabled (MCG_C2_LP = 0).

While 38.4MHz is not enabled, PLL is not lock (MCG_S_LOCK0 = 0), that's ok. When we activate the clock generator, PLL is locked on the 38.4MHz to produce a 120MHz (MCG_S_LOCK0 = 1), that's ok too.


When we disable the clock generator, PLL stay locked (MCG_S_LOCK0 = 1) for a while (at least 1 min) and interrupt is not generated while MCG_S_LOCK0 return to 0.

It's sure that the PLL is no longer locked because if we switch MCGOUTCLK on PLL output, MCU is immediately stopped when we turn off the clock generator.

Is someone experiencing the same issue ?
Is there any way to immediately detect a loss of PLL lock ?
When MCGOUTCLK is using PLL output as clock source, is there a way to switch back on an other clock source without resetting the device ?

Thanks

Thibaut LALUQUE

3D Ouest

0 Kudos
9 Replies

1,056 Views
nxf56274
NXP Employee
NXP Employee

Hi,

 

Unfortunately, you may be right.

 

Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 days after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos

1,056 Views
nxf56274
NXP Employee
NXP Employee

Hi,

 

 Using interrupt to switch the clock may can't be realized. When in the interrupt, the clock is lost. Only very simple instruction can be used. Changing clock is a set of complex instructions. If use reset, how about enabling CME0  and LOCRE0?

 

Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 days after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos

1,056 Views
laluquethibaut
Contributor III

Hi Da Li,

The scheduler onyl raise flags in interrupt and then, flags are dealed in the main loop.


When we enable LOCRE0 and CME0 a reset is immediately generated when we loss the 38.4MHz.


I also try to generate an interrupt on loss of clock on OSC0 (LOCRE0 = 0 and CME0 = 1), in this case, interrupt is not generated and the CPU is stucked, this is the watchdog that is reseting the device.

Do you know how the Kinetis K22 manage a loss of clock when this is the main CPU clock that is lost ? Is the device switch automatically on a other backup clock ?

For our application (that is a network of processors, all synchronized on the 38.4MHz) we would to detect loss of synchronization (loss of clock or loss of PLL lock) without resetting the device that must continue to work in a degraded mode.

Thanks

0 Kudos

1,056 Views
nxf56274
NXP Employee
NXP Employee

Hi,

 

You know the code will become machine instruction. And instruction depend on the mcu clock. If we lost the OSC, the instruction won't be executed. So setting the flag in the interrupt doesn't work. Because setting the flag is a set of instruction. So your project is difficult to realize.

Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 days after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos

1,056 Views
laluquethibaut
Contributor III

Hi Da Li,

Thank for your reply.

Yes, I know all of that.

I ask these questions because some MCU integrate a clock guard that automatically switch the CPU on an internal backup clock source in case of the CPU loses it's primary clock.
That allow to the devices to continue operation in a degraded mode.


From our last conversions, I understand that the K22 devices haven't this feature, does it ?
I also understand that interrupts for PLL lock loss and OSC0 clock loss can't be dealed in case that CPU is running on these clock. does it ?

Thanks

0 Kudos

1,056 Views
nxf56274
NXP Employee
NXP Employee

Hi,

FRDM-k22 has the function to detect the lose-of-locks(LOL). You can see the reference manual 6.2.2.6. Here is my suggestions. k22 has two way to solve the  LOL -- Interrupt and reset. You can set the bit to test when we lose the PLL if the mcu reset. If reset,  your configure correctly. Then change it to interrupt. And in the interrupt function, put your change clock code into it. Don't forget to clear the LOLS0. Using debugger to debug the mcu when the mcu is LOL may not a good ideal.

Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 days after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos

1,056 Views
laluquethibaut
Contributor III

Hi Da Li,


Thanks for your reply.

As you suggest me, I made the first test to check if device reset on PLL loss of lock.

I configure the MCG module to work on internal 4MHz until we detect a PLL lock on the external 38.4MHz.
When PLL is locked, device switch the MCGOUTCLK on the PLL output, at this time MCU is running at 120MHz.
When switch is complete, I configure the MCG module to generate a reset on LOL (MCG_C8_LOLRE = 1). I make sure to disable interrupt (MCG_C6_LOLIE = 0) and CME0 module.
When I disable the clock generator, MCU is freezing until watchdog reset it (5s). After the reset, only the WDOG flag in RCM module is set indicating that the reset source is coming from watchdog module.

I haven't found any information in the documentation about the behavior of the device when the MCGOUTCLK is running on PLL output and that the PLL loss lock.
Is the device automatically switch on an other clock source to maintain CPU operation in a degraded mode ?
I suspect that this is not the case, and when CPU loose it's clock, it's stay freezed until clock back, is that right ?

Thanks

0 Kudos

1,056 Views
nxf56274
NXP Employee
NXP Employee

Hi,

 

Configure Internal -> detect a PLL -> PLL output. Do you use a while loop to detect the PLL and if mcu don't detect the pll, it won't go on running ? If so, here is my thoughts. When you remove the generator, the mcu reset in fact. But mcu stuck in detecting PLL on the next reset. Then watchdog works. Reset the MCU. So it becomes watch dog to reset the mcu. RCM won't display the other reset signal.

 

Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 days after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos

1,056 Views
laluquethibaut
Contributor III

Hi Da Li,

No, that's not the case, After reset, device start to work in FEI mode.


During my setup, I start to configure the MCG module to use internal 4MHz as clock source for MCGOUTCLK. I configure the PLL too to produce a 120MHz clock using the external 38.4MHz as reference.
After this setup, the PLL is ready to engage external clock but not yet engaged. The CPU already running on the internal 4MHz.


With a little scheduler (using LPTMR clocked by LPO) I blink the board leds to show device status. after the setup, it's blinking red to indicate that PLL is not yet lock.


I check every 100ms if PLL is locked or not with MCG_S_LOCK0 flag, if we detect a lock, we swtich the MCGOUTCLK on the PLL output, while PLL is locked, the green led is blinking.


After PLL lock, we enable the loss of lock reset (MCG_C8_LOLRE = 1) and make sure that the loss of lock interrupt is disabled (MCG_C6_LOLIE0 = 0).


Watchdog is refreshed every 250ms for a timeout of 5s and it's clocked by LPO. I have tried to disable it and in this case, the device never reset after a PLL loss of lock.

thanks.

0 Kudos