<?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>Why does using P0.0 as uart RX cause BLE stack to hang?</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/15395/why-does-using-p0-0-as-uart-rx-cause-ble-stack-to-hang</link><description>I have a custom board that doesn&amp;#39;t use the external 32Khz crystal. The engineer that designed it chose to use P0.0 as UART RX. (I know, poor choice.) I have set up a custom_board.h file with the RC oscillator and if I set the RX as P0.8, it works fine</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Fri, 29 Jul 2016 11:51:28 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/15395/why-does-using-p0-0-as-uart-rx-cause-ble-stack-to-hang" /><item><title>RE: Why does using P0.0 as uart RX cause BLE stack to hang?</title><link>https://devzone.nordicsemi.com/thread/58794?ContentTypeID=1</link><pubDate>Fri, 29 Jul 2016 11:51:28 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:d0a5018f-acc3-447d-9c87-583f3e3a63e6</guid><dc:creator>Ole Bauck</dc:creator><description>&lt;p&gt;You are correct, connecting RX pin to a VDD or TX will remove the issue (however connect it to ground did not solve it for me). It is probably just noise and P0.00 or P0.01 is more susceptible for noise, but this can be the PCB as much as the chip itself.&lt;/p&gt;
&lt;p&gt;I still see no difference when I enable the SoftDevice.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Why does using P0.0 as uart RX cause BLE stack to hang?</title><link>https://devzone.nordicsemi.com/thread/58793?ContentTypeID=1</link><pubDate>Fri, 29 Jul 2016 09:40:37 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:a3e22640-9c59-48d6-ae8a-9faed17bb601</guid><dc:creator>JimG</dc:creator><description>&lt;p&gt;Try one more thing. Change TX_PIN_NUMBER to 1 and then loopback 1 to 0. I think you are just seeing noise. Without the loopback, I get the uart error. With the loopback, I don&amp;#39;t get any uart events at all. Even with the loopback, I get the spurious interrupt on 0 during SOFTDEVICE_HANDLER_INIT with the BLE code uncommented.
Edit: or just tie 0 to ground.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Why does using P0.0 as uart RX cause BLE stack to hang?</title><link>https://devzone.nordicsemi.com/thread/58792?ContentTypeID=1</link><pubDate>Fri, 29 Jul 2016 09:15:05 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:ee75c40e-a958-4490-bccc-5e491d3df9cd</guid><dc:creator>Ole Bauck</dc:creator><description>&lt;p&gt;I took the ble_app_uart example and commented out all except uart_init() in main(), changed RX_PIN_NUMBER to 0 and defined DEBUG in the preprocessor symbols. When I debug I can see that the it stops in the error handler. This was done on a DK with SB1 and SB2 cut, and SB3 and SB4 bridged.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Why does using P0.0 as uart RX cause BLE stack to hang?</title><link>https://devzone.nordicsemi.com/thread/58791?ContentTypeID=1</link><pubDate>Fri, 29 Jul 2016 00:42:47 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:a59c9de5-878c-4139-8ef1-af0d7503b843</guid><dc:creator>JimG</dc:creator><description>&lt;p&gt;Thanks! That helps a lot. I still think it is something in the SoftDevice. To test on the DK, you would have had to disconnect the external crystal by cutting the SB1 and SB2 traces and soldering SB3 and SB4. Doing that, it does not generate an error without the SoftDevice. If you initialize the SoftDevice to use the RC oscillator (since the crystal is disconnected), an interrupt is generated on P0.0 that causes the Communication Error. If you use a different pin for the receiver, the interrupt is not generated.&lt;/p&gt;
&lt;p&gt;At any rate, once I ignore that first communication error, it all seems to work fine. Thanks again!&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Why does using P0.0 as uart RX cause BLE stack to hang?</title><link>https://devzone.nordicsemi.com/thread/58790?ContentTypeID=1</link><pubDate>Thu, 28 Jul 2016 11:03:32 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:5324d501-b00a-4b09-94af-236c7ac89fc4</guid><dc:creator>Ole Bauck</dc:creator><description>&lt;p&gt;I tested this on the DK and got the same problem, using pin 0 or 1 as UART RX would cause the device to hang at the next SoftDevice call it seemed.&lt;/p&gt;
&lt;p&gt;After some investigation I found out that it was actually the UART event handler calling the &lt;code&gt;APP_ERROR_HANDLER&lt;/code&gt; because of a &lt;code&gt;APP_UART_COMMUNICATION_ERROR&lt;/code&gt; event. Defining DEBUG in the preprocessor symbols showed that the application would go into the error handler and stop the execution.&lt;/p&gt;
&lt;p&gt;The problem is that when using pin 0 or 1 for UART RX the UART peripheral will get an error event as soon as it is enabled, which will lead to the UART event handler calling the error handler. The solution is to ignore the first &lt;code&gt;APP_UART_COMMUNICATION_ERROR&lt;/code&gt; and not call &lt;code&gt;APP_ERROR_HANDLER(p_event-&amp;gt;data.error_communication)&lt;/code&gt;.&lt;/p&gt;
&lt;p&gt;The problem is not related to the SoftDevice. I tested without enabling the SoftDevice and got the same error.&lt;/p&gt;
&lt;p&gt;I will report this internally so that we can fix this. Thank you for noticing the issue.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>