T4.1 - phantom digital interrupts firing. (Scope video incl)

Talkiet

Well-known member
I have 2 digital inputs configured on a T4.1. Each has a 10k external pullup. I have been finding in my full build and code that I am getting occasional instances where when only one input is closed, both routines fire. I built up a bare PCB with only the T4.1 and the inputs/pullups and had the same issue, so then tried a third T4.1 connected to the most basic pullup circuit on a breadboard and had a look at what was happening with a scope.


I don't know a lot about electronics, but if I just tap the digital input pin with a pair of tweezers, I see BOTH inputs momentarily (much less than a microsecond) drop low enough to be considered a state change. The code IS running on the board but as you can see, it shouldn't change the behaviour here.. Admittedly they are adjacent pins, but is this expected behaviour?

pinMode(22, INPUT); // sets the digital pin as input for START beam
pinMode(23, INPUT); // sets the digital pin as input for FINISH beam
..
attachInterrupt(22, isrStartBeam, FALLING); // interrupt on light beam input
attachInterrupt(23, isrFinBeam, FALLING); // interrupt on light beam input

Is there anything I can do in the code to dampen the sensitivity of the digital inputs? Will adding a small cap across each input help/fix? Most importantly though - is this expected behaviour or am I doing something wrong?

When I look at the output from the code, I can see both interrupt routines running when I tap the signal line on either one. It's NOT all the time, and me+tweezers or, me using an unplugged multimeter lead to tap the pin both trigger the issue about 75% of the time...

What am I missing?

Cheers - Neil G

I have tried 4.7k and 2k resistors instead, and I have tried with the internal pullups enabled as well. It occurs to me I have NOT tried with ONLY the internal pullups... but something feels odd here.
 
Last edited:
Try using a stiffer pullup like 2k2. Capacitance between adjacent pins couples them at nanosecond timescales. The T4 is a
very high speed chip so its very sensitive to tiny spikes on its inputs that last a few ns.

Consider the effect of a tiny 1pF of coupling between pins at various timescales:

30ns its about 30k ohm equivalent
10ns its about 10k equivalent
3ns its about 3k equivalent - stronger than your 10k pull up resistor.

and if the capacitance is larger than that due to wiring runs the effect can be even stronger.

I suspect there are ways to program the chip's GPIO to be less sensitive to noise (this is common in microcontrollers,
there'll be some circuitry to ignore pulses that last a single clock cycle, or small number of cycles, precisely
to deal with real-world signals.

And another thing to be aware of is that if the tweezers are metal you could be discharging a static charge
through them when you touch the circuit, possibly up in the 50 to 100V region due to you body picking up
mains potential through nearby wiring. This sends a brief current pulse through the protection diode on the pin
involved but this high current may couple _inductively_ to nearby wires, again creating pickup on neighbouring
signals.

Its not a good idea to touch CMOS circuits like this, even though they are designed with anti-static protection,
unless you are grounded.
 
Thanks Mark - I am aware that just touching the pins with an ungrounded source isn't the best idea but I get this behaviour (far less often but still often enough to break my use case) when I have a button connected to each input. This was just to demonstrate the issue in a reproducible manner.

I don't know the maths or electronics background to fully understand your explanation, but I get the principle. I have done some searching to see if there was a way to reduce the sensitivity of the T4 digital inputs but have come up with nothing so far.

The next thing I will likely try is a small cap across the input - is that likely to work? I understand it will affect the behaviour of the state change but I'm only really concerned about the response speed at the 10s of microseconds level - I don't really care if it's a few microseconds slower to fire.

Failing that, any other suggestions for how to clean the signals up externally?

(oh, I have replicated the behaviour with 2k, 4.7k and 10k resistors - I couldn't see any real change in behaviour but that may be due to the test to test variability of the static conditions)

Cheers - Neil G
 
There is something that doesn't quite add up with this experiment. Just touching the pin with a probe shouldn't cause a low going signal. Your power wiring looks a little suspect, the connector on the proto board looks crooked for some reason. The signals look like the scope is not grounded, yet I clearly see the scope ground connected. So ???
 
This is the 3rd test config that displays the issue.

1) Fully populated PCB with quite a few other components
2) PCB with only the T4.1 and input connectors/pullup resistors populated
3) The bare board / breadboard as seen in the video.

All give the same behaviour so this particular test setup / wiring is not to blame (unless it's the scope wiring)

However, the scope is only showing me what I had previously observed through watching the program behaviour. I had the two interrupt functions do nothing but a tiny serial print when they were triggered (plus look at a micros timestamp to limit their execution to once a second or so). I observed both routines execute essentially at the same time when only one pin was touched. The scope is displaying the behaviour that the program experienced with no scope attached.

The scope is grounded.

It's really doing my head in - unfortunately I don't have any caps here and I live rurally, so short of butchering all the old electronic devices I have looking for a through hole cap, I can't place caps on the inputs for a couple days :-( Would be good though if anyone could confirm whether what I am proposing (100nf cap across input and ground) is a good approach.

Cheers - N
 
The signals on the scope show undershoot, ( they go below zero volts ) and the rising edge looks like there is capacitance. Perhaps your scope probes are not compensated. There are a couple of connections on the right hand side of the scope where you hook up the probe and ground. You will see what should be a square wave on the scope. You use a very small screwdriver in the scope part up by the BNC connectors and adjust until you see a good looking square wave.

My best theory of the cross talk between signals is still something with the power wiring or ground. For example, if your red wire had a resistance of say 2000 ohms instead of 1 ohm, you would see what you now see.
 
BTW have you tried using an actual switch to ground the pins - I strongly suggest touching any CMOS signal with a metal probe
is a bad thing to do and not at all representative of actual operation in a normal circuit. You could try adding 100 ohms in
series with each signal to limit at current spikes, that might ameliorate the effect of zapping the signals like that.

Your two wires for the signal are commoned on a ribbon cable of a few inches, that's probably 5--10pF of coupling right there,
and quite a lot of mutual inductance for the current spikes to use.
Normally with high speed signals every other wire of a ribbon is ground or power specifically to reduce crosstalk.
 
As a valid test, you could wire say pin 5 over to one of the resistors on the breadboard and then write a signal pulse in loop like

Code:
delay(100);
  digitalWrite( 5, LOW );
  digitalWrite( 5, HIGH );
and see how that loop looks on the scope and if you see cross talk.
 
Thanks for those suggestions. I do like the idea of a clean test using a digital output to verify behaviour. I'll have a crack at that this evening.

And Mark, yes, I have seen this behaviour with switches connected as well. It's nowhere near as frequent, but it is there. I'll see if I can get some example traces of that as well.

Cheers - N
 
Coming back to this - I put a 100nf cap across the input and this has tamed the behaviour sufficiently. It looks ok on the scope now and I am not seeing any phantom triggers in the normal program execution.
Cheers - N
 
Back
Top