https://devzone.nordicsemi.com/f/nordic-q-a/21603/any-way-to-put-system-into-off-state-in-hard-fault-handler-with-sd-enabledLong title, but basically sums it up - is there any way to put the nRF51 into the off state from within the hard-fault handler if the soft-device was enabled prior to the fault? The complication is that the soft-device seems to protect the NRF_POWER peripheralen-USTelligent Community 13Wed, 24 May 2017 10:30:26 GMThttps://devzone.nordicsemi.com/thread/84809?ContentTypeID=1Wed, 24 May 2017 10:30:26 GMT137ad170-7792-4731-bb38-c0d22fbe4515:789d7f40-3268-470c-9ddc-bb96e3a7d1deovrebekk<p>It&#39;s good you found some kind of solution at least. With the current architecture it is challenging to handle hard faults gracefully. The assumption is that this should only happen during development, and in the rare case that it would happen in production a software reset would be sufficient.</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/84808?ContentTypeID=1Tue, 16 May 2017 20:58:08 GMT137ad170-7792-4731-bb38-c0d22fbe4515:86c69fe4-f9a3-4023-88e9-ca78835aca97MarcF<p>Unfortunately, not really... this was for production code, so I couldn&#39;t just clear UICRs, halt, or use the UART. I ultimately had to set things to generate an interrupt on WDT, quickly preserve some state in shared RAM between bootloader and application, issue a softreset, and then in the bootloader I check if the WDT is running or not, and if it is, I put the system into OFF and have it wake immediately back up using a GPIO-detect on a signal with a guaranteed state. It&#39;s not pretty, but it ensures I will always have a clean system on restart, and that shared RAM is preserved through all resets except power-on and pin-reset.</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/84810?ContentTypeID=1Tue, 16 May 2017 07:37:58 GMT137ad170-7792-4731-bb38-c0d22fbe4515:c0c4e4ab-b744-488e-96b4-6924455af8f3ovrebekk<p>Did you have any luck with this?</p> <p>It should be possible to disable the peripheral protection by erasing the CLENR0 register in the UICR, but it might be better to find some other way to get the information you need, such as halting with the debugger, writing to the UART, or something similar.</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/84804?ContentTypeID=1Tue, 25 Apr 2017 13:45:50 GMT137ad170-7792-4731-bb38-c0d22fbe4515:a6969234-e76f-4d33-84a4-90e9fa7b84eaMarcF<p>For better or worse, the WDT stays active through system resets - only power-on, pin, and wake-from-off will reset/disable the WDT. So unfortunately, NVIC_SystemReset() won&#39;t help on its own. I&#39;m experimenting with doing a system reset and then putting the system to sleep on startup if the WDT was running... but it&#39;s not ideal yet. But it may wind up doing what I need it to do.</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/84807?ContentTypeID=1Tue, 25 Apr 2017 10:58:02 GMT137ad170-7792-4731-bb38-c0d22fbe4515:d8bc477c-752e-4fc9-bcc8-aa46ea117353Turbo J<p>Did you try just calling <code>NVIC_SystemReset()</code> to disable the WDT?</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/84806?ContentTypeID=1Mon, 24 Apr 2017 23:55:13 GMT137ad170-7792-4731-bb38-c0d22fbe4515:c8a3ae33-643f-464f-905d-158ba4c8a4cbMarcF<p>Fair enough... nRF51822, S110v8, SDKv10.</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/84805?ContentTypeID=1Mon, 24 Apr 2017 23:49:36 GMT137ad170-7792-4731-bb38-c0d22fbe4515:8289259e-3302-4776-9dea-f070dbb91370RK<p>Which chip, which softdevice version, the answer (if there is one) will probably be different based on that information.</p><div style="clear:both;"></div>