MSP430AFE221: False interrupt on the controller

I am using the similar interrupt example for my system,

void main(void)
{
WDTCTL = WDTPW + WDTHOLD; // Stop WDT 
CCTL0 = CCIE; // CCR0 interrupt enabled
TACTL = TASSEL_2 + MC_1 + ID_3; // SMCLK/8, upmode
CCR0 = 10000; // 12.5 Hz 
P1OUT &= 0x00; // Shut down everything
P1DIR &= 0x00; 
P1DIR |= BIT0 + BIT6; // P1.0 and P1.6 pins output the rest are input 
P1REN |= BIT3; // Enable internal pull-up/down resistors
P1OUT |= BIT3; //Select pull-up mode for P1.3
P1IE |= BIT3; // P1.3 interrupt enabled
P1IES |= BIT3; // P1.3 Hi/lo edge
P1IFG &= ~BIT3; // P1.3 IFG cleared
_BIS_SR(CPUOFF + GIE); // Enter LPM0 w/ interrupt 
while(1) //Loop forever, we work with interrupts!
{}
} 

// Timer A0 interrupt service routine 
#pragma vector=TIMERA0_VECTOR 
__interrupt void Timer_A (void) 
{ 
P1OUT ^= BIT0; // Toggle P1.0 
} 
// Port 1 interrupt service routine
#pragma vector=PORT1_VECTOR
__interrupt void Port_1(void)
{ 
P1OUT ^= BIT6; // Toggle P1.6
P1IFG &= ~BIT3; // P1.3 IFG cleared 
}

So the overall system consist of a lot of peripherals communicating through the SPI bus, I2C bus and UART. I have connected 3 interrupt pins for subroutine operations, we have to connect a push button via a wire that grounds the pin with pressed. The interrupt pin is pulled up and connected to a screw terminal for connections with the button. Cases when false interrupt are triggered:-

1. When the wire is not connected, interrupt is pulled up, we touch the pin terminal with a metal.

2. The wire is connected and button not attached to the end, When we touch the other end of wire the interrupt gets triggered.

3. When both the wire and button are connected, It sometimes works just fine, following the normal routine and the subroutine when button is pressed. However in some cases there is an interrupt detected and the subroutine called. We have tested 10 systems in this configuration and around 4 of them show this behavior.

Also note that there are no power rails in the vicinity of the interrupt trace that may cause any problem.

The whole is PCB has ground plane for noise immunity in order to ground any noise element.

Thank you

Hi everybody,

Sorry for the delayed response from my side, I tested the interrupt terminal using a digilent USB scope and found the attached result when it is touched with a metal stick.

Note that this only happens when we give an external touch. Is it due to hardware design?

Are there any steps that I can do to minimize this so that no false interrupts are processed by the core.

Thanks

Hey Shwetank,

Thanks for the captures!   This does seem to be a problem from the hardware design/debounce circuitry. 

Have you tried also adding a few different sizes of capacitors?  It looks like these are extremely quick pulses, so I think they should be able to be smoothed out with a larger capacitor.   

If that doesn't work, can you provide a schematic for the circuit connected to the GPIO for the community to review?    

Thanks,

JD

hi,

Yes the spikes are of approx. 20micro seconds. Earlier we added parallel bypass capacitors 0.1micro value but during the initialization, the system used to hand and no functionalities were working so once we removed them it used to come back to life. That was the reason for not connecting any caps in the circuit.

The further wires goes to interrupt pins of the controller. However as described above, in the actual board we have depopulated these capacitors to avoid charging discharging that perhaps caused the system hangs.

Also I have tried using RC circuits with 0.1micro cap and 1-10K resistor but the response were more or less similar.

Thanks

Thanks

hello JD Crutchfield 

Thanks for the suggestions on finding the right hardware filter and choosing a smaller capacitor for the same. However I faced some problems earlier while using a software debounce routine.

I used the timer approach for waiting for 5ms and then rechecking the signal for available interrupt and hosting the flag accordingly. However this solved the issue in three of four terminals but one terminal which is connected to a pulse output of another device that gives 1s LOW pulse output at indefinite intervals used to get stuck in the subroutine since the input from that device triggered the interrupts using the same spikes that I discussed with you guys.

Note that in case of the pulse output device I am using a long wire about 10meter to get the 24volt pulse and then drop it down to microcontroller level using a regulator. When the terminal is not at all connected, it works fine but while I connect it to the device, I see these spikes all again, that triggers the interrupt and due to timer delays it gets stuck at that point only.

The other interrupts however works fine when I use the delay.

Thank again

Regards