Softdevice assert

[nightgoat]

Hi, 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 issue down even though SDS has stopped working ? Would SoC reset always solve the problem ?

I don't have any problems with the assert at the moment, but i am considering if i need to reimplement the assert handler and what do i need to take into consideration if i do that.

The application is just a bluetooth beacon, possibly i might have to add the ability to change uuid/major/minor through a custom service and a couple of flash writes.

Thanks.

[Susheel Nuguru]

Softdevice could assert because

1. Application accessing modules in hardware that are used by softdevice

2. Application configuring/using interrupt priorities that it is not suppose to use, breaking softdevice realtime requirements.

3. trying to debug by breaking the execution of the code and stepping.

4. application stack overflow corrupting softdevice stack memory

5. using Timeslot API and not ending the allocated session in time.

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.