AnsweredAssumed Answered

FCCU_NCF_S read causes FCCU_NCF_S bits to be set?

Question asked by Andrew Smith on Sep 12, 2016
Latest reply on Nov 30, 2016 by Jun Li

I'm using the recommended FCCU code snippets for read/clear/configure published by NXP earlier this year.

 

As part of the MPC5744P processor setup, I need to configure the FCCU - my code to do this has the following requirements:

a) Read the present state of the NCF_S[] array and record it for posterity

b) Clear the NCF_S[] array for use in this power cycle

c) Configure the FCCU (bi-stable protocol, configuring fault reaction etc.)

 

Prior to a), I have ensured the PLLs are locked and stable. I have also disabled the SWT and ensured the MEMU error flags are cleared.

 

If I break the processor immediately prior to...

/* Change to OP10 - see manual */

FCCU.CTRL.R = FCCU_OP10;

/* Wait here until FCCU state changes */

while(FCCU.CTRL.B.OPS != FCCU_OPS_SUCCESS)

{;}

/* Get copy of latched fault status - make available to application code */

FCCUState[0] = FCCU.NCF_S[0].R;

FCCUState[1] = FCCU.NCF_S[1].R;

FCCUState[2] = FCCU.NCF_S[2].R;

 

...the NCF_S[] array is all zeroes.

 

If I break the processor where I start to do requirement b) the NCF_S[0] = 0x00038000 - implying a system RAM ECC fault.

 

It appears the action of requesting OP10 is causing this fault - does anyone have any idea as to why that might be?

 

Also - I would have thought it better to use

FCCU.CTRL.B.OPR = FCCU_OP10;

...rather than write to the whole register since the FCCU supports 8/16/32 bit writes - any reason the recommended code changes the whole register?

 

Thanks for any advice.

Outcomes