Correct way to reset from high-priority ISR?

[Carl]

Hi,

I want to have a generic fault handler that will cause a reset. The handler may be called from a high-priority ISR or exception trap (e.g. hard fault handler), and will likely be called when the SoftDevice is enabled.

Calling sd_nvic_SystemReset appears to be recommended versus NVIC_SystemReset: devzone.nordicsemi.com/.../

However, it's unclear why. In general the "sd_" functions are used so that you don't interfere with SoftDevice state or real-time guarantees. But if we're resetting anyway, why does it matter?

Calling sd_nvic_SystemReset won't work properly from a high-priority ISR. In fact, it will result in a reset, but due to a lockup rather than a proper soft reset. It's also less than ideal because it requires the SoftDevice to be enabled.

A throwaway comment in the following suggests that one difference between the two functions is that "sd_nvic_SystemReset" may block until flash writes are finished: devzone.nordicsemi.com/.../

However, this isn't documented in the API description of the function. Would it be safe to assume that calling "NVIC_SystemReset" wouldn't cause any issues except the possible loss of a pending flash write?

Thanks, Carl

[Susheel Nuguru]

Hi,

What I wrote in that thread was true for most of the sd_xx calls. The sd_xxx calls would know the state of the softdevice and will try to wait for any state that might cause any error.

Unfortunately this is not true for sd_nvic_SystemReset. Like you have explained yourself, we are intending to do a system reset irrespective of system state. In Ideal case, softdevice should have checked for any flash operations BUT it does not do it. It just calls NVIC_SystemReset. So I do not see any advantage of calling sd_nvic_SystemReset over just calling NVIC_SsytemReset in this case.

But it is still your responsibility to make sure that there are no ongoing flash activity at the time of this, else there might be flash corruptions.