Edge trigger interrupt

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Hi,

I have an interrupt set up to fire on the falling edge, however when I trigger a level change on the pin, it fires for both the rising and the falling edge. any ideas what may be causing this? my pin set up is as below

//configure interrupt pin

    gpio_configurePin(GPIO_PORT(pin),GPIO_PIN(pin),

    GPIO_EN_INT_FALLING_EDGE,

    GPIO_PIN_OUTPUT_LOW);

UINT16 interrupt_handler_mask[3] = {0,0,0};

interrupt_handler_mask[0] = ((1 << GPIO_PIN(DIAL)));

gpio_registerForInterrupt(interrupt_handler_mask, measure_dose, NULL);

and all the interrupt does for now is just print a debug message to console.

0 Likes
11 Replies
JacobT_81
Employee
Employee
250 replies posted 100 replies posted 50 replies posted

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.

Jacob

0 Likes
Anonymous
Not applicable

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.

0 Likes
JacobT_81
Employee
Employee
250 replies posted 100 replies posted 50 replies posted

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.

Jacob

0 Likes
Anonymous
Not applicable

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

cheers

0 Likes
JacobT_81
Employee
Employee
250 replies posted 100 replies posted 50 replies posted

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?

Jacob

0 Likes
Anonymous
Not applicable

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

0 Likes
JacobT_81
Employee
Employee
250 replies posted 100 replies posted 50 replies posted

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.

Jacob

0 Likes
Anonymous
Not applicable

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?

0 Likes

jkindem​ and ldgirod​ had both discussed a similar issue here: interrupt latency

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.

0 Likes
Anonymous
Not applicable

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?

0 Likes
Anonymous
Not applicable

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

0 Likes