S32K3 HSE Memory ECC Error. RGM FES[F FR18]

[longfeiwang]

MCU: S32K344, HSE has been installed, but the following errors occurred during running:

MCU_JTAG_RST_RESET = McuConf_McuResetReasonConf_MCU_JTAG_RST_RESET

What are the main reasons for this error, as there were no OTA operations or other HSE kernel operations during operation?

[lukaszadrapa]

Hi @longfeiwang 

the only reason I can see for this reset is that instructions EXTEST, HIGHZ or CLAMP are executed by JTAGC.

Is that random or does it occur every time? Is a debugger connected? Does it happen if you run different application?

Regards,

Lukas

[longfeiwang]

The target board is in the offline test state, and the Jtag is not connected. The output of the error code is matched and located through the CAN printed message information. The same error basically occurs once a day.

[lukaszadrapa]

Do you follow the recommendations from hardware design guide? Are there pull resistors on JTAG signals?

Regards,

Lukas

[longfeiwang]

yes follow the recommendations:

[lukaszadrapa]

Thanks. I have to ask if there are other reasons for this reset. I will let you know later. Notice that it may take some time.

Regards,

Lukas

[longfeiwang]

Another important piece of information: FS26 works in debug mode without this error.

[lukaszadrapa]

The main reason to use debug mode is that the watchdog is disabled. Could you check if the reset is caused by the FS26? You can read FS_DIAG_SAFETY1 register after the reset via SPI. Check BAD_WD_DATA and BAD_WD_TIMING bits. Is any of them set? It's possible that JTAG_RST is just some side effect in this case.

By the way, I'm still waiting for details about JTAG_RST reasons, I hope I will receive the response soon.

Regards,

Lukas

[lukaszadrapa]

Hi @longfeiwang 

It looks like there are no other reasons for JTAG_RST other than I mentioned earlier. I was asked if it is possible to do an AB swap test to confirm whether this issue follows the chip or the board.

Have you had a chance to check the watchdog as I mentioned in previous post?

Regards,

Lukas

[longfeiwang]

The problem should have been resolved. After initializing the watchdog in S32K3, setmode was not called. When I called setmode(wdg_43_Instance0_ etMode(WDGIF_SLOW_MODE), the reset did not occur again. Will the process of initializing the watchdog not configure the working mode?

[longfeiwang]

The problem should have been resolved. After initializing the watchdog in S32K3, setmode was not called. When I called setmode, the reset did not occur again. Will the process of initializing the watchdog not configure the working mode?

[lukaszadrapa]

Yes, Wdg_43_Instance0_SetMode() should be called at the beginning.

[longfeiwang]

Do I need to call this function every time before feeding the dog? In the current test, it is found that if the function is not called before feeding the dog, there is still a reset probability.

[lukaszadrapa]

Hi @longfeiwang 

could you please create new ticket here for this?

https://support.nxp.com/s/?language=en_US

I'm not really sure, so it will be better to assign the new ticket directly to SW group.

Thanks,

Lukas

[WeoWang]

Hi Lukas,

I have a question, in the wdg example(C:\NXP\SW32K3_RTD_4.4_R21-11_3.0.0_P01_HF02\eclipse\plugins\Wdg_TS_T40D34M30I0R0\examples\EBT\S32K3XX\Wdg_Example_S32K344), wdg is configured in slow mode:

In main.c, I can understand that it switches to the fast mode by calling Wdg_43_Instance0_SetMode(WDGIF_FAST_MODE):

While in this case, the customer didn't want to use fast mode, why is Wdg_43_Instance0_SetMode(WDGIF_SLOW_MODE) still needed?

Best Regards

[lukaszadrapa]

Hi @WeoWang 

because I'm not Autosar expert, could you please create new thread for this? We will assign it directly to Auto SW team. Thanks.

Regards,

Lukas

[WeoWang]

Hi Lukas,

https://community.nxp.com/t5/S32K/S32K3-Watchdog-s-Default-Mode/m-p/1701638#M25888

This is the new ticket that I created, thanks for the help.

[lukaszadrapa]

Thanks, assigned to Auto SW group.

[longfeiwang]

Thanks Reply