REQUEST CLARIFICATION FOR FCCU OF MPC5744

[santoshkumar_n]

Hi NXP Team,

I am working for MPC5744P and testing the FCCU Module.

Following are the issues which i face and request your support.

Note : I use TRACE32 as be debugger window and LAUGHTERBACH is the debugger which i use.

1. 1. I find the FCCU is getting initialized (NORAMAL TO CONFIGURE && CONFIGURE TO NORMAL state) only after HARDWARE POWER ON RESET. Through DEBUGGER, if i give SOFT RESET, the FCCU STATE is going to ABORT State.

MY understanding is, the FCCU WATCHDOG TIMER would have not get initialized by the SOFT RESET, so that only, the FCCU is going to the ABORT STATE. Could you please confirm if my understanding is correct or Pl correct me if i am WRONG...?

2. While i was testing the FAULT REACTION by configuring the FAULT REACTION as " No reset reaction " in "NCFS Configuration Register" I find the MICRO is reaching the EXCEPTION LOOP.

   The configurations done are as follows:

• FAKE FAULT INJECTED is " BIST NON CRITICAL FAULT: 0X09 "
• FAULT LINE 0x09 is been configured as " SOFTWARE FAULT " in NCF Configuration Register
• FAULT LINE 0x09 is been configured as "No reset reaction" in NCFS Configuration Register
• FAULT LINE 0x09 is been configured as " ENABLED " in NCF Enable Register (FCCU_NCF_En)
• FAULT LINE 0x09 is been configured as " ENABLED " in NCF Time-out Enable Register (FCCU_NCF_TOEn)
• NCF Time-out Register (FCCU_NCF_TO) is been set to "0xFFFE" ( The approximate TIME OUT is 4 ms).

   I request to understand, why the system is reaching the EXCEPTION state...?

Please find the attached VIDEO “ EXCEPTION ERROR_NO FAULTREACTION_FCCU” and can be run in any media player by changing the extension of the file.

3. While I was trying to move the system from " NORMAL TO ALARM " and then " ALRAM to NORMAL", I find the FCCU reached the FAULT state without turning to NORMAL STATE.

   The FAULT which is try to create is FAKE FALUT and it is ADC0 SELF TEST FAULT and the corresponding    NCF number is 47. (As mentioned in the FAULT CONFIGURATION SECTION at 7.11.3 in MPC5744 reference manual)

  I injected the fault by writing directly to STCR2[SERR] bit   and cleared the fault in the next instruction cycle itself. MY system clock is 200 MHZ.

 Even though, i find the FCCU reach "Fault “state admits of the FAULT clearing.

Please find the attached VIDEO “ ALARM_TO_NORMAL_FAILURE” and can be run in any media player by changing the extension of the file.

[santoshkumar_n]

Hi  Peter,

Sorry 1 more obeservation.

Observation 3:  In MPC5741P micro, After debugger reset, as already told  " SYSTEM RAM ERROR " are getting generated and the FCCU is getting RESET and holding the default values in the registers. But i watch that the FCCU[0] =0 && FCCU1[1] =1 ( turing to FAULT STATE)..  Why it is so happening...?

I have made all the  EOUT_Sign  register as "zero" in my configuration and also they are "zero" at by default.

But the protocol by default is" DUAL-rail" .At my configuration i have set " Bi stable".

After debugger RESET, the FCCU state is getting changed to FAULT State  and the FCCU pin outs are showing the " FAULT" and the FAULT value at the lines seems to be equivalent to Bi stable and not equivalent to Dual rail.

[santoshkumar_n]

Hi Peter,

Thanks for your support.

Observation1: 

We can able to disable the BIST and can able to see that there is no occurrence of the SYSTEM  RAM errors after the "IN TARGET RESET GIVEN VIA DEBUGGER". But BIST has to be ( auto- activated ) in real time scenario for sure. The activity was carried out to confirm that BIST is responsible for SYSTEM RAM CORRUPTION.  The above test i carried out in MPC5741P micro.

Observation 2: 

I do have EVAL board , in that micro is MPC5744P. The observation is , whenever i start executing, the below errors are generated and injected to the MICRO.

1. NCF[44] => Safety Core exception Error  

2. NCF[72] => SoFirst timeout interrupt requestfrom Software Watchdog of Safety Core

 and before configuring FCCU, if i try to ERASE the status of FCCU, it is going to ABORT state , because the SOURCE of the FAULTS  not yet  been erased and it keeps updating the errors to the FCCU.

But when i give, DEBUGGER RESET, i didnt find any creation of the SYSTEM RAM ERRORS  and all the status registers value become "ZERO".

Query:

1. Why the SYSTEM RAM errors generated in after " DEBUGGER RESET"  in MPC5741P   and not in MPC5744P"? .

     Note: i checked BIST is there in MPC5744P .  and it  will also get auto activated after RESET..

2.  How to  clear the source of the FAULT for  "NCF[44]"  &&  "NCF[72]"..?...

Please help me in getting the answers for the above..Please...

[petervlna]

Hi,

Ok so observation 1 is now clear to you.

To second observation::

Even if fault sorces are active you cant get abort. You will clear faults with operation successful and the the faults are immediately set.

You can get abort only on FCCU configuration watchdog timeout. This mean stepping in debugger, execution non  FCCU code during config mode, etc...

A1: Make sure that your debugger execute long external reset -> trigger BIST. On short reset to phase3 the BIST is not triggered.

A2: NCF[72] is cleared only via reset. Watchdog do not implement clear bit for TIF flag. For safety reason.

NXF[44] - im not sure about. This is most probably generated by Power on Reset due to lockstep core reset state.

Please clear that fault and do functional reset. I can test is in office, however I am now sick and I will be one week out of office.

[fu860925]

{

    .functionID    = 2,

    .hwSwRecovery  = FCCU_NCF_HW_REC_FAULT,

    .reset         = FCCU_NCFS_NO_RESET,

    .timeoutEnable = false,

    .reactionType  = 0U,

    .callback      = NULL,

    .callbackParam = NULL

};

fault 0-4, the same config, two inject mothod,

First：FCCU_DRV_SetNcfFake(0U,2U)  no reaction, not alarm or fault status, why?

Second：PMC->FIR = 0x1U;

When debug this line, s32 design studio show error, Error : Error in ONCE status register during instruction execution.  why?

[santoshkumar_n]

BIST_DIABLE_CMM : https://community.nxp.com/docs/DOC-340007

My Output file : output_files.zip 

Hi Peter, 
             
Thanks for your support. 
 
This is regarding the discussion "ANY idea /guidance WHY THE  "System RAMs uncorrectable ECC error" is getting generated ...?".

As said by u, i checked my code.
I do RAM initialization at the startup code and the code is executed at all times of RESET.

And 1 more  point , as you told that the BIST activation would also lead to RAM destroy. 
Based upon the above point, i developed the script to disable the BIST activation at the startup.( By getting some guidance from previous community discussions)
Attached with this mail.
Could you please make a review....?

I ran the attached CMM.

Then i flashed my application and gave the "IN TARGET RESET VIA TRACE32".After that too, i observe the SYSTEM RAM is getting corrupted

and i see the SYSTEM RAM ERRORS in MEMU...

Could you please guide me over the above scenario...?

Basically , could you please guide me " How to confirm that the BIST is DEACTIVATED..?"

[petervlna]

Hi,

Your offline BIST disable script is not correct for MPC5744P device.

Please you attached one.

This is regarding the discussion "ANY idea /guidance WHY THE  "System RAMs uncorrectable ECC error" is getting generated ...?".

This can be also cause by Power on Reset. After power on reset you should clear all faults in FCCU (also in MEMU). If you clear them and do functional reset do you see those faults pending? Have in mind you have to first clear MEMU flags and then FCCU.

Peter

[petervlna]

Hi,

1. your understanding is not correct. FCCU starts its first watchdog on entry to config mode. This has nothing to do with any kind of reset. If FCCU is not exited from config mode to normal mode within specified watchdog timeout then FCCU report ABORT flag.

2. Always first configure FCCU and then inject the fault.

FCCU cannot trigger exception (except IVOR4). This is linked to other issue. Most probably protected access to register or so. You will find out which instructions cause your exception by debugging step by step your code until it goes to exception. For injecting of FCCU fault please follow my application note:

https://www.nxp.com/docs/en/application-note/AN5284.pdf?fsrch=1&sr=2&pageNum=1 

3. FCCU goes to fault state of if there is fault active. You can also find how to configure alarm state in AN: https://www.nxp.com/docs/en/application-note/AN5284.pdf?fsrch=1&sr=2&pageNum=1 

I have also included examples to make it easy to understand.

https://community.nxp.com/docs/DOC-329719 

Peter

[santoshkumar_n]

Hello Peter,

Thank you for your response.

The below discussion is the continuation of discussion item 1 (Discussed in the previous reply) 

As you told I agree with your point that "FCCU abort state and reset state does not have much correlation".and we confirmed by deep debugging.

My initialization sequence is attached as JPEG with this thread.Please have a look.                                                                                                                                 

                              

While on debugging i find the following:

1. During POWER ON RESET & GO, the above flow works good  and FCCU IS FUNCTIONING NORMALLY.

2. Down the line, When I give a SOFTWARE RESET via DEBUGGER, " System RAMs uncorrectable ECC error" is been generated  

    and i confirmed inside the MEMU ERROR Registers also.

ANY idea /guidence WHY THE  "System RAMs uncorrectable ECC error" is getting generated ...?

3.  If i continue " GO( Execute the code in debugger )" after the above scenario, i find that the Control/Execution enters the code as usual via the entry point as depicted in above figure, but gets stuck inside the LOOP 1 and I observe the following

      *.   FCCU STATE is in " FAULT STATE". ( The reason could be the generation of the RAM ERRORS & could not be erased by the status                  clear operation)

      *    The  Execution keep continuing inside the LOOP 1 shown in above figure ( The reason could be the FCCU STATE is in " FAULT STATE")

      *   The FCCU. CTRL .OPS = ABORT. (Not able to find out WHY THE  operation result(OPS) turned to ABORT..?

Could you please help us to get the ANSWERS for the above..?

Note: From reference Manual page no 2792

The ABORT response occurs in the following cases:

• wrong access (missing or wrong key) to the FCCU_NCF_S register (clear operation OP12)
• wrong access (missing or wrong key) to the FCCU_CTRL register (OP1, OP2 operation)
• OP1 (CONFIG command) execution when FCCU state /= NORMAL or configuration locked

  And I cross checked we did not do any of the above malfunctions in loop 1.

[petervlna]

Hi:

ANY idea /guidence WHY THE  "System RAMs uncorrectable ECC error" is getting generated ...?

I expect that you are not disabling BIST. It is enabled by default in our factory. Memory BIST is executed during reset and destroy the ECC content of RAM memories as BIST is not executed via standard bus interface.

Therefore the RAM must be initialized every time the memory BIST is executed.

I expect that you initialize RAM only after POR or destructive reset. But it must be initialized also after long external reset. Only reset which do not triggers BIST is reset starting from phase 3  ( short external reset).

This is my guess, but without further information I cannot tell you any closer details.

To point 3:

You have to distinguish between fault report and fault source.

You can clear this fault in FCCU by standard fault clearing procedure. However it is immediately set again as its source line is still active (MEMU ECC flags). Therefore you think it is not cleared.

1. remove the fault source(MEMU) and then you can clear the fault in FCCU.

The FCCU. CTRL .OPS = ABORT. (Not able to find out WHY THE  operation result(OPS) turned to ABORT..?

This should be because of:

1. you are checking it with debugger and CONFIG state watchdog timeout.

2. You are not able to enter config state because of pending fault. (Not all fault prevent entering the config state).

Working with FCCU is quite tricky, therefore I have published various application notes  to help customers with it.

But debugging via community is always hard :smileyhappy:

Peter

PS: upload me here your latest compiled SW (at least output file) so I can play with it to see if there is an issue. :smileycheck: