https://devzone.nordicsemi.com/f/nordic-q-a/1635/problems-with-reset-loop-s110-softdeviceHello All, Since yesterday I have been getting a problem where my project using the S110 softdevice enters a reset loop. This runs on a unmodified PCA10001 that plugs into a carrier board. After stepping through the code I reach a point where myen-USTelligent Community 13Tue, 18 Feb 2014 11:47:00 GMThttps://devzone.nordicsemi.com/thread/7206?ContentTypeID=1Tue, 18 Feb 2014 11:47:00 GMT137ad170-7792-4731-bb38-c0d22fbe4515:b7f8bed5-af83-473c-8db1-b8ed434b788ebart<p>I have followed your suggestion and indeed the reset command in the error handler was being called, I have put an infinite loop there with some debug prints and found the problem.</p> <p>I assumed that the output power setting has a linear scale but it uses a few discrete values. The setting I gave it was incorrect.</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/7205?ContentTypeID=1Tue, 18 Feb 2014 11:42:26 GMT137ad170-7792-4731-bb38-c0d22fbe4515:b6eec74c-2a14-477e-aa44-994fa286838aOle Morten<p>A reset loop usually indicates that some function returns an error, that is caught by an APP_ERROR_CHECK(), resulting in app_error_handler() being called.</p> <p>By default, this function contains a reset, but for development I&#39;d strongly recommend removing this reset and instead uncommenting the call to ble_debug_assert_handler(), or inserting an infinite loop and possibly some UART printing on your own. The app_error_handler() function gets the error code, file name and line number where the error occurred as arguments, so if you either halt the chip with a debugger or print this over UART, you should be able to easily find both the place at which the error occurred and hopefully also the cause.</p> <p>If you have trouble understanding the cause of the error, I&#39;d strongly recommend you to post a question about this separately, since there are any number of possible causes here.</p><div style="clear:both;"></div>