Interrupts keep triggering without changing pin state.

I’m having an issue with interrupts being triggered pin changes which are happening while interrupts are detached.

Here is a minimal version of my program:
Pin 3 is an interrupt
Pin 7 is used to detect an interrupt by manually connecting and diconnecting a wire between them.

After the interrupt is triggered, the interrupt is detached and the loop is reset.

The problem is that when interrupt is attached to pin 3 on the second loop, if it is connected to pin 7, it will instantly interrupt and reset the loop despite not changing state.

If I comment out test(); then it stops happening, so I can only assume is has something to do with changing pin 7 while interrupt is disabled.

The only think I can think of is that somehow Pin 3 is detecting the change when the interrupt is detached, and as soon as it is reattached it is acting on that change.

bool result[24][24];
volatile bool resetdetect = false;


void setup() {

  Serial.begin(250000);

}



void loop() {


  Serial.println("Start Loop");
  Serial.println("Run Test");
  test();
  Serial.println("Interrupt setup");
  pinMode(7, OUTPUT);
  digitalWrite(7, HIGH);
  pinMode(3, INPUT);
  attachInterrupt(digitalPinToInterrupt(3), reset, CHANGE);
  Serial.println();
  Serial.println();
  Serial.println();
  while (resetdetect == false) {             //holds program here until interrupted
  }
  resetdetect = false;
}






void reset() {
  resetdetect = true;
  detachInterrupt(digitalPinToInterrupt(3));
}




void test() {
  for (int x = 4; x <= 27; x++) {
    pinMode (x, OUTPUT);
    digitalWrite (x, LOW);



    for (int y = 28; y <= 51; y++) {
      pinMode (y, INPUT_PULLUP);
      result[x - 4][y - 28] = !digitalRead(y);

      pinMode (y, INPUT);

    }

    pinMode (x, INPUT);




  }



}

WOW, someone had some spare newlines laying around!

Spagoose:
by manually connecting and diconnecting a wire between them.

You mean you connect or disconnect a wire to pin 3?

You don't have the internal pull up enabled. So when noting is connected to pin 3 it's floating and it will just pick up everything. A not connected pin does not mean LOW :wink:

septillion:
WOW, someone had some spare newlines laying around!
You mean you connect or disconnect a wire to pin 3?

You don't have the internal pull up enabled. So when noting is connected to pin 3 it's floating and it will just pick up everything. A not connected pin does not mean LOW :wink:

I am shorting pin 3 and pin 7 manually with wire.

I have a 10k pulldown resistor between pin 3 and GND as well.

Also the issue is only happening when pin 3 IS constantly connected to pin 7 which is held low, so floating isn't the issue.

If I start the program with 3 and 7 shorted, it starts fine, if I disconnect and then reconnect then the issue starts.

I have also simplified the code more:
As you can see all you need to do is change pin 7 from high to low while the interrupt is disabled and it will still trigger the interrupt as soon as it is enabled. It is effectively acting as if detachInterrupt isn't actually doing anything. Or more consisely, it stops the interrupt triggering, but still tracks the state changes so that when the interrupt is reenabled, it will instantly act on those changes that happened while it was detached.

volatile bool resetdetect = false;
void setup() {
  Serial.begin(250000);
  pinMode(7, OUTPUT);
}
void loop() {
  Serial.println("Start Loop");
  Serial.println("Run Test");
  digitalWrite(7, LOW);
  Serial.println("Interrupt setup");

  digitalWrite(7, HIGH);
  pinMode(3, INPUT);
  attachInterrupt(digitalPinToInterrupt(3), reset, CHANGE);
  Serial.println();
  Serial.println();
  Serial.println();
  while (resetdetect == false) {             //holds program here until interrupted
  }
  resetdetect = false;
}
void reset() {
  resetdetect = true;
  detachInterrupt(digitalPinToInterrupt(3));
}

Things like a pull down is pretty important info.

But why would you connect an output to an interrupt?

And the output is that it runs over and over?

Might be that the interrupt flag isn't cleared before attaching/enabling the interrupt. Which board are we talking about?

septillion:
Things like a pull down is pretty important info.

But why would you connect an output to an interrupt?

And the output is that it runs over and over?

Might be that the interrupt flag isn't cleared before attaching/enabling the interrupt. Which board are we talking about?

This code is just a snippet of a much larger piece which is used to check for continuity and shorts of a cable. I want the code to be able to detect if the cable has been manually removed and restart the testing from the start. Both ends of the cable are attached to the arduino so there are output pins at one end and inputs at the other.

I have a feeling that detaching the interrupt only stops the ISR from running, but the flag can still be set in the background which is why it interrupts as soon as it's reattached. I guess what I need is a way to reset this flag or otherwise stopping this flag from being set. Mega 2560

Spagoose:
This code is just a snippet of a much larger piece which is used to check for continuity and shorts of a cable. I want the code to be able to detect if the cable has been manually removed and restart the testing from the start. Both ends of the cable are attached to the arduino so there are output pins at one end and inputs at the other.

Doesn't sound like a fast changing event aka an interrupt is the wrong tool for that task :wink:

An interrupt is meant to temporary interrupt your normal program and continue afterwards. Not to interrupt and force the normal program to do something else.

Spagoose:
I have a feeling that detaching the interrupt only stops the ISR from running, but the flag can still be set in the background which is why it interrupts as soon as it's reattached. I guess what I need is a way to reset this flag or otherwise stopping this flag from being set. Mega 2560

Yeah, seems like attachInterrupt() does not clear any interrupt flags. So yeah, if it's still set the function will be called right away.
But again, interrupts are the wrong tool to detecting a wire break.