AnsweredAssumed Answered

Steps to recover from loss of PLL0 lock with MPC5643L

Question asked by Michael Coury on Dec 1, 2017
Latest reply on Jan 17, 2018 by Michael Coury

We are using a 120 MHz System clock using a 40 MHz crystal and PLL0

 

CGM.AC3SC.R = 0x01000000; /**< Select 4–40 MHz crystal osc as PLL0 source clock */
CGM.AC4SC.R = 0x01000000; /**< Select 4–40 MHz crystal osc as PLL1 source clock */

 

and...

 

CGM.FMPLL[0].CR.B.IDF = 5; /**< FMPLL0 IDF = 5 --> divide by 6 */
CGM.FMPLL[0].CR.B.ODF = 1; /**< FMPLL0 ODF = 1 --> divide by 4 */
CGM.FMPLL[0].CR.B.NDIV = 72; /**< FMPLL0 NDIV= 72 --> divide by 72 */
CGM.FMPLL[0].CR.B.EN_PLL_SW = 1; /**< Enable progressive clock switching */

 

 

 

We are injecting a loss of lock of the PLL0 and I am not getting the micro to recover...  and its not clear what the steps need to do so...

 

I have set up the FCCU and RGM to prevent the micro from immediately resetting... 

 

RGM.FEAR.R = (uint16_t) 0x0000; // Make everything go Safe Mode Request
RGM.FERD.R = (uint16_t) 0x0A78; // Disable The Reset Request

 

And I think this is working because the micro will reset according to the NCF_TO (60 seconds).

 

FCCU.NCF_TO.R = 0x39387000;

 

I have tried to go from SAFE MODE --> DRUN --> RUN0 but I don't know if I should be resetting the PLL0? and I don't know if I need to shut all the clocks down and bring them back up? Essentially re-run the initialization of all the CGM registers?

 

using the debugger has been hard as any mucking with the PLL0 while the debugger is connected usually bricks things and attaching the debugger after the event currently results pausing the micro in no-mans-land... 

 

Any help would be be appreciated...  

Outcomes