MPC5643L FCCU interrupts not occuring

[twp]

We are developing a system in which we need to log alarms and faults generated by the FCCU on the MPC5643L.  To test this I am Injecting fake critical and non-critical faults, critical faults should generate an NMI which we have attached a logging function to, and the interrupt controller has a handler assigned to 250 which should catch the alarm interrupts. This code has previously worked and I managed to record alarm codes to shadow flash, however neither of these handlers are now being called.  I know that the critical fault injection is still functioning as it generates a RESET and transition to SAFE mode but there is no response to the non-critical fault injection.

Is there any way in which the interrupts could be disabled?  The register FCCU.IRQ_EN only has a single field for the Configuration Time Out interrupt.

The non-critical fault I am testing is enabled and has a timeout enabled so the FCCU should transition to the ALARM state.

Any help appreciated,

Tom.

[vijayravi]

How to clear this ADC critical fault after injecting. Even if I clear I_SAFE bit, it remains in fault state.

[petervlna]

[Peter] - In FCCU NCF Enable Register you can mask the reaction following a fake non-critical fault.

FCCU NCFS Configuration Register (FCCU_NCFS_CFG0..7) the reaction on fault. As you didn’t share your FCCU configuration, please make sure you have your FCCU configured properly.

Is there any way in which the interrupts could be disabled?

[Peter] – Yes, even whole reaction can be disabled via FCCU configuration registers.

The external interrupt is asserted if any interrupt status bit of the FCCU_IRQ_STAT is set and the respective enable bit of the FCCU_IRQ_EN register is also set.

The register FCCU.IRQ_EN only has a single field for the Configuration Time Out interrupt. The non-critical fault I am testing is enabled and has a timeout enabled so the FCCU should transition to the ALARM state.

[Peter] – Yes, it should on timeout trigger and interrupt

[Peter] - To avoid any speculations, I would like to see your FCCU configuration.

[twp]

Hi Peter,

Thank you for the reply.  the FCCU configuration is below.  At this point it is fairly standard as the first stage in our development is to get the interrupts up and running.

FCCUCTRL	0x000001c0	0xffe6c000`Physical
FCCUCTRLK	non-readable	0xffe6c004`Physical
FCCUCFG	0x003f0e3f	0xffe6c008`Physical
FCCUCFCFG0	0xffffffff	0xffe6c00c`Physical
FCCUCFCFG1	0x0000ffff	0xffe6c010`Physical
FCCUCFCFG2	0x00000000	0xffe6c014`Physical
FCCUCFCFG3	0x00000000	0xffe6c018`Physical
FCCUNCFCFG0	0xffffffff	0xffe6c01c`Physical
FCCUNCFCFG1	0x00000000	0xffe6c020`Physical
FCCUNCFCFG2	0x00000000	0xffe6c024`Physical
FCCUNCFCFG3	0x00000000	0xffe6c028`Physical
FCCUCFSCFG0	0xaaaaaaaa	0xffe6c02c`Physical
FCCUCFSCFG1	0xaa82800a	0xffe6c030`Physical
FCCUCFSCFG2	0xaa800800	0xffe6c034`Physical
FCCUCFSCFG3	0x00000000	0xffe6c038`Physical
FCCUCFSCFG4	0x00000000	0xffe6c03c`Physical
FCCUCFSCFG5	0x00000000	0xffe6c040`Physical
FCCUCFSCFG6	0x00000000	0xffe6c044`Physical
FCCUCFSCFG7	0x00000000	0xffe6c048`Physical
FCCUNCFSCFG0	0x0000aaaa	0xffe6c04c`Physical
FCCUNCFSCFG1	0x00000000	0xffe6c050`Physical
FCCUNCFSCFG2	0x00000000	0xffe6c054`Physical
FCCUNCFSCFG3	0x00000000	0xffe6c058`Physical
FCCUNCFSCFG4	0x00000000	0xffe6c05c`Physical
FCCUNCFSCFG5	0x00000000	0xffe6c060`Physical
FCCUNCFSCFG6	0x00000000	0xffe6c064`Physical
FCCUNCFSCFG7	0x00000000	0xffe6c068`Physical
FCCUCFS0	0x00000000	0xffe6c06c`Physical
FCCUCFS1	0x00000000	0xffe6c070`Physical
FCCUCFS2	0x00000000	0xffe6c074`Physical
FCCUCFS3	0x00000000	0xffe6c078`Physical
FCCUCFK	non-readable	0xffe6c07c`Physical
FCCUNCFS0	0x00000000	0xffe6c080`Physical
FCCUNCFS1	0x00000000	0xffe6c084`Physical
FCCUNCFS2	0x00000000	0xffe6c088`Physical
FCCUNCFS3	0x00000000	0xffe6c08c`Physical
FCCUNCFK	non-readable	0xffe6c090`Physical
FCCUNCFE0	0x01d3fcff	0xffe6c094`Physical
FCCUNCFE1	0x00000000	0xffe6c098`Physical
FCCUNCFE2	0x00000000	0xffe6c09c`Physical
FCCUNCFE3	0x00000000	0xffe6c0a0`Physical
FCCUNCFTOE0	0x01fbffff	0xffe6c0a4`Physical
FCCUNCFTOE1	0x00000000	0xffe6c0a8`Physical
FCCUNCFTOE2	0x00000000	0xffe6c0ac`Physical
FCCUNCFTOE3	0x00000000	0xffe6c0b0`Physical
FCCUNCFTO	0x0000ffff	0xffe6c0b4`Physical
FCCUCFGTO	0x00000006	0xffe6c0b8`Physical
FCCUSTAT	0x00000000	0xffe6c0c0`Physical
FCCUCFF	0x00000000	0xffe6c0d8`Physical
FCCUNCFF	0x00000000	0xffe6c0dc`Physical
FCCUIRQSTAT	0x00000000	0xffe6c0e0`Physical
FCCUIRQEN	0x00000000	0xffe6c0e4`Physical
FCCUXTMR	0x00000000	0xffe6c0e8`Physical
FCCUMCS	0x00008083	0xffe6c0ec`Physical

Regards,

Tom.

[petervlna]

Hi Tom,

Your FCCU configuration seems fine to me. Except one thing, you need to enable interrupt on Timeout.

The external interrupt is asserted if any interrupt status bit of the FCCU_IRQ_STAT is set and the respective enable bit of the FCCU_IRQ_EN register is also set.

Also do not forget to enable interrupts in INTC

And to enable external interrupts in MSR[EE]=1

Peter

[twp]

Hi Peter,

Another question on this subject.  When an ALARM interrupt occurs it is possible to search through the FCCU.NCF_S[] registers to find the source of the fault. If an NMI occurs and it was triggered by a critical fault it can be seen in the FCCU.CF_S[] registers, but if it was due to a timeout of a non-critical fault there doesn't seem to be a register which will give the source.  I was expecting a set of 'Non-critical fault timeout occurred' registers.  In 99% of occurrences there won't have been a second ALARM generated so searching FCCU.NCF_S[] will give you the source, but it isn't guaranteed to be the correct source of the FAULT state.  Am I missing a trick here?

Tom

[petervlna]

[Peter] – If it was due to a timeout of non-critical fault, then the source of fault is still the same and it is stored in NCF status register. There is a possibility to trigger interrupt on timeout where you can analyze why was not possible to recover from fault state. But the original cause of the fault is still in NCF status register. As long as the fault remains in status register the FCCU will trigger appropriate actions.

I see no reason from safety point of view to store time-out event in some special register if the original fault persist and micro can’t operate normally. If the fault is removed micro won’t get into the alarm state. So why to analyze the timeout?

[twp]

Hi Peter,

I agree, it has no bearing on the safety of the system.  I was considering it from a diagnostics point of view.  This isn't really an issue, I was just checking that I'm not missing a trick for determining the cause.

Reading back the NCF status register after injecting the fault I can see that it is not set.  However if I change that single line of code to inject a critical fault I get an immediate reset and transition to safe mode.

Kind regards,

Tom.

[petervlna]

After injecting of NCF, are you reading NCF_S registger correctly like described below?

The SW application executes the FCCU_NCFSx read operation by the following sequence:

• to set the OP10 operation into the FCCU_CTRL.OPR field

• to wait for the completion of the operation (FCCU_CTRL.OPS field)

• to read the FCCU_NCFSx register

[twp]

Hi Peter,

Yes, I am following that procedure.  It correctly reads the fault status register values if I generate an ADC self-test failure.  The whole interrupt and logging code works if it is a system generated fault but not if I inject a fault.

Tom.

[petervlna · Accepted solution]

Hi Tom,

If you take a look at table Table 285. FCCU mapping of non-critical faults in reference manual you will see:

Under Set/clear injection (inject fault) - the faults which can be injected. For ADC self-test (NCF10 & NCF11) it is [Yes - by ADC itself)]

This means NCF 10 and 11 can be injected onyl by ADC peripheral.

If you take a look on ADC self-test registers: Table 43. STCR2 field descriptions

So, for injection of this particular fault you need to set ADC.STCR2[SERR] = 1. Then you will see it in FCCU.NCF_S register.

If you need any further help do not hesitate to ask.

Ciao,

Peter

[twp]

Thanks Peter,  I had missed the meaning of that column in the table.

[twp]

Hi Peter,

I've configured my device to fail the ADC self-test routine, thus generating an non-critical fault.   I can see that it is generating an ALARM state then progressing to the FAULT state and both the INTC and NMI interrupts are being generated and being caught in our application.  However, if I switch to the fault injection method I don't get any interrupts.  It appears either I am missing something on the fault injection side or injected faults don't generate interrupts.  Does the FCCU need to in a particular state or be sent an OP code before a fault can be injected?

Tom.

[petervlna]

"Does the FCCU need to in a particular state or be sent an OP code before a fault can be injected?"

FCCU can inject faults in Normal state.

First please make sure that your FCCU sw routine is injecting NCF correctly. Inject the fault and read  FCCU NCF Status Register to verify that fault was recorded in  FCCU NCF Status Register.

You need to set OP10 [01010 Read the NCF status register (refer to the FCCU_NCFS register) [OP10].] to properly read the status.