<?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>NRF52 doesn&amp;#39;t work after a few days</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/24246/nrf52-doesn-t-work-after-a-few-days</link><description>I&amp;#39;m getting a weird behaviour on my first NRF52 custom board. It&amp;#39;s a BLE with HR, battery and a custom service. After programming I can test it properly with/without debugger and powered either by FTDI + Regulator or a battery. 
 For 2 times now the</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Thu, 01 Feb 2018 23:58:19 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/24246/nrf52-doesn-t-work-after-a-few-days" /><item><title>RE: NRF52 doesn't work after a few days</title><link>https://devzone.nordicsemi.com/thread/119446?ContentTypeID=1</link><pubDate>Thu, 01 Feb 2018 23:58:19 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:bc6bff97-3feb-4e62-bcfe-2036adf8afb5</guid><dc:creator>Nguyen Hoan Hoang</dc:creator><description>&lt;p&gt;Not working you mean not advertising ? If that is the case, check the advertising timeout. &amp;nbsp;Set it to 0 for non stop advertising otherwise it will stop at timet out. &amp;nbsp;The default was usually 180 seconds.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: NRF52 doesn't work after a few days</title><link>https://devzone.nordicsemi.com/thread/119444?ContentTypeID=1</link><pubDate>Thu, 01 Feb 2018 23:09:08 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:5561f9d4-9481-4614-83b8-3d199bd0659d</guid><dc:creator>Otavio Borges</dc:creator><description>&lt;p&gt;I had a similar issue. If your problem is recurrent (undoubtedly the BLE will froze) you could let the board running connected to the debugger, with a breakpoint on app_error_handler_bare and first lines of main. If, for some reason, your firmware is glitched you would trap the code before it reboots and use stacktrace to check from where is coming the error.&lt;/p&gt;
&lt;p&gt;I&amp;#39;ve done such using a custom board attached to the Nordic nrf52DK and eclipse as IDE. solved my problems.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: NRF52 doesn't work after a few days</title><link>https://devzone.nordicsemi.com/thread/95454?ContentTypeID=1</link><pubDate>Thu, 10 Aug 2017 21:22:28 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:04dd7bde-76f1-46de-8fa7-cd8c364a1191</guid><dc:creator>RK</dc:creator><description>&lt;p&gt;You can attach a debugger to a running chip, halt it and read the registers. Literally do exactly that, attach a debugger (JLink recommended), I&amp;#39;d use the command line to halt it and read the registers. Most IDEs will try hard to reset and reprogram so they won&amp;#39;t work well. If you try Segger&amp;#39;s excellent Ozone debugger I think you may be able to point it to the software image, attach it and get a full debugger at the point you&amp;#39;ve halted. Try it on a running chip, it&amp;#39;s a nice tool.&lt;/p&gt;
&lt;p&gt;Note that as soon as you do attach a debugger, you can&amp;#39;t single step (well you can if you use the debugger to instantly disable all interrupts to stop the softdevice getting any). So you really just have a frozen &amp;#39;moment in time&amp;#39; to work from, but that may be enough.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>