S32K310 FUNCTION RESET

[Embedded_novice]

The single-step simulation is shown in the figure. I added a breakpoint in IAR to perform the single-step simulation. The rightmost OS_TICK is the cumulative value of my 1ms timer. When I was conducting single-step debugging, OS_TICK suddenly reset to zero and started accumulating again, and the reset count in the MCRGM register also started accumulating. This indicates that something triggered my reset, but I couldn't find the reason for my reset in the FES register.

I suspect it might be due to the fact that I configured the software watchdog. However, I have already configured the software watchdog to not run in the DEBUG mode, and I only initialized the watchdog. Why did it still trigger a reset?

Could you please provide some troubleshooting directions? Thank you very much!

[VaneB]

Hi @Embedded_novice 

Could you please check if the Software Watchdog Timer (SWT) is properly disabled in debug mode? Specifically, take a look at the CR[FRZ] bit. It should be set to freeze the watchdog while debugging.

Also, as a quick test, try toggling a GPIO pin right at the start of your code. That can help confirm whether the MCU is resetting, especially since you are not seeing any reset flags in MC_RGM.DES or MC_RGM.FES.

And just one more thing, try running the code without any breakpoints to see if the reset still happens.

BR, VaneB

[Embedded_novice]

Hi @VaneB

Without any changes to my software environment, I was unable to reproduce the previous malfunction. However: A1: I checked SWT -> CR -> FRZ, and it's clear that this register flag has been set to 1.
A2: I guess you want to determine whether the MCU has reset by flipping the GPIO. The way I observed it was by monitoring a continuously accumulating OS_TICK variable. Previously, when we determined that the MCU had reset, it was because we saw this variable start counting again from 0 (1ms count, uint32 type)
A3: This situation will not occur when running without setting breakpoints.

I am currently unable to reproduce the fault and therefore cannot continue to provide valid information. However, I have a question. Could the reset of this MCU be related to the debugger? For instance, if the JLINK I'm using has an issue, it might cause other MCU exceptions to be triggered when performing breakpoint debugging (as far as I know, software breakpoints are attached by the debugger).

[VaneB · Accepted solution]

Hi @Embedded_novice 

It is possible that the issue is caused by the debugger itself. To rule out debugger-specific behavior, consider testing with a different debugging tool.

Another potential root cause could be related to memory caching. If variables are stored in cached memory regions, their values might not be preserved correctly during debugging. To address this, consider placing such variables in non-cached memory regions to ensure their values remain consistent and are not lost unexpectedly.