S32K396 SPD DEMO

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

S32K396 SPD DEMO

2,363 Views
Jason22
Contributor III

S32DS version 3.6.0, RTD version 4.0.0HF02, SPD version S32K396_1.0.0. When I was porting the demo to the IP layer, I encountered this error in bist, which was an imprecise bus fault. What caused this error? It is a probability of occurrence, with a probability of approximately 50%. I have made some changes to the emcem code because after bist is completed, there will definitely be precise bus faults when accessing the au32InjectedFaults variable, and faults will also occur during erm initialization.

Jason22_0-1745806044202.png

Jason22_1-1745806063938.pngJason22_2-1745806070192.png

 

 

Tags (3)
0 Kudos
Reply
6 Replies

2,331 Views
petervlna
NXP TechSupport
NXP TechSupport

Hello,

There must be something wrong in the integration.

On our side the S32k396 non-DS example is running correctly.

 

au32InjectedFaults -We don't understand why you put orimi into code for assigment to bss, for such purpose there is memMap files where you can redefine. You will ahve a conflicts with declarations locations where you did not placed _atribute(bss).

It enough to search in eMcem_MemMap.h section: EMCEM_START_SEC_VAR_NO_INIT_UNSPECIFIED_PERSIST_RESET

and if you put it into BSS, the array will always be initialized to zero, what is against nature of that array which carries information of injected fault details . (specifically DCM channel)

REM of eMcem_Erm_Init() seems to me like incorectly set clock if the fucntion crash. So check the clocks for ERM module.

petervlna_0-1745841609776.png

Strange is also connection of BIST problem with eMcem module. Especially if it throws Bist_StcuUnlock() error, you should check BIST clocks.

petervlna_1-1745841684313.png

You could check linker file if it is same in DS as in the SPD demo code.

Best regards,

Peter

 

 

 

0 Kudos
Reply

2,319 Views
Jason22
Contributor III

Hello, thank you for your reply.
1 . au32InjectedFaults
If I had not modified the variable, then when I run Bist_Run and reset it, accessing the variable in eMcem_Dcm_ClearNCFFaults will definitely result in a bus fault, where the first two values of the variable do not match the memory.

Jason22_0-1745895640004.png

Jason22_1-1745895654015.png


2.  The clocks of STCU and ERM
There seems to be no problem.

Jason22_2-1745895686992.png

Jason22_3-1745895699298.png

 

Jason22_4-1745895718722.png

3 . linker file
I copied the linker file from the demo.

4. EMcemInit failed
Sometimes, in the eMcem_Fccu_ExecuteOperationAndConfigureCtrlReg function, there may be failures in the eMcem_Fccu_TestAndLockFCCUAccess function or the eMcem_Fccu_UnlockFCCUAccess function.

Jason22_6-1745896248977.png

Jason22_7-1745896273632.png

5. other
I copied startup_cm7. s from the demo and changed MAIN_CORE to 0; The Optimization Level is - O0; All the results were obtained after performing a POR  and then attaching the PE.

Jason22_5-1745895749606.png

 

0 Kudos
Reply

2,285 Views
Jason22
Contributor III

Hello,

I don't have a screenshot now, but during the debugging process, I found that the second bit of NCF_S0 is 1, and sometimes these three bits of DCMROD4 are 1, and these bits of SR1 of ERM0 are 1, corresponding to addresses 0x10338 and 0x10340.

Jason22_0-1745933082649.png

 

Jason22_1-1745933216184.png

When I disable NCF2 group in the configuration of EMCEM, there will be no initialization failure or reset (FCCU_RST) due to these reasons.

But it still fails in other parts of the emcem initialization function, and I found that when FCCU returns from the CONFIG state to the NORMAL state, it does not enter the NORMAL state, but enters the FAULT state.

Best regards, 

Jason

 

0 Kudos
Reply

2,177 Views
petervlna
NXP TechSupport
NXP TechSupport

Hello,

When I disable NCF2 group in the configuration of EMCEM, there will be no initialization failure or reset (FCCU_RST) due to these reasons.

ok, that is expected

But it still fails in other parts of the emcem initialization function, and I found that when FCCU returns from the CONFIG state to the NORMAL state, it does not enter the NORMAL state, but enters the FAULT state.

Most probably there is pending fault, and as soon as you enable it and save configuration the pending fault will propagate to your FCCU fail sate machine and trigger the ALARM state.

Before entering configuration phase, do a check if there are no latched faults.

At least this seems to me as the root cause of the described behavior.

Best regards,

Peter

0 Kudos
Reply

2,302 Views
petervlna
NXP TechSupport
NXP TechSupport

Hello,

It looks like you have some NCF faults latched which you are not erasing / not able to erase.

It would be good if you could share some screenshots of NCF status registers (NCF_S) and K3 has fault details in DCMROD registers.

Best regards,

Peter

 

0 Kudos
Reply

2,159 Views
Jason22
Contributor III

screenshots:

Jason22_0-1746498483628.png

Jason22_1-1746498509557.png

Jason22_2-1746498560560.png

 

Jason22_3-1746498578651.png

 

Jason22_4-1746498592129.png

 

Jason22_5-1746498603963.png

 

The problem seems to have been solved, but I am using the startup_cm7. s and link file of SPD1.0.5, and the driver files is still S32K396SPD1.0.0. The driver files has not been modified, and there are no issues with Bist_Run and eMcem_Init.

0 Kudos
Reply