S32K312 infinite reset problem

[Yiming2]

hello all

We met a very strange problem. After burning the software with pemicro's burner and powering the ECU normally, the ECU would go into infinite reset state, but we connected the ECU with a debugger (like jlink) (no extra action) and then disconnected the ECU from Jlink. Then power up the ECU, the ECU shall return to normal. May I ask what causes this?

we have HSE firmware integrated in this software. regarding to Jlink connection, we just colict the connect, and wait for successful connection information and then disconnect it. finally, the infinite reset shall be disappeared 

[lukaszadrapa]

Hi @Yiming2 

it's not really clear what happened. If the same image is successfully loaded by different programmers, there should be no difference. Could you provide log from Pemicro? Is there anything unusual?

Regards,

Lukas

[Yiming2]

hello @lukaszadrapa 

thanks for your reply. We done some tests we found that there is no relationship with debugger or programmer. because it shall happen for other programmer. and we add the HSE idle check the infinite reset is gone but we found that there are some other abnormal reactions(LED is not blink but CAN communication is normally ran) only the first start-up after the UTEST_1B000000 programmed,(aka first HSE installation start-up, we integrate the HSE installation with our software. ) and from the second reset, all abnormal reactions shall be disappeared, and the abnormal status was disappeared. and if we also tried removed the HSE installation step (aka don't program the UTEST_1B000000, the first start-up goes to normal.), it also works. So is there any method to fix this problem for the first start-up/reset after the UTEST_1B000000 programmed? 

we use the HSE installation with IVT method to install the HSE firmware. and integrate it with our main app. 

[Yiming2]

additional information: S32K312NH MCU is used. Option F clock configuration for S32K312 is strictly configurated regarding to Reference manual Rev9. HSE Idle status check is also performed before HSE CLK configuration. If we put the delay(about 2.5 seconds) at the start-up stage it also would be worked. because it only happed in the blank PCBA(without HSE Firmware). So we can not do a lot tests

[lukaszadrapa]

Hi @Yiming2 

if you use option F, did you program dcf_client_utest_misc to UTEST?

See S32K3xx_DCF_clients.xlsx attached inside S3232K3 RM.

I guess that this could be the reason for such weird behavior.

Regards,

Lukas

[Yiming2]

hello @lukaszadrapa 

thanks for your information. But regarding the your reply in other topics,HSE PLL configuration - NXP Community "This configuration of HSE_CLK_MODE in DCF record (and also configuration of FXOSC) has no effect unless PLL_ENABLE in IVT is enabled. SBAF will ignore it and FIRC will be used at boot time. And PLL_ENABLE has effect only when BOOT_SEQ is 1 (i.e. secure boot enabled)."

We didn't enable the PLL_ENABLE and BOOT_SEQ, so it would be no effect for this case, am I correct?

[lukaszadrapa]

Yes, I know. But there's still some confusion, I'm still checking this internally but I do not have final confirmation yet.

But I would try that anyway - there's no any downside, it can only help. Please give this a try and let me know if it makes a difference. Thank you.

Regards,

Lukas

[Yiming2]

hello
We tried to program dcf_client_utest_misc to UTEST in complaint with option F. It seems to be some difference. The infinite reset still exist. but reset happened after several seconds(App has been ran several seconds(because we can see some behavior of app working, such as LED is on). that is means that the period between the each reset is obviously longer. But just like before ,once we try to connect it with debug port, it shall go to the normal status. And we can not catch any abnormal using debugger.

[lukaszadrapa]

One more idea - it could be caused by reset escalation. Try to set registers FRET and DRET in MC_RGM module to zero. This will disable reset escalation which could lead to infinite reset until next POR.

Then, even if more resets are triggered for some reason, the device should still run and you can check the reason. If it works a few seconds, it could be caused by watchdog. Debuggers usually disable the watchdog automatically to be able to debug the code. You can simply check FES and DES registers in MC_RGM to see the source of last reset.

Regards,

Lukas

[Yiming2]

hello
We have solved this this issue. We found that if we don't check HSE_STATUS_INIT_OK in FSR, the M7 core can not be normally ran. So we add this step after HSE installation.
And we found some conflict in HSE RM(2.3). In figure 7 start-up flow, if IVT-found is no, it shall go to the normal boot, and in normal boot flow, it shall go to the recovery mode. so how to install the HSE via method 2 that descript "HSE Firmware Installation" -Installation via default application NVM location? it says that "In this firmware installation method, encrypted FW-IMG is programmed at default location IVT_START and no IVT is programmed in the device". So is it conflict with Start flow?

[lukaszadrapa]

Yes, it's necessary to wait for HSE_STATUS_INIT_OK before triggering HSE services.

And yes, I agree that the start-up flow diagram is not accurate here. It does not consider the installation via default NVM location. Thanks for pointing this out, I will report it.

Regards,

Lukas