Hi David.
Guess I need to explain my situation a little better. We are running both cores with lockstep enabled (no DCFs are used) and the FCCU has been setup to react on a set of NCF's (including NCF[42]). Software is running just fine until we attempt to perform a software download. As part of the download sequence the CPU will perform a software reset to hand over control to the bootloader which will perform the actual update.
Until recently, the NCF[42] was set up to not cause any FCCU reaction and download worked just fine. But in a recent update, NCF[42] was activated and setup to cause an immediate FCCU reset. This caused download sequence to fail and we found that when core1 performed the software reset, the CPU got stuck in reset (RSTOUT active). By temporarily disabling NCF[42] reaction prior to software download, the download sequence works, i.e. the CPU is reset and core 0 boots up as expected.
I compared this to what happen when I attach the CPU to a debugger and halt Core 1 while NCF[42] reaction is active. As debugging this will disable/halt RCCU this also trigger FCCU reaction with the same result as we noticed above, i.e. both cores gets stuck in reset and RSTOUT is active.
My suspicion was hence that maybe a software reset will have much the same effect. As a SW reset will not reset the FCCU and if NCF[42] is(/becomes) present after any reset (as you stated above), wouldn't that mean that the FCCU would kick in and perform a FCCU reset as a response to the SW reset?
If so I guess that would mean that if you intend to perform a software reset, you must first disable NCF42 reaction?
By the way, is the expected behaviour of halting Core1 using a debugger while NCF[42] is configured to peform a reset that the CPU will actually be held in reset, rather then "just" performing a FCCU reset and reboot the CPU?
Best Regards
/Jimmy W
