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

Like • Show 0 Likes0
Comment • 4

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

No one else has this question

Outcomes

David Tosenovjan

Dec 4, 2017 5:30 AM

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.

1 person found this helpful

Actions

Michael Coury @ David Tosenovjan on Dec 4, 2017 7:12 AM

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

Actions

David Tosenovjan

@ Michael Coury on Dec 4, 2017 7:54 AM

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;
}
}

2 people found this helpful

Actions

Michael Coury @ David Tosenovjan on Jan 17, 2018 8:57 AM

David Tosenovjan

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?

Actions

4 Replies

David Tosenovjan Dec 4, 2017 5:30 AM
Mark Correct
Correct Answer
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.
1 person found this helpful
Like • Show 1 Like1
Actions
- Michael Coury @ David Tosenovjan on Dec 4, 2017 7:12 AM
  Mark Correct
  Correct Answer
  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...
  Like • Show 0 Likes0
  Actions
  - David Tosenovjan @ Michael Coury on Dec 4, 2017 7:54 AM
    Mark Correct
    Correct Answer
    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;
        }
    }
    2 people found this helpful
    Like • Show 1 Like1
    Actions
    - Michael Coury @ David Tosenovjan on Jan 17, 2018 8:57 AM
      Mark Correct
      Correct Answer
      David Tosenovjan
      
      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?
      Like • Show 0 Likes0
      Actions

Steps to recover from loss of PLL0 lock with MPC5643L

Outcomes

Related Content

Recommended Content