<?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>GPIOTE Interrupt doesn&amp;#39;t catch button press</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/39869/gpiote-interrupt-doesn-t-catch-button-press</link><description>Hi all, 
 I am currently developing on the RIGADO BMD-300 (nRF52832) eval board. I have the following code setup to interrupt on a button press (aim is to have 9 buttons). I am storing the current state of the button in a single byte ( m_custom_value</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Tue, 06 Nov 2018 07:03:40 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/39869/gpiote-interrupt-doesn-t-catch-button-press" /><item><title>RE: GPIOTE Interrupt doesn't catch button press</title><link>https://devzone.nordicsemi.com/thread/156056?ContentTypeID=1</link><pubDate>Tue, 06 Nov 2018 07:03:40 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:ddf09dea-3389-4514-babc-de203c23ef19</guid><dc:creator>Zoran</dc:creator><description>&lt;p&gt;Hi Einar,&lt;/p&gt;
&lt;p&gt;I solved my problem. thanks&amp;nbsp;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: GPIOTE Interrupt doesn't catch button press</title><link>https://devzone.nordicsemi.com/thread/156033?ContentTypeID=1</link><pubDate>Mon, 05 Nov 2018 19:26:15 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:fd91a77b-fbe9-4fb1-9866-19852bb0217b</guid><dc:creator>Zoran</dc:creator><description>&lt;p&gt;Please refer to my other post for more information on my implementation.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: GPIOTE Interrupt doesn't catch button press</title><link>https://devzone.nordicsemi.com/thread/156032?ContentTypeID=1</link><pubDate>Mon, 05 Nov 2018 19:24:23 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:057842de-44f5-4a54-9bfa-54cbf8dfe49d</guid><dc:creator>Zoran</dc:creator><description>&lt;p&gt;I agree that this was a problem when using the interrupt directly, but I am now using the button handling library through bsp on the development board and even the buttons on the dev board are not captured properly at 50Hz.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: GPIOTE Interrupt doesn't catch button press</title><link>https://devzone.nordicsemi.com/thread/155932?ContentTypeID=1</link><pubDate>Mon, 05 Nov 2018 11:59:04 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:6f0d0614-5630-47a9-8821-7a77b657f984</guid><dc:creator>Einar Thorsrud</dc:creator><description>&lt;p&gt;Hi,&lt;/p&gt;
&lt;p&gt;From our earlier discussion I remember that you found that there is a large number of interrupts per button event (due to bounce). It is expected that these are lost if these are not services immediately due to a higher priority interrupt (SoftDevice), as the CPU cannot queue up multiple interrupts for the same source (interrupt number). So to handle this you should limit the number of interrupt by low-pass filtering the button presses (using a capacitor).&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: GPIOTE Interrupt doesn't catch button press</title><link>https://devzone.nordicsemi.com/thread/155914?ContentTypeID=1</link><pubDate>Mon, 05 Nov 2018 10:35:44 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:2665983b-6967-417c-8220-f9782e9c590d</guid><dc:creator>Zoran</dc:creator><description>&lt;p&gt;Hi Einar,&lt;/p&gt;
&lt;p&gt;As I mentioned in my other post, I was able to implement a solution based on the bsp library. I thought I would give this approach a try as I wanted to try to work with a custom board header file for my application. I am not sure if there is some limitation with this approach but I cannot seem to detect button presses when I increase the frequency of the timer/notifications to 50Hz. I can&amp;rsquo;t even trigger the original BLE button 1 disconnect function &amp;nbsp;at this rate. Any idea what might be causing this or how to resolve it?&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: GPIOTE Interrupt doesn't catch button press</title><link>https://devzone.nordicsemi.com/thread/155454?ContentTypeID=1</link><pubDate>Thu, 01 Nov 2018 00:38:57 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:729f9d6c-2b59-458c-8877-6277c7b44efe</guid><dc:creator>Zoran</dc:creator><description>&lt;p&gt;Thank you Einar. Much appreciated for your support.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: GPIOTE Interrupt doesn't catch button press</title><link>https://devzone.nordicsemi.com/thread/155349?ContentTypeID=1</link><pubDate>Wed, 31 Oct 2018 13:45:48 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:2c9e7337-130e-49b1-b3fd-6f7294eaa4a5</guid><dc:creator>Einar Thorsrud</dc:creator><description>&lt;p&gt;The button handling library will give you events when buttons are pressed and released. This has not direct implication on BLE or anything else, but then you should do whatever you what to do in the event handler. You should find examples of most of the things you mention by looking through the &lt;a href="http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.sdk5.v15.2.0/examples_ble.html?cp=4_0_0_4_1"&gt;BLE examples&lt;/a&gt;.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: GPIOTE Interrupt doesn't catch button press</title><link>https://devzone.nordicsemi.com/thread/155257?ContentTypeID=1</link><pubDate>Wed, 31 Oct 2018 06:54:20 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:ae1ea550-9e3e-403a-9ec6-18d0c2591313</guid><dc:creator>Zoran</dc:creator><description>&lt;p&gt;I have extended the&amp;nbsp;&lt;span&gt;ble_app_template to include a custom service that&amp;nbsp; sends notifications to a central device. As mentioned earlier, the peripheral will need to monitor the state of 9 push buttons and 1 analog input. I am not sure how to implement the following BLE button functions directly through the button library. These should include wake up, sleep, disconnect, wakeup bond delete and whitelist off as is currently working in this&amp;nbsp;ble_app_template example. Any chance you could point me in the right direction?&amp;nbsp;&lt;/span&gt;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: GPIOTE Interrupt doesn't catch button press</title><link>https://devzone.nordicsemi.com/thread/155235?ContentTypeID=1</link><pubDate>Tue, 30 Oct 2018 23:27:38 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:489c3e92-d454-444c-b9f4-3b19de8a5bca</guid><dc:creator>Zoran</dc:creator><description>&lt;p&gt;Hi Einar,&lt;/p&gt;
&lt;p&gt;Do you recommend that i remove the BSP implementation in the &lt;span&gt;ble_app_template&amp;nbsp;&lt;/span&gt;example and implement the few BLE button funtions via the button handling library myself, and then expand this to include my other buttons?&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: GPIOTE Interrupt doesn't catch button press</title><link>https://devzone.nordicsemi.com/thread/155196?ContentTypeID=1</link><pubDate>Tue, 30 Oct 2018 15:35:10 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:63911543-e729-4c9d-958e-3934971e8fa8</guid><dc:creator>Einar Thorsrud</dc:creator><description>&lt;p&gt;The button handling library (app_button)&amp;nbsp; uses the app timer library, which is a library that is used to share RTC1 amongst an arbitrary number of timers, so there will not be any conflicts in that regard.&lt;/p&gt;
&lt;p&gt;I personally find the BSP a bit too complex for simple applications. It makes sense in the SDK where we need to support a large variety of boards, but less for other applications. So I would&amp;nbsp;probably use the button handling library directly instead of via the BSP, but that is just my preference.&lt;/p&gt;
&lt;p&gt;If you want to use the button library directly you can for instance refer to how it is used in the BSP (bsp.c), or perhaps better one of the other applications that use it directly, for instance ble_app_blinky.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: GPIOTE Interrupt doesn't catch button press</title><link>https://devzone.nordicsemi.com/thread/155041?ContentTypeID=1</link><pubDate>Tue, 30 Oct 2018 09:22:33 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:1a1fae36-2ff7-4fd1-9a22-3222b2ce9432</guid><dc:creator>Zoran</dc:creator><description>&lt;p&gt;Hi Einar,&lt;/p&gt;
&lt;p&gt;Thank you for this feedback. As my&amp;nbsp;BLE application is based on the &lt;span&gt;ble_app_template&amp;nbsp;&lt;/span&gt;example and it uses the BSP BLE Button Module,&amp;nbsp;do i need to be aware of any conflicts with the Button handler, for example with timers?&amp;nbsp;&lt;/p&gt;
&lt;p&gt;Also, is this a good example to follow for this?&amp;nbsp;&lt;a href="https://github.com/NordicPlayground/nrf51-app-button-example/blob/master/main.c"&gt;https://github.com/NordicPlayground/nrf51-app-button-example/blob/master/main.c&lt;/a&gt;&amp;nbsp;&lt;/p&gt;
&lt;p&gt;I have also seen others on here suggesting to make a custom board header file and using the BSP functionality to handle buttons. Are there any benefits to doing this over using the button handling library?&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: GPIOTE Interrupt doesn't catch button press</title><link>https://devzone.nordicsemi.com/thread/155006?ContentTypeID=1</link><pubDate>Tue, 30 Oct 2018 08:21:53 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:2092fc68-96c7-453a-b692-2e61bf4a3f48</guid><dc:creator>Einar Thorsrud</dc:creator><description>&lt;p&gt;That explains it. You need to low pass filter the button (hardware debouncing) if you want a single interrupt for each button transition. If not you need to handle multiple rapid interrupts (due to switching noise), and debounce in software.&lt;/p&gt;
&lt;p&gt;I would say that the best approach is to filter the button signal as we do in the DK, as this limits the number of interrupts you have to handle in a short time. You could do software debouncing in addition to be sure, but you might not need it. I you want software debouncing you can for instance use the &lt;a href="http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.sdk5.v15.2.0/lib_button.html?cp=4_0_0_3_7"&gt;Button handling library&lt;/a&gt;.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: GPIOTE Interrupt doesn't catch button press</title><link>https://devzone.nordicsemi.com/thread/154982?ContentTypeID=1</link><pubDate>Tue, 30 Oct 2018 05:42:54 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:dc137d4a-f2ce-4c70-bcb0-3d487e108e91</guid><dc:creator>Zoran</dc:creator><description>&lt;p&gt;Btw, The interrupt priority in the sdk_config.h is set to 6&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: GPIOTE Interrupt doesn't catch button press</title><link>https://devzone.nordicsemi.com/thread/154981?ContentTypeID=1</link><pubDate>Tue, 30 Oct 2018 05:40:04 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:36932958-76de-4b56-9463-1b6e93fd7681</guid><dc:creator>Zoran</dc:creator><description>&lt;p&gt;Hi Einar,&lt;/p&gt;
&lt;p&gt;I did some further investigation. I used the pin_change_int example as this does not use the softdevice and updated the input button to a pin on the dev board that i have an external pushbutton connected to (pin P0.11). I discovered on the oscilloscope that the interrupt is catching the button press but because of the mechanical contact bounce, it is toggling the output multiple times. I then switched the input to one of the 4 buttons on the dev board and found this to work perfectly. After looking at the schematic for the dev board, each button has ESD protection. Would this be the main reason why the on-board buttons work correctly? if this is the case, i can definitely add this to my custom board.&lt;/p&gt;
&lt;p&gt;Also, when i tried to access these buttons in my BLE code (based on the ble_app_template), the code doesn&amp;#39;t run (there is no advertising). I know that the&amp;nbsp;ble_app_template uses button 1 to wake up and advertise, but why cant i access the other 3 buttons?&lt;/p&gt;
&lt;p&gt;Another question: What is the best approach to add buttons and outputs to a custom board with BLE? Is it to use the BSP module or this approach with my own interrupt handler?&lt;/p&gt;
&lt;p&gt;&lt;/p&gt;
&lt;p&gt;Thanks heaps for your support.&lt;/p&gt;
&lt;p&gt;Zoran&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: GPIOTE Interrupt doesn't catch button press</title><link>https://devzone.nordicsemi.com/thread/154819?ContentTypeID=1</link><pubDate>Mon, 29 Oct 2018 09:41:04 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:eba873d4-7e8b-41e8-b8e9-9e6590a2a2cc</guid><dc:creator>Einar Thorsrud</dc:creator><description>&lt;p&gt;Hi,&lt;/p&gt;
&lt;p&gt;You are right that the interrupt will be blocked by any higher priority interrupts (for instance from the SoftDevice). This would lead to a delay in the handling of the interrupt, but the only way you would lose an interrupt is if there are multiple interrupts while being blocked by a higher priority interrupt. This does not seem very likely though, as button presses are typically quite slow compared to the maximum block time for a SoftDevice interrupt (see &lt;a href="http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s132.sds/dita/softdevices/s130/processor_avail_interrupt_latency/processor_usage_patterns.html?cp=2_3_1_0_15_2"&gt;Processor usage patterns and availability&lt;/a&gt;), except for a few special cases such as during flash erase operations.&lt;/p&gt;
&lt;p&gt;Do you have any other interrupt sources in your application? What is the interrupt priority for GPIOTE in your application (GPIOTE_CONFIG_IRQ_PRIORITY set in the projects sdk_config.h)?&lt;/p&gt;
&lt;p&gt;Br,&lt;/p&gt;
&lt;p&gt;Einar&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: GPIOTE Interrupt doesn't catch button press</title><link>https://devzone.nordicsemi.com/thread/154740?ContentTypeID=1</link><pubDate>Sat, 27 Oct 2018 07:29:47 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:ad341cce-5103-4845-99d5-f20081c578cf</guid><dc:creator>Zoran</dc:creator><description>&lt;p&gt;Hi Einar,&lt;/p&gt;
&lt;p&gt;Thanks for the feedback. I have setup an output pin and toggled this in the&amp;nbsp;&lt;span&gt;in_pin_handler() event handler along with storing the state of the button as in the code above in value[] byte. I was observing the state of the output pin on an oscilloscope as i was pressing a momentary pushbutton connected to the input. With this setup i could frequently see that during the button press the interrupt would not capture the event (whether high to low (push down) or low to high (release button).&amp;nbsp;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;I am doing this in conjunction with sending the value of &amp;quot;value[]&amp;quot; over BLE. Do you think that BLE will conflict with the button interrupt priority?&lt;/span&gt;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: GPIOTE Interrupt doesn't catch button press</title><link>https://devzone.nordicsemi.com/thread/154684?ContentTypeID=1</link><pubDate>Fri, 26 Oct 2018 13:13:31 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:41506099-637e-4a1d-b79c-a99269d1de95</guid><dc:creator>Einar Thorsrud</dc:creator><description>&lt;p&gt;Hi,&lt;/p&gt;
&lt;p&gt;I do not immediately see any issue with your setup, and I would not expect you to lose interrupts. How have you verified this? Could you for instance toggle a GPIO in the event handler (&lt;span&gt;in_pin_handler()&lt;/span&gt;) and use a logic analyzer to observe the toggled pin(s) in relationship with the input pins, to see verify if that is really the case?&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>