MPC5675K WDT Reset

[pradeepdas]

We are using MPC5675K micro-controller and codewarrior 10.6 as the software development IDE.

During boot-up we are printing the last reset cause by reading RGM_FES(Functional event status) and RGM_DES(Destructive event status) registers.

Internal Watch dog timer is enabled and an ISR is registered for the WDT event for debug prints. Internal watch dog timer over flow was simulated and is working. The values from RGM_FES and RGM_DES are 0x4180 and 0x0000 respectively.

Some times the controller resets without triggering the WDT ISR. Both RGM_FES and RGM_DES are found to have the same values i.e 0x4180 and 0x0000 respectively.

Is this still a internal watchdog reset? Help us to find the reason of reset. Is there any  other way to find root cause of reset?

Thank you.

[pradeepdas]

Hi petervlna,

Now  we are able to inject non-critical fault and able to clear it in FCCU alarm ISR and continue  our normal operation.

Still we are unable to service critical fault.
I am confused with NMI signal generated by FCCU for critical fault. How we can service NMI signal, generated from FCCU (IRQ Vector address)?

Since we have boot loader, safe mode ISR will be branched to boot loader application or on-going user application?

Thanks and Regards

Pradeep

[petervlna]

Hi,

In Reference manual : Chapter FCCU-> Functional description -> Fault recovery is described how to recover from critical fault:

NMI is asserted whenever the FCCU detects critical fault. As the picture above represents. NMI is released when micro enters RESET state.

NMI is for z7 core handled via IVOR1 (Machine check).

For more details about NMI refer to Reference manual -> 54.4.2 Non-Maskable Interrupts (NMI)

Peter

[pradeepdas]

Hi,

We have tried to follow mentioned scheme. Still we are unable to get critical fault cause.

What we understand is during critical fault both NMI and Safe mode request will be generated.

Is it correct on each critical fault soft or hard reset will be  asserted followed by safe mode request.

In start up code, critical faults are cleared. Do we need to remove that section to go to safe mode request ?

Can we get any reference code to test critical fault handling?

Thanks & Regards

Pradeep

[petervlna]

Hi,

The NMI is triggered before Reset and/or Safe mode. Like the figure 25-34 Critical fault recovery represents.

Safe mode after critical fault is entered directly from reset mode.

When FCCU detects the critical fault it is going immediately to FAULT state like it is described in this figure.

Read your FCCU faults in NMI interrupt.

Hint: minimize the code to find easier the source of reset.

Peter

[petervlna]

Hi,

From your FES content I can see that the reset was caused by FCCU HARD reaction.

FCCU also forced micro into SAFE mode.

To find the root cause of your issue you need to read FCCU CF and NCF status registers. (FCCU_CFSn / FCCU_NCFS0).

For more details refer to FCCU chapter in reference manual.

Peter

[pradeepdas]

Dear Peter,

Thank you for reply.

We have tried to read FCCU CF and NCF register in boot loader before doing any other task. Even before reading RGM_FES and RGM_DES register.

Still we are getting value of all three registers(FCCU_CFS0, FCCU_CFS1 and FCCU_NCFS0) as zero.

Below code we are using to read above registers

/************************************************************************/

unsigned long ulTimeOut     = 0;

unsigned long ulConfigReg     = 0;

unsigned long ulCFS0        = 0;

unsigned long ulCFS1        = 0;

unsigned long ulNCFS0         = 0;

/* Read Critical failure*/

ulConfigReg = FCCU.CTRL.R;     /* Read current settings*/

ulConfigReg &= 0xFFFFFFE0;    /* Clear the Op-code place*/

ulConfigReg |= 0x09;         /* Opcode for reading critical fault*/

FCCU.CTRL.R = ulConfigReg;

while(1){

    ulConfigReg = FCCU.CTRL.R;

    ulConfigReg = ulConfigReg & 0x000000C0;

    if(ulConfigReg == 0x000000C0){

        ulCFS0 = FCCU.CFS[0].R;   

        ulCFS1 = FCCU.CFS[1].R;

        break;

    }

}

/* Read non Critical failure*/

ulConfigReg = FCCU.CTRL.R;     /* Read current settings*/

ulConfigReg &= 0xFFFFFFE0;    /* Clear the Op-code place*/

ulConfigReg |= 0x0A;         /* Opcode for reading non critical fault*/

FCCU.CTRL.R = ulConfigReg;

while(1){

    ulConfigReg = FCCU.CTRL.R;

    ulConfigReg = ulConfigReg & 0x000000C0;

    if(ulConfigReg == 0x000000C0){

        ulNCFS0 = FCCU.NCFS0.R;

        break;

    }

}

Are we reading them correctly ?

[petervlna]

Hi,

You are getting FCCU CF and NCF registers values after destructive reset. The FCCU content is destroyed by destructive reset.

This is the reason why you see zero values in status registers.

FCCU implements alarm state in its state machine.

If you was to store the FCCU registers value before the reset use the ALARM state.

FCCU can be configured to react on fault by moving into ALARM state. (Device is still not reset)

The Fault source is stored in FCCU fault status registers.

During alarm store the FCCU status registers to memory which is not affected by destructive reset. Flash, etc...

When ALARM timeout expires then reset is performed.

After reset you can read original content of FCCU status registers as it is stored in Flash, EEPROM, etc...

But to simplify root cause finding you can explain me what you are doing before/when micro resets.

Are you using some specific peripherals?

Peter

[pradeepdas]

Dear Peter,

Thank you, We are yet to implement and test the method you have suggested.

The code we are using is large in size and we have yet to point-out the reason(or section of code) for reset.

After each reset, code will enter to boot-loader application, where UART is the only peripheral, which is initialized to get the code for programming.

We are reading functional event and FCCU registers from boot-loader application, before doing any initialization.

As per data sheet there are four interrupt sources are available (IRQ No. 251, 252, 253 and 254) for FCCU.

If I am not wrong we have to register an ISR for IRQ 251(external alarm interrupt line) to catch ALARM state of FCCU. Please confirm the same.

How to configure the time-out value, so that we can print/store the values before it resets.

As per FCCU FSM for critical faults transition will happen from normal mode to fault mode directly.

Will this fault will give us a reset ?

If so, how we can get critical error cause?

We are not configuring any FCCU related registers, except clearing fault as a part of initialization. Is it still can generate a reset with default settings ?

Can we get any sample code/reference regarding FCCU implementation ?

[pradeepdas]

Hi,

Update to previous reply.

We have tried to inject fake NCF to simulate FCCU operation.

We found that the interrupt for ALARM state is branching to IRQ 250(irq_alarm_b). We are able to print NCF status and found to same flag what we have injected.

But we are getting struck inside ISR,. Neither controller is getting reset, nor we are able to do other task. Please help in this regards.

Still we are not clear how to handle/identify critical fault.

The code we have used for injecting fake fault is

*************************************************************************************************

FCCU.CTRLK.R = 0x913756AF;               // Configuration state key

FCCU.CTRL.R  = 0x1;                               // enter config state - OP1

while(FCCU.CTRL.B.OPS != 0x3)              // Verify if state changed to OP1

/* Configure SMRT time. The delay between Fault and Reset operation*/

FCCU.CFG.B.SMRT = 0xF;                       // 32768 count at 16 MHz. approx 2048 us

FCCU.CFG_TO.R     = 0xFFFFFF;           // 65 mili seconds, ALARM Timeout

FCCU.NCFE.R          = 0xFFFFFFFF;       // Enable all NCF

FCCU.NCFTOE.R     = 0xFFFFFFFF;       // Enable transition from Normal to Alarm on fault

FCCU.IRQ_EN.B.CFG_TOI_EN = 1;          // Enable interrupt for Alarm

FCCU.CTRLK.R = 0x825A132B;               //provide Config state key

FCCU.CTRL.R  = 0x2;                               //Enter Normal mode

while(FCCU.CTRL.B.OPS != 0x3)              //Wait till operation is over

FCCU.NCFF.B.FCNFC = 0x0C;                  //Inject fake NCF

[petervlna]

In your ISR are you reading and clearing the faults?

[Now I realize that FCCU cannot react on critical faults with ALARM state on this device]

One more thing which can help:

Disable the FCCU reaction on critical faults in FCCU_CFS_CFGx registers.

Write to FCCU_CFS_CFGx registers 0x0, but it must be written trough CONFIG mode.

This will prevent FCCU reset reaction on critical fault.

However some faults are routed redundantly also to RGM and can trigger reset immediately.

Now when your critical fault comes the FCCU will store it in CFSx register and trigger SAFE mode request to Mode entry module.

The interrupt 51 is safe mode interrupt.

In this interrupt you can read FCCU CF fault status registers.

Hope this will help.

Peter

[pradeepdas]

Hi,

We have registered ISR for Safe mode interrupt and FCCU alaram mode. We have given highest priority(15) to safe mode interrupt and priority 14 to FCCU alarm mode.

Immediately after injecting NCF error code is getting branching to safe mode ISR.

Status register (ME.GS.R) of mode entry module is found as 0x74 and Interrupt status register(ME.IS.R) is read as 0x07.

RGM_FES register is read as 0x00. From safe mode ISR non critical error status(FCCU_NCFS0) is also read as zero.

When we tried to change the mode to DRUN mode using ME_MCTL register, invalid mode interupt is getting generated.

After servicing this safe mode ISR, code is moving to FCCU Alaram mode ISR and we are able to read injected error flag as set. After clearing it again we are getting struck.

Is this the correct sequence ?

Thanks & Regards

Pradeep

[petervlna]

In the ISR you need to clear the FCCU CFS and NCFS flags.

Verify if those flags was cleared and then you can request mode transition from SAFE to DRUN.

Be aware that it is possible to make transition from SAFE only to DRUN or RESET. Not to RUNx modes!

Peter

[pradeepdas]

Hi,

As I have mentioned, we are reading FCCU CFS and NCFS as zero from safe mode ISR where as FCCU NCFS is read as 0x1000 from FCCU alarm mode ISR.

We will retry again to read FCCU CFS and NCFS flags.

Thanks and Regards

Pradeep

[petervlna]

One more thing comes to my mind.

Place while(1) - endless loop at the very fist instruction in your startup.

Skip this in debugger and execute program.

When the program is reset by fault it will ensure that nothing else is executed and nothing can overwrite FCCU status registers.

Read FCCU status registers via debugger. (Do not forget that you need to execute some script to see the actual values. Lauterbach do it automatically)

And also as you see the fault is also coming from SWT -> disable SWT also in your program. To exclude the SWT as source of reset.

Peter