<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://devzone.nordicsemi.com/cfs-file/__key/system/syndication/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Unknown firmware crash on BLE connect</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/27537/unknown-firmware-crash-on-ble-connect</link><description>Hi,
i have a wierd behavior on my board.
On my nrf52832 custom board i have sdk14.1 with DEBUG flag and NRF_LOG enabled.
Usualy when my board crash i got into some kind of Falat error message. 
 But two times today my board has crashed when trying</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Mon, 27 Nov 2017 14:22:43 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/27537/unknown-firmware-crash-on-ble-connect" /><item><title>RE: Unknown firmware crash on BLE connect</title><link>https://devzone.nordicsemi.com/thread/108743?ContentTypeID=1</link><pubDate>Mon, 27 Nov 2017 14:22:43 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:f4bf990c-6647-434c-8a4a-a5156bbe6795</guid><dc:creator>MartinBL</dc:creator><description>&lt;p&gt;Yes, debugging BLE applications can be tricky, but if your board crashes you don&amp;#39;t care about timing sensitivity. You only care about what your nRF52 is doing when/after it has crashed.&lt;/p&gt;
&lt;p&gt;You say that you get some kind of Fatal error message. My guess is that your application crashes because one of your functions return an error, the error is inspected using APP_ERROR_CHECK(err_code), which finally sends your application into the function called app_error_fault_handler() (located in app_error_weak.c). If you use a debugger and set a breakpoint inside this function you can get the error code and the filename and line number of where the error originated.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Unknown firmware crash on BLE connect</title><link>https://devzone.nordicsemi.com/thread/108745?ContentTypeID=1</link><pubDate>Mon, 27 Nov 2017 08:53:33 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:7422ad47-77b8-44c6-95bc-fbf0f353d09d</guid><dc:creator>schef</dc:creator><description>&lt;p&gt;I have read that using a debugger in a BLE application is limited because of a radio time sensitivity?&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Unknown firmware crash on BLE connect</title><link>https://devzone.nordicsemi.com/thread/108744?ContentTypeID=1</link><pubDate>Mon, 27 Nov 2017 08:48:49 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:569a995b-300a-41c0-96ad-b9e9c2e0034b</guid><dc:creator>MartinBL</dc:creator><description>&lt;p&gt;Most programming IDEs, like Keil and Segger Embedded Studio for example, have a built in debugger. Ozone is a good choice if your IDE actually doesn&amp;#39;t have a debugger. Debugging is essential when developing embedded code, so if you are new to that sort of things I encourage you read up on it. Printing messages is fine for simple applications, but knowing how to debug will eventually save you a lot of time.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Unknown firmware crash on BLE connect</title><link>https://devzone.nordicsemi.com/thread/108742?ContentTypeID=1</link><pubDate>Fri, 24 Nov 2017 08:29:25 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:17cc3299-64fb-4dd1-8165-ea319882a3b8</guid><dc:creator>schef</dc:creator><description>&lt;p&gt;I am not so familiar with a debugger. What software do you use? Ozone? If i follow printed messages can i connect the Ozone software afterwards or i have to be in a &amp;quot;debug&amp;quot; mode and use software to backtrace the code? Does segger have some extra cool features that i don&amp;#39;t know they exist? :)&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Unknown firmware crash on BLE connect</title><link>https://devzone.nordicsemi.com/thread/108741?ContentTypeID=1</link><pubDate>Thu, 23 Nov 2017 16:56:53 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:bb742663-b0e4-412a-8dfb-70febb83b743</guid><dc:creator>MartinBL</dc:creator><description>&lt;ol&gt;
&lt;li&gt;It sounds like this happens rarely? What is the failure rate approximately?&lt;/li&gt;
&lt;li&gt;Are you able to use a debugger to see where the code ends up, instead of just relying on printed messages?&lt;/li&gt;
&lt;/ol&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>