Hi,
I would like to ask some questions on GPIO interrupt on DM6437.
I have a regular ISR which I configured to be triggered by the rising edge of GP[12]. There related code snippet is:
|
GPIO_DIR01= 0x00001000; //GP[12] direction as input GPIO_BINTEN |= 1;//Enable bank0
GPIO_SET_RIS_TRIG01=0x00001000;//Enable rising edge interrupt detection GPIO_CLR_FAL_TRIG01=0x00001000;//Disable falling edge interrupt detection
CSR |= 1; IER = 0x00000000 | (1<<1) // set INT5 and NMIE | (1<<5) ; INTC_INTMUX1= 0x00004800;//GP[12] has no direct interrupt; it must use GPIO Bank 0 interrupt number 72
|
And of course, there is an vector interrupt service table which associates the ISR function with the interrupt.
I have already reported one discrepancy between sprs345d and the actual measurement in GP[12] is IPU, not IPD: manual mistake? : GP[12] seems to have IPU rather than IPD.
Since GP[12] is high when unconnected, I uses a 0V signal to trigger it. Ideally:
1. When 0V pin touches GP[12], there is a falling edge since GP[12]'s input pin has its connected voltage transitioned from IPU to 0.
2. When 0V pin leaves GP[12], there is a rising edge corresponding to the effect of IPU, which would trigger an interrupt.
Therefore, there will be a total of 1 interrupt for a touch-then-leave action.
But my problem is that I have detected 4 interrupts rather than 1.
1. Two at "touch".
2. Two at "leave".
I have used a variety of mechanism to confirm my observation, including both static counter in ISR as well as LED lights on the board. I definitely get 4 interrupts for each "touch-then-leave".
I googled ti.com and there are two articles containing some information on configuring GPIO interrupt, among which the second is particularly relevant:
1. Configuring GPIO Interrupts
2. Avoiding Double Interrupts with the GPIO Peripheral
However, (2) suggests not enabling bank interrupt and pin interrupt at the same time for pins having their own direct interrupts, and this is exactly what I have done in the code snippet above: not using direct interrupt at all and only uses bank0's interrupt for GP[12]. Therefore I have already followed the guidelines there.
It is quite strange then for me to get this quadruple interrupts for a single "touch-leave" action. Especially for "touch", there is no rising edge and why I am still getting interrupts, and executed twice? For "leave", I expected once, not twice.
I also thought it possible to finally pinning down the cause to the rapidly changing transient voltage during the "touch-then-leave". I in fact did it in a quite reliable manner: GP[12] is connected to a hole on a high-quality breadboard, and then plug (touch) the 0V pin to another hole which is connected with the GP[12] hole on the breadboard, and unplug it after some time, both in an unhesitated manner. Nonetheless, I still observed rapidly oscillating transient waveform captured by oscilloscope in these two short intervals. The picture above is what happens when "leave", i.e., GP[12] being pulled back to high by its internal IPU. There is a strikingly large number of rising and falling in these short period.
So my questions are:
1. Why do I get 4 interrupts for each "touch-then-leave"? Why two even when there is no rising edge ("touch") when I configured only rising edge? Why two at "leave"?
2. Do they relate to the rapidly changing transient voltage? How frequently (in clock cycles) does GPIO interrupt module samples pin value? Please note that each grid in my oscilloscope is 250µs.
3. If it is due to the rapidly changing transient voltage that quadruple interrupts arises, how should I do to avoid it? In a product there must be buttons, and they are implemented using switches. As long as switches exist, there might exist the same short-time transient voltage as with my "touch-and-leave". Quadruple interrupts would make the buttons unusable. Therefore, what is the solution?
I of course can use time triggered interrupts to sample GPIO input pin value as an alternative way of implementing GPIO input interrupt, but this wastes timer resources. I could also write overhead statements in ISR to reduce 4 interrupts to 1 for each "touch-then-leave", but without knowing the underlying cause of the issue this approach is subjected to hidden problems. For these reasons, I believe the cause for this problem needs to be thoroughly investigated.
Zheng
