Is the interrupt triggered by a push button? If so this will probably be solved by taking debouncing measures. When you press a button it actually bounces up and down due to the inherent properties of the materials. Attach to a scope to watch the actual
The way to stop this is to only trigger your interrupt code once it doesn't receive another interrupt for some amount of time. Or in the hardware you can add a small RC circuit in between the button and the microcontroller.
Other than it being a debouncing issue, I see nothing wrong with your init code.
I'm using an infrared receiver that is pulled up by a 10k resistor, which I read from P15 (I'm not using it for battery measuring). I've attached a scope to the output of the IR LED and and triggered it such that I can control when the pin rises and falls. from looking the scope there the rise and falling edges don't noticeably bounce. I've reduced the ISR to just a print statement to show me when it fires and the interrupt fires for both rising and falling (verified with scope). is it possible that there could be something that would override my pin initialization and cause this behavior? I'm using a custom board a BCM20736s. I observed similar behavior while working with another module from embedded masters that used the BCM20736s.
There should be nothing overriding your configuration. The pin should be tristated but maybe change the configuration to output high? That would rule out the pin registering its own configuration as an interrupt since we want falling edge.
Also, I notice that in your configuration you first refer to pin as 'pin' then later to 'DIAL.' To the best of my knowledge these should be identical numbers.
You could also try configuring the pin after registering for interrupt instead of before. It shouldn't change anything, but that's the way I've always seen it done.
yes pin and dial are the same P15, just a typo when copying and pasting. I've tried setting it to output high and configuring after registering for interrupt, I get the same result. Do you know if there us an example I can try out? as I'm lost as to what the cause could be
I don't believe any of the sample applications in the SDK instantiate interrupts.
Can you attach scopes of the pin with the IR LED on it?
Can you test using a different GPIO?
I have a scope attached to the pin and the signal from the IR LED it very stable with smooth rise and falling edges.
I have another interrupt attached to a button on a different pin with an RC for denouncing and that too fires on both edges.
is it possible this is something related to the chip? I only ask because I used a very simple app supplied to me a while back on here and all the app did was toggle an LED on the rising edge and that too fired on both edges and this leads me to believe it must be the hardware, unless I'm wrong and missing something simple
What pin was the push button tested on?
And do you ever wipe the default configuration of P15 as the battery input in the GPIO configuration?
It is possible to work around this in the software if need be: just return form the function w/o code execution on every 2nd interrupt.
The button was tested on PIN 3.
I removed P15 as the battery input from platform.h.
my interrupt has to have very low latency as IR LED has rise and fall times of microseconds.
is it possible to tell which edge triggered the interrupt?
is it possible to poll the pin and detect the changes by doing ADC?
also just so I know, is it possible to get confirmation if edge triggering is possible on the BCM20763s?
Within that context, the developers responded and stated that the HW can detect the edges, but if the period of the pulse is too fast (in this context, on the order of 10uS), then the Firmware/app cannot handle every edge/transition.
Thank you for the link.
I have tried the edge triggering the interrupt at a much lower frequency however but it still triggers on both, so if the HW can detect the edges, is it possible for me to identify the edges in the application or within the interrupt?
do you know if I can maybe poll the state of the pin faster than the 12.5ms?
I can confirm that the hardware can detect both edges by the firmware seems to only be able to do edge triggering on the rising edge, it's a bit weird but I thought I at least leave a comment in case someone experiences the same issue