LPCXpresso 1769: GPIO Interrupt issues

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

LPCXpresso 1769: GPIO Interrupt issues

907 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by gweppler on Wed Jan 25 22:56:10 MST 2012
Hello,
I am trying to use GPIO interrupts to interface to 3 button switches to an LPCXpresso 1796. The buttons are active high to 5V, the pins use internal pull-down, rising edge INT. pins 0.0, 0.6, 0.7 are all used in the same configuration.

IO0IntEnR is set to 0xc1 (pins 0.0, 0.6, 0.7 config’d for rising edge event).
  
  If I press any of the 3 buttons,

[LIST]
[*]- the EINT3_IRQHandler gets invoked as expected.
[*]- Upon entry into the handler, IOIntStatus is 0x1, indicating a GPIO int from port 0.
[*]- However, IO0IntStatR almost always also logs rising edge events on the other two pins – sometimes only on one of the two other pins.
[/LIST]
    I confirmed that the pins are electrically isolated from one another (except the common GND or +5V). I verified signals on all pins with the oscilloscope and they all seem clean. I have tried other combinations (using port 2 / other pins instead, using active low buttons with pull-up, etc.) but they're all showing basically the same behavior.
  
My partial code (lines that are commented out don’t seem to make a difference):
  
//*********************************************************************
void EINT3_IRQHandler(void)
{
   unsigned long regVal;

   regVal = LPC_GPIOINT->IntStatus;                       //for debugging only

   if (((LPC_GPIOINT->IO0IntStatR)&(1<<0)) == (1<<0))  {  //rising edge int?
      LPC_GPIOINT->IO0IntClr = (1<<0);
      key=enter;
   }
   if (((LPC_GPIOINT->IO0IntStatR)&(1<<6)) == (1<<6))  {  //rising edge int?
      LPC_GPIOINT->IO0IntClr = (1<<6);
      key=up;
   }
   if (((LPC_GPIOINT->IO0IntStatR)&(1>>7)) == (1<<7))  {  //rising edge int?
      LPC_GPIOINT->IO0IntClr = (1<<7);
      key=down;
   }
   return;
}


//*********************************************************************
int main(void) {
   uint32_t KEY_PINS = ( BIT0 | BIT6 | BIT7 );    //keypad button connections (P0.0/6/7). buttons are active high.

   //LPC_SC->PCONP        |= (1<<15);                      //power to GPIO block on (default is on)
   LPC_PINCON->PINSEL0    &= ~((3<<0)|(3<<12)|(3<<14)); //set p0.0/6/7 to GPIO (00) function (button connection)
   LPC_GPIO0->FIODIR      &= ~KEY_PINS;                 //set key pins to input (0)
   LPC_PINCON->PINMODE0   |=  ((3<<0)|(3<<12)|(3<<14)); //pull down
   LPC_GPIOINT->IO0IntEnR |=  KEY_PINS;                 //enable rising edge INT (1)

   NVIC_EnableIRQ(EINT3_IRQn);                  //Enable EINT3 interrupt */
   //LPC_SC->EXTINT = CLEAR_EINT3;              //clr the EINT3 interrupt flags
   //LPC_GPIOINT->IO0IntClr = KEY_PINS;         //clr all pending GPIOINTs

   while (1) 
       ;
   return 0;
}
[B]Questions:[/B]
  1) How can I ensure I get only the GPIO interrupt only from the pin that had the actual rising/falling edge?

  2) When I  configured the GPIO pins w/ pull-up and to trigger on falling edge (with buttons connecting to GND and thus, a different configuration as the one above), I measure around 2.04V on the GPIO pins when the button isn’t pressed or when there’s nothing connected at all. That seems to be within what the 17xx defines as “high” level (2V or more). Any ideas why I would see a value this close to an undefined signal state?
  
  Thanks in advance for any hints.
  
  Regards,
  Guido
0 Kudos
6 Replies

526 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Rob65 on Fri Jan 27 01:08:39 MST 2012
If I remember well you are relying on the internal pull downs of the MCU.
I am sometimes having problems with those - the pull up/downs are just to weak to handle any noise on neighboring pins.

Therefor I always use external pull up/downs - except of course for those quick tests that I do with just an LPCXpresso module ...
When I then see strange results I know what to do.

Regards,
[INDENT]Rob
[/INDENT]
0 Kudos

526 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by gweppler on Thu Jan 26 19:17:24 MST 2012
Thanks for the testing effort and the super fast response - this solved it.

I had  these buttons connected to 5V at first and 3.3V now -- in both cases  without resistor, as I had measured <70uA per pin when the button was  pressed and that seemed within safe limits. Still not sure why this  didn't work but using a <1k resistor now, the problem seems fixed and  I'm getting repeatable results.
0 Kudos

526 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Ex-Zero on Thu Jan 26 17:02:54 MST 2012
[LEFT]I've tested you code here and (without typo) it was running without problems :eek:
But , of course, I don't know how your buttons are connected.
Since they are 5V I hope you've added a resistor to protect your input?

Same test here (5V via 680 Ohm) shows a correct input status of 0x80, 0x40 or 0x01 :)
[/LEFT]
0 Kudos

526 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by gweppler on Thu Jan 26 16:56:02 MST 2012
Thank you Rob and Zero for your responses. Sorry for the typo in the code. However, I don't think that's relevant to my problem, because of how GPIOINTMAP looks before and upon entry to the handler:

1) After init (line LPC_GPIOINT-->IO0IntEnR |= KEY_PINS; )

[ATTACH]655[/ATTACH]

2) After pressing a single button only, IO0IntStatR has multiple bits set upon entry to the EINT3_IRQHandler (breakpoint on first line of handler):

[ATTACH]657[/ATTACH]

The IO0IntStatR's 0xc0 shows that pins 0.6 and 0.7 registered a rising edge, where in fact only the button on 0.6 was pressed.

Given Rob's indication that this should work, and the fact that also this time the oscilloscope didn't show any activity on 0.7 while the 0.6 button was pressed, can I assume I may be working on a faulty MCU here?
0 Kudos

526 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Rob65 on Thu Jan 26 08:50:05 MST 2012

Quote: Zero
What is that line doing :eek:

if (((LPC_GPIOINT->IO0IntStatR)&(1[COLOR=Red]>>[/COLOR]7)) == (1<<7))  {  //rising edge int?



I thought you'd be smarter than this :eek:

This is just an homage to one of our famous forum members.

You must have noticed that (LPC_GPIOINT->IO0IntStatR)&(1[COLOR=Red]>>[/COLOR]7))equals [B]Zero

[/B]I can confirm that the GPIO interrupts do work as expected (just used them yesterday) and that the IntStat register indeed only shows Ones for active interrupts.
Regards,[INDENT]Rob (the only One ;))
[/INDENT]
0 Kudos

526 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Ex-Zero on Thu Jan 26 05:02:18 MST 2012
Sorry, I don't understand your code :confused:

What is that line doing :eek:

if (((LPC_GPIOINT->IO0IntStatR)&(1[COLOR=Red]>>[/COLOR]7)) == (1<<7))  {  //rising edge int?
0 Kudos