Steps to recover from loss of PLL0 lock with MPC5643L

[michaelcoury]

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...  

[davidtosenovjan]

Hi, it is needed to disable reset reaction in FCCU for the lock-of-lock fault source.

If you handle this NCF in interrupt service routine, it is needed to clear the fault during ALARM interval, then MCU will not reset or not go to SAFE mode.

Then if FCCU fault is removed, you should switch Mode entry back to DRUN mode, re-initialize PLL and switch to RUN0.

[michaelcoury]

David -

I don't think this is my problem.  I need help understanding how to correctly recover the PLL and clear all the faults.  My attempts to clear the fault fail and the FCCU stays in ALARM mode until the NCF_TO expires.... and it resets - which is expected...

[davidtosenovjan]

I am usually using function ClearFails, that is however clearing all possible faults:

static void ClearFails(void)
{
    uint16_t reset_register;
    
    if(RGM.FES.B.F_FCCU_SAFE || RGM.FES.B.F_FCCU_HARD)
    {
        reset_register = RGM.FES.R;
        ME.IMTS.R = 0x00000001;
        ClearCF();
        ClearNCF();
        
        RGM.FES.R = 0xFFFF;
        RGM.DES.R = 0xFFFF;
        
        /* re-enter DRUN */
        ME.MCTL.R = 0x30005AF0; /* Enter DRUN Mode & Key */        
        ME.MCTL.R = 0x3000A50F; /* Enter DRUN Mode & Inverted Key */
    }
}

static void ClearNCF(void)
{
    uint32_t i,b[4];
    for(i=0;i<4;i++)
    {
        FCCU.NCFK.R = FCCU_NCFK_KEY;
        FCCU.NCF_S[i].R = 0xFFFFFFFF;
        while(FCCU.CTRL.B.OPS != 0x3)
        {
        
        };              /* wait for the completion of the operation */
        b[i]=FCCU.NCF_S[i].R;
    }
}

static void ClearCF(void)
{
    uint32_t i,a[4];
    for(i=0;i<4;i++)
    {
        FCCU.CFK.R = FCCU_CFK_KEY;
   
        FCCU.CF_S[i].R = 0xFFFFFFFF;
 
        while(FCCU.CTRL.B.OPS != 0x3)
        {
            
        };      /* wait for the completion of the operation */

        a[i]=FCCU.CF_S[i].R;
    }
}

[michaelcoury]

davidtosenovjan

I appreciate the support....  I have a better understanding of what's going on now....  When we artificially inject the fault (by disruption of the XOSC or the PLL Power Supply), the Safe Mode ISR fires off, we are able to clear the faults, restart the PLL0, and recover.  I use a signal on CAN to communicate when a recovery occurs. 

However, when the fault is real, sometimes we will not recover... my best guess is that whatever interference that is taking out the PLL0 is still present when the recovery attempt starts and we are hitting an illegal ME transfer or are stuck in a while loop waiting for a clock to settle that was presumed to be on and has turned back off. 

What makes this more difficult to diagnose is that in this case, attempting to attach the debugger will cause the micro to reset so we lose all that information.

Thoughts?