System Software Reset vs, Software Signal

[jeffthompson]

What are the subtleties between using SRC_DoSoftwareResetARMCore0( SRC ) and WDOG_TriggerSystemSoftwareReset( WDOG1 ) in terms of how they work? The latter seems to work more reliably for our purposes than the former, but I'm not sure why.

[jeffthompson]

Gustavo,

The way I've coded my system is that, for production firmware, faults call SRC_DoSoftwareResetARMCore0. If the WDOG1 'early warning' interrupt is triggered, the system attempts to do some cleanup, including writing critical data to flash, then reboots using WDOG_TriggerSystemSoftwareReset(). Of course, if things go badly, the watchdog will eventually reboot the system, just not as gracefully as I would like.

Does this sound like a reasonable approach, or should I be using WDOG_TriggerSystemSoftwareReset() for the faults, too?

Thanks,

Jeff

[gusarambula]

Hello Jeffthompson,

Would you please confirm which i.MXRT processor you are using? If it’s one that has a second core that you may want to keep running then it would make sense to reset only the core0 in theory, otherwise I would probably opt for the WDOG reset for the faults too.

Knowing which i.MXRT you are using may also allow me to investigate if we have more information on how resetting the core0 differs from the WDOG reset on that MCU in particular.

Regards,
Gustavo

[jeffthompson]

Thanks, Gustavo. I'm using the MIMXRT1026DVJ6A, so I'll change my code to use the WDOG reset instead of the SRC reset.

[gusarambula]

Hello Jeffthompson,

Both would be cold resets, albeit originated in different ways.

SRC_DoSoftwareResetARMCore0 would do a software reset of the ARM Core0 only, by asserting the SRC_SCR[core0_rst], which is a self-clearing bit.

WDOG_TriggerSystemSoftwareReset asserts WCR[WDA] which asserts WDOG_B, so it’s functionally identical to the WDOG time-out triggering the WDOG_B signal.

I hope that this information helps.

Regards,
Gustavo