https://devzone.nordicsemi.com/f/nordic-q-a/8476/softdevice-assertHi, What are the general causes of SDS assert in nrf51/52 ? Assuming that SW has been tested, is there something that could happen in the code that would cause the assertion ? Can some HW malfunction cause the assert and is it possible to track the issueen-USTelligent Community 13Sun, 02 Aug 2015 16:28:50 GMThttps://devzone.nordicsemi.com/thread/30912?ContentTypeID=1Sun, 02 Aug 2015 16:28:50 GMT137ad170-7792-4731-bb38-c0d22fbe4515:631b9c40-2bd1-4a88-aaee-2199cc02e6efSusheel Nuguru<p>Softdevice could assert because</p> <ol> <li> <p>Application accessing modules in hardware that are used by softdevice</p> </li> <li> <p>Application configuring/using interrupt priorities that it is not suppose to use, breaking softdevice realtime requirements.</p> </li> <li> <p>trying to debug by breaking the execution of the code and stepping.</p> </li> <li> <p>application stack overflow corrupting softdevice stack memory</p> </li> <li> <p>using Timeslot API and not ending the allocated session in time.</p> </li> </ol> <p>These are the reasons cause by application for softdevice to assert and application has to fix it in its code. Any other reason that caused the assert might be a bad sign and could be a hint that it could be softdevice bug. When softdevice asserts it wont be able to come out of it as all the real time requirements for it are broken. System restart would bring it back, but if the system restart again leads to the same system state, then it will cause the same softdevice assert. The main intention of assert handlers is debugging. But if you want to extend its usage by trying to dynamically handle softdevice assert, then why not, It could atleast be used to exit things gracefully.</p><div style="clear:both;"></div>