Interrupt from external Pin doesn't trigger with short pulse?

[noe]

Hi,
I need to implement a simple external interrupt triggered by another IC on a nrf51822. After searching the devzone I found the example in the GIT repo (github.com/.../nrf51_app_gpiote_example) which I used.

Everything works fine when I use a button, but when I change the pin to the one I actually want, it doesn't work. The signal is a 500ns long pulse (high) with 250Hz. I don't get the interrupt (neither rising nor falling edge). Is the pulse too short to detect? Shouldn't it be the edge that is detected?

Thanks in advance.

Noé

[Stefan Birnir Sverrisson]

Hi

The app_gpiote needs to have a pulse of approximately 10us in order to detect the pulse. What app_gpiote library uses internally is the GPIOTE->PORT event. The GPIOTE PORT event handler inside the app_gpiote library needs to read what pin the PORT event was received on, since the port event does not report what pin was asserted. By the time the execution of the GPIOTE interrupt handler starts executing, your signal has gone low again, so the app_gpiote library will detect no assert on a pin and will not notify your application of any pin event.

To detect a very short pulse, you would need to use the GPIOTE->IN events instead which is tied directly to a specific pin. See the \nRF51_SDK_8.0.0_5fc2c3a\examples\peripheral\pin_change_int example in the nRF51 SDK for code reference. The disadvantage is that using the GPIOTE->IN is a high power operation (~1mA)

[noe]

Thanks for your answer. I figured it out myself as I was reading through the examples. Its works now, although I'm a bit disappointed that it uses so much current as the interrupt will occur quite often and we're in a low power environment. Also I noticed that other things can trigger the interrupt as well. For example, I have a SD110 and I use BLE. While advertising, the indicator LED toggles and this triggers the event interrupt. I'm quite sure that I only listen to the pin I want to. Any suggestions there? I will post the code later, I'm not at my office right now. Thanks again

[Stefan Birnir Sverrisson]

Hmm, if you are using custom board and if traces are very tight together on the PCB, the signal might penetrate to the adjacent trace, could that be the case? To find out, try to configure the indicator LED to another pin. If that is not it, I would need to see some of your code.

[noe]

I had some time to analyze it a bit more and it seems that there are not more interrupts triggered but less are being handled. The core is just busier with BLE running and hence has not time in the main() loop to finish everything he has to do (which is triggered from the interrupt). Once the advertising() turns off, there are no more interrupt misses and the core has enough time to finish all it has to do.

[Stefan Birnir Sverrisson]

Yes, if you have a lot of radio activity, i.e. advertising with short advertising interval or transfering a lot of data when in a connection, you will have a lot less CPU availability for the application, see the SDS, chapter about Processor Availability. The application will however get more CPU availability with nRF51 third revision hardware (specified in S110 SDS 2.0) together with softdevice 8.0.0 than nRF51 second revision hardware and older softdevices (specified in S110 SDS 1.3). See the nRF51 compatibility matrix for what is second and third revision hardware.