<?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>Debugging without disconnect</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/5533/debugging-without-disconnect</link><description>Hi, 
 I understand the the Android Counter part will disconnect from the my NRDF board if for debugging purposes I stop at break point in the code. (I&amp;#39;m using Keil uVision). because of no ack after the connection interval time I guess. 
 Is there a</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Thu, 12 Feb 2015 15:55:37 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/5533/debugging-without-disconnect" /><item><title>RE: Debugging without disconnect</title><link>https://devzone.nordicsemi.com/thread/19349?ContentTypeID=1</link><pubDate>Thu, 12 Feb 2015 15:55:37 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:51abf82f-0bdc-4595-b066-7fbeb188aeb4</guid><dc:creator>Hung Bui</dc:creator><description>&lt;p&gt;Hi Mobi,&lt;/p&gt;
&lt;p&gt;It&amp;#39;s not possible to get back to a connection after you stop for a break point when debugging. The timing will not be correct after you resume, and most likely you will have a connection timeout from the peer device (which is not halted).
As mentioned by Bill, it&amp;#39;s better to use log message rather than breakpoint.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Debugging without disconnect</title><link>https://devzone.nordicsemi.com/thread/19348?ContentTypeID=1</link><pubDate>Thu, 12 Feb 2015 01:11:15 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:7b4ec1c2-1251-4f81-aada-5616e61c6418</guid><dc:creator>Bill Siever</dc:creator><description>&lt;p&gt;This isn&amp;#39;t quite what you asked for, but I&amp;#39;ve squashed many of my bugs with log messages (printing variable values and messages that help me see both the order of events and what code is being executed) rather than breakpoints.&lt;/p&gt;
&lt;p&gt;If you are using Segger&amp;#39;s J-Link, you can use Segger&amp;#39;s Real-Time Terminal (RTT) for logging over the J-Link cable. Thanks to forum member jeremysf  and post &lt;a href="https://devzone.nordicsemi.com/question/23763/j-link-rtt-for-easy-debug-prints/"&gt;devzone.nordicsemi.com/.../&lt;/a&gt; for sharing info. about RTT.&lt;/p&gt;
&lt;p&gt;Segger&amp;#39;s RTT package is available at:
&lt;a href="https://www.segger.com/jlink-real-time-terminal.html"&gt;www.segger.com/jlink-real-time-terminal.html&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;I&amp;#39;ve put together a blog entry with some directions and even a package that makes it a bit easier to start using RTT.  (The package is just an alpha version that suited my needs when I put it together. It could use an overhaul). If you&amp;#39;re interested take a look at: &lt;a href="http://siever.info/blog/?p=1"&gt;http://siever.info/blog/?p=1&lt;/a&gt;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>