Do Interrupt pins float ?

Projects Programming
1

Mega 2560 and Ethernet Shield

I have the following in my sketch and a few days ago I started experiencing problems.

Hallway beams are connected to pins 19 and 20 ( interrupts 4 and 3 respectively ).

Interrupt 4 suddenly stopped working ( as it should operate ) after 2 days of erratic triggering.

I have disconnected the inputs from the hall beam relays to the pins and checked the voltage between ground and the pins :
pin 19 = 0v
pin 20 = 0.11v

The voltage coming from the beam relay contacts is 0.04v on each line

attachInterrupt(3, HallBeam1, FALLING); //pin 20 upper beam
attachInterrupt(4, HallBeam2, FALLING); //pin 19 lower beam

With the beam pins disconnected, if I connect my voltmeter between ground and pin 20, it triggers the interrupt. Does this mean that my voltmeter is dropping the voltage on pin 20 and triggering the interrupt ? Measuring the voltage has no effect on pin 19 and does not trigger the interrupt.

Under normal conditions, the voltage from the beam relay is 0v, and if triggered should rise to 4.8v and then drop back down, triggering the interrupt.

Is the pin 20 = 0.11v causing the problem ?

If I change the interrupts to 'RISING' would this not cause a similar problem if pin 20 floats down to 0v and then back up to 0.11v ?

2

Have you initalized both pins as inputs, with internal pullups enabled?

3

No. I assumed that using them as interrupts I would not need to.

I (think) I would need to add :

pinMode(19, INPUT);      
digitalWrite(19, HIGH);  
pinMode(20, INPUT);      
digitalWrite(20, HIGH);

the existing wiring on the beam relay is :
Com. 4.7v
N/O to the interrupt pin.

should that be modified to :
Com. Gnd
N/O to the interrupt pin
N/C to 4.7v ( is this part required if the internal pull up is used ? edit : removed : realised the stupidity of this

4

DaveO:
Mega 2560 and Ethernet Shield

I have the following in my sketch and a few days ago I started experiencing problems.

Hallway beams are connected to pins 19 and 20 ( interrupts 4 and 3 respectively ).

Interrupt 4 suddenly stopped working ( as it should operate ) after 2 days of erratic triggering.

I have disconnected the inputs from the hall beam relays to the pins and checked the voltage between ground and the pins :
pin 19 = 0v
pin 20 = 0.11v

The voltage coming from the beam relay contacts is 0.04v on each line

attachInterrupt(3, HallBeam1, FALLING); //pin 20 upper beam

attachInterrupt(4, HallBeam2, FALLING); //pin 19 lower beam




With the beam pins disconnected, if I connect my voltmeter between ground and pin 20, it triggers the interrupt. Does this mean that my voltmeter is dropping the voltage on pin 20 and triggering the interrupt ? Measuring the voltage has no effect on pin 19 and does not trigger the interrupt.

Under normal conditions, the voltage from the beam relay is 0v, and if triggered should rise to 4.8v and then drop back down, triggering the interrupt.

Is the pin 20 = 0.11v causing the problem ? 

If I change the interrupts to 'RISING' would this not cause a similar problem if pin 20 floats down to 0v and then back up to 0.11v ?

Need to see more about the 'beam' output circuit. You mentioned it being a relay? If so and you are just using the 'dry contacts' of a relay as input to the arduino input pin you need to properly wire it such that you don't have a 'floating input pin condition' in either beam broken or not broken states. The easiest was is to enable the internal pull-up resistor for the input pins you will be using and then wire one relay contact to that inoput pin and the other relay contact to a arduino ground pin. What you are seeing looks very much like a floating input pin situation which can intermittently cause false or missing interrupts. If your 'beam' doesn't use relay contact outputs then try and find a datasheet or schematic of it so we can clearly see what kind of electrical output arrangement it is using.

Lefty

5

retrolefty:
Need to see more about the 'beam' output circuit. You mentioned it being a relay? If so and you are just using the 'dry contacts' of a relay as input to the arduino input pin you need to properly wire it such that you don't have a 'floating input pin condition' in either beam broken or not broken states. The easiest was is to enable the internal pull-up resistor for the input pins you will be using and then wire one relay contact to that input pin and the other relay contact to a arduino ground pin. What you are seeing looks very much like a floating input pin situation which can intermittently cause false or missing interrupts.

Hi Lefty

Yes, the beam output is a dry contact relay, so I can hook up anything through there.

I will connect Gnd to beam relay Com and beam relay N/O to interrupt input pin.

In the code will set the interrupt input pins as inputs and set to High to pull-up.

I think my error was to assume that the input didn't need to be set for the interrupt pins.

Thanks to everyone for the guidance.

6

DaveO:

retrolefty:
Need to see more about the 'beam' output circuit. You mentioned it being a relay? If so and you are just using the 'dry contacts' of a relay as input to the arduino input pin you need to properly wire it such that you don't have a 'floating input pin condition' in either beam broken or not broken states. The easiest was is to enable the internal pull-up resistor for the input pins you will be using and then wire one relay contact to that input pin and the other relay contact to a arduino ground pin. What you are seeing looks very much like a floating input pin situation which can intermittently cause false or missing interrupts.

Hi Lefty

Yes, the beam output is a dry contact relay, so I can hook up anything through there.

I will connect Gnd to beam relay Com and beam relay N/O to interrupt input pin.

In the code will set the interrupt input pins as inputs and set to High to pull-up.

I think my error was to assume that the input didn't need to be set for the interrupt pins.

Thanks to everyone for the guidance.

No error in your thinking. All arduino I/O pins default to input mode upon power-up or reset. So mode statement to set them to input in not normally required. However to enable the internal pull-up resistor for any input pin (no matter if an interrupt pin or not) does require the pin to be setup properly. If you were interfacing the interrupt pin to a electrical active TTL voltage signal (0 and +5vdc active states with a common ground connection to the arduino) then you would not need a pull-up resistor enabled, but for simple mechanical contacts (relay contacts or switch contacts) you do need to do so. That make sense?

Lefty

7

So I learn from experience that my idea would not work ( hope I remember this next time ).

I set input pins 19 and 20 to high, and wired up :
Com. Gnd
N/O to the interrupt pin

However, when I triggered the beam, the board just kept resetting. I think it didn't like the common Gnd meeting up with the pins High when the beam relay triggered and I assume it drained the power so much that the board 'shut down', and immediately re-booted, and repeated the cycle.

So, plan B is to use an optocoupler ( I have a few spare on my project board ) and pass the resulting ground from that, to the input pin.

BUT ... before I connected anything up, I added code :

pinMode(19, INPUT);      
digitalWrite(19, HIGH);  
pinMode(20, INPUT);      
digitalWrite(20, HIGH);  

attachInterrupt(3, HallBeam1, FALLING);
attachInterrupt(4, HallBeam2, FALLING);

and pin 19 measures 5.02v, but pin 20 only measures 0.13v

I can't understand why pin 20 wouldn't be High.

Does the fact that these pins in the board are marked RX1 and SDA make any difference ?
Could my Ethernet Board or One Wire temperature sensors be affecting this pin somehow ?
Or something to do with my PC being connected to the USB port ?

I did go ahead and connect the beam relays to Com Gnd and N/O to the optocoupler, and the 'output' of the optocoupler to the input pins 19 and 20.

As expected, only the beam relay to pin 19 worked ( as it was set high on startup, and when triggered went to Gnd ) - pin 20 was never high to start with, so it didn't register the interrupt 'falling' to Gnd.

8

BUT ... before I connected anything up, I added code :

Code:
pinMode(19, INPUT);
digitalWrite(19, HIGH);
pinMode(20, INPUT);
digitalWrite(20, HIGH);

attachInterrupt(3, HallBeam1, FALLING);
attachInterrupt(4, HallBeam2, FALLING);

and pin 19 measures 5.02v, but pin 20 only measures 0.13v

Measure the pin 20 voltage with out any wire connected to it removed from pin 20. If it still then measures .13v then you have a bad pin, if not you have bad wiring to the switch contact or the contact is closed to ground.

I can't understand why pin 20 wouldn't be High.

Do the check above, then report back.

Does the fact that these pins in the board are marked RX1 and SDA make any difference ?

Not unless you are using serial1 commands or I2C commands in your sketch, otherwise the pins are free to use.

Could my Ethernet Board or One Wire temperature sensors be affecting this pin somehow ?

Not sure about the Ethernet Board, you need to see if it uses pins 19 or 20. If it does then you have a conflicting use for the same pin and your design will have to change to a different pin number.

Or something to do with my PC being connected to the USB port ?

No.

I did go ahead and connect the beam relays to Com Gnd and N/O to the optocoupler, and the 'output' of the optocoupler to the input pins 19 and 20.

As expected, only the beam relay to pin 19 worked ( as it was set high on startup, and when triggered went to Gnd ) - pin 20 was never high to start with, so it didn't register the interrupt 'falling' to Gnd.
Again make the electrical check described above and get back to us. With the internal pull-up enabled for pin 20 it should measure +5vdc with nothing wired to it (or another attached shield using that same pin number).
Lefty

9

Hi Lefty

I do have :

#include <OneWire.h>

and I see on :

that it looks like it uses pins 20 and 21.

So I guess I have conflicting use of pin 20 - Lesson for me : just cos there is no wire attached, and the pin is open, doesn't mean I can use it.

I also have an LCD attached with :

LiquidCrystal lcd(18, 17, 16, 5, 6, 7);

so is there any reason I can't change that pin 18 to any other open pin, and then use pin 18 / interrupt 5 for the beam relay input ?

10

so is there any reason I can't change that pin 18 to any other open pin, and then use pin 18 / interrupt 5 for the beam relay input ?

Sounds like a reasonable plan to me.

Lefty

11

Does this mean that my voltmeter is dropping the voltage on pin 20 and triggering the interrupt ?

Your volt meter actually presents a voltage on its probes. That voltage triggered the interrupt.

In general, you want to have a resistor on any pin that interacts with the rest of the world, to just protect it against potential damages.

12

I have moved my LCD pins along one place and changed :

from
LiquidCrystal lcd(18, 17, 16, 5, 6, 7);
to
LiquidCrystal lcd(17, 16, 15, 5, 6, 7);

Moved the LCDs physical wires to the input pins ( 15 - 17 ) and the LCD still working perfectly.

Then I added code to :

pinMode(18, INPUT);      
digitalWrite(18, HIGH);  
pinMode(19, INPUT);      
digitalWrite(19, HIGH);

Upload and reboot :

Pin 18 = 0.08v
pin 19 = 5.01v

Pin 18 is doing the same as I was having previously on pin 20. There is nothing connected to pins 18,19,20 so no 'outside influence' there.

Suspecting a similar problem that prevents the use of pin 20 and 21 if I am using OneWire, next I moved to a basic sketch (no other libraries) and added :

void setup(){
	pinMode(18, INPUT);      
	digitalWrite(18, HIGH);  
	pinMode(19, INPUT);      
	digitalWrite(19, HIGH);  
}

void loop(){
	//do nothing
}

As simple as it gets, and pins still read :

Pin 18 = 0.08v
pin 19 = 5.01v

Now I am baffled. There is no other code present, but pin 18 still won't show 5v. Could the ethernet shield be affecting the pin 18 (tx1) ?

I could remove the ethernet shield, but not easy to get to, so would prefer if I (we) could figure it out.

13

Update :

After not having any success trying pins 18 and 20 for interrupts 5 & 3, I moved the wiring from the second beam to pin 2 ( interrupt 0 ).

Beam 1 is still on pin 19.

Everything working perfectly.

I can only guess that either the ethernet card is using pin 20, or one of the libraries ( like OneWire ) is using pin 18 and stopping it working as an interrupt.

Maybe in the design of the Mega 2560, the extra interrupts would have been better positioned as a normal ( ie. not communication type ) pins allowing usage irrelevant of any comms requirements of libraries / shields. Just a thought. It's still an absolutely awesome board and I really enjoy playing with it.