<?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 DK does not run GPIOTE interrupt handler after some time with SoftDevice 132 present</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/12700/nrf52-dk-does-not-run-gpiote-interrupt-handler-after-some-time-with-softdevice-132-present</link><description>Hi All, 
 I&amp;#39;m having a problem with my application which involves regularly sampling I2C slave data and sending it over Bluetooth. The I2C slave generates an active high interrupt when new data is available, which signals my application to read the data</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Tue, 22 Mar 2016 20:13:37 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/12700/nrf52-dk-does-not-run-gpiote-interrupt-handler-after-some-time-with-softdevice-132-present" /><item><title>RE: nRF52 DK does not run GPIOTE interrupt handler after some time with SoftDevice 132 present</title><link>https://devzone.nordicsemi.com/thread/48234?ContentTypeID=1</link><pubDate>Tue, 22 Mar 2016 20:13:37 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:b3663730-fdf7-40f0-a42a-e2a99590a136</guid><dc:creator>bvuong87</dc:creator><description>&lt;p&gt;Seems I may have found the cause of my problem! Thanks to RK&amp;#39;s who helped point me into looking at missing GPIOTE events.&lt;/p&gt;
&lt;p&gt;While configuring my sensor input interrupt pin, GPIOTE sense from LOTOHI was set to use Low Accuracy.. i.e:&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;nrf_drv_gpiote_in_config_t gpioConfig = GPIOTE_CONFIG_IN_SENSE_LOTOHI(false);
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Switching this over to a high accuracy event seems to have resolved this problem through a few hours of testing this morning.&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;nrf_drv_gpiote_in_config_t gpioConfig = GPIOTE_CONFIG_IN_SENSE_LOTOHI(true);
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;The literature regarding the GPIOTE driver notes that low accuracy/power mode is not suitable for high speed pin changes which may be applicable to my sensor interrupt which fires an active high interrupt with a pulse width of 16us.&lt;/p&gt;
&lt;p&gt;Hope this helps somebody who encounters something similar&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: nRF52 DK does not run GPIOTE interrupt handler after some time with SoftDevice 132 present</title><link>https://devzone.nordicsemi.com/thread/48233?ContentTypeID=1</link><pubDate>Tue, 22 Mar 2016 01:17:15 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:4864b4de-e5db-4800-88b1-3497406d7562</guid><dc:creator>bvuong87</dc:creator><description>&lt;p&gt;RK - Thanks for the quick reply! I did come across issue 73 previously, and tried the workaround unsuccesfully, but am not completely certain I implemented it properly.&lt;/p&gt;
&lt;p&gt;I placed the workaround code into both the start of my main() as well as inside of the main() function&amp;#39;s infinite loop&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;if (*(volatile uint32_t *)0x4006EC00 == 0) 
{ *(volatile uint32_t *)0x4006EC00 = 0x9375; } 
*(volatile unit32_t *) 0x4006EC14 = 0xC0;
&lt;/code&gt;&lt;/pre&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: nRF52 DK does not run GPIOTE interrupt handler after some time with SoftDevice 132 present</title><link>https://devzone.nordicsemi.com/thread/48232?ContentTypeID=1</link><pubDate>Tue, 22 Mar 2016 00:44:29 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:80081fd3-b659-4d61-9342-505848f0cd66</guid><dc:creator>RK</dc:creator><description>&lt;p&gt;PCA10036 has lots of anomalies, including this one&lt;/p&gt;
&lt;p&gt;&lt;a href="http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52832.EngA.errata%2Fanomaly_832_73.html&amp;amp;anchor=anomaly_832_73"&gt;infocenter.nordicsemi.com/index.jsp&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;which affects GPIO interrupts among other things. Have you tried the workaround for that issue?&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>