How exactly does hysteresis GPIO function filter an input?

[lpcware]

Content originally posted in LPCWare by jdupre on Sat Nov 07 14:05:04 MST 2015
The LPC15xx has a hysteresis mode for GPIO.  How exactly does it filter the input and what would be the reason to use this mode or not?

How is hysteresis different from using the glitch filter(s)?

- Joe

[lpcware]

Content originally posted in LPCWare by IanB on Wed Jun 01 23:15:35 MST 2016
Yes - that would be wise otherwise you'll get customers saying "It keeps blowing fuses" - and I hope all that current is going into a capacitor somewhere, not through the LEDs!

[lpcware]

Content originally posted in LPCWare by jdupre on Wed Jun 01 16:27:29 MST 2016
I think what I am seeing is the result of huge inrush current of the LED loads I am driving.  I wasn't seeing any problems when I was developing the code with a small test fixture.  But once the board was installed in the actual enclosure and with the full load, I am measuring upwards of 150 amps in-rush current flowing through wires adjacent to my controller.  Soft-starting the loads in software has greatly reduced the problems.

I think I'll start a new topic in regards to minimizing effects of inrush and other noise...

[lpcware]

Content originally posted in LPCWare by IanB on Sun May 22 03:18:29 MST 2016
I have just come across a very similar problem:

I had a TPIC1021 LINbus receiver - the data on the Linbus was nice, no glitches, a bit slew-rate limited; but the UART was making a complete mess of reading it.
I connected it to a counter capture input instead and it still looked like nonsense. It wasn't jitter due to the slew-rate because that would give capture times in the sub 1µs and they were about 10µs (when they should be about 104µs for 9600 baud).

10µs? Thats 100kHz. I bet that's the frequency of the power supply.

I replaced the TPIC with two resistors (potential divider to get the 12V LIN signal down to 3.3V), and it worked! No spurious signals.

What appears to be happening is the TPIC is finding a little bit of psu noise and turning it into a valid signal too fast for my 20MHz scope to see. It might have shown up on an analogue scope: one of the areas where analogue has the edge (no pun intended) over digital.

SO perhaps your Schmidt trigger is turning psu noise into what looks like a valid signal to the cpu, and you'd be better off without it. The slow old phototransistor in the opto-coupler hasn't got the speed to amplify the noise, but the Schmidt trigger does!

[lpcware]

Content originally posted in LPCWare by jdupre on Wed Apr 27 09:12:06 MST 2016
No, I have just worked around the problem at this point.  (By increasing the time of the programmable glitch filter.)

I need to re-write my code to the bare minimum and feed the input with a known test signal to demonstrate the problem.  There must be some basic concept I'm missing.  I am clearly seeing a rising edge event occur occasionally when there is no rising edge.  

[lpcware]

Content originally posted in LPCWare by IanB on Sun Apr 24 09:35:10 MST 2016
Did you fix it?

[lpcware]

Content originally posted in LPCWare by IanB on Thu Apr 14 11:36:21 MST 2016
A bit of  code you may find useful:

                LDR R7,=LPC_SCT1_BASE                       @ set up SCT for capture
                MOVW R0,#0b1000000001                 @ INSYNC ON; 32-bit counter
                STR R0,[R7,CONFIG]                          @ 32-bit timer, prescaled bus clock
                MOVS R0,#3
                STR R0,[R7,REGMODE]                         @ capture on reg 0
                MOVW R0,#0x6800                             @ Event 0
                STR R0,[R7,EV0_CTRL]                        @ capture rising edge on input #0
                MOVS R0,#0x1
                STR R0,[R7,EV0_STATE]                       @ remain in state 0
                MOVW R0,#0x6400                             @ Event 1
                STR R0,[R7,EV1_CTRL]                        @ capture falling edge on input #0
                MOVS R0,#0x1
                STR R0,[R7,EV1_STATE]                       @ remain in state 0
                MOVS R0,#3
                STR R0,[R7,CAPCTRL0]
                MOVS R0,#3
                STR R0,[R7,EVEN]                            @ events 0 and 1 cause interrupt
                MOVS R0,#3
                STR R0,[R7,LIMIT]                           @ and reset counter
                MOVW R0,#0b10110000100
                STR R0,[R7,SCTCTRL]                         @ prescale by 45 = 1µs per count


                LDR R7,=ISER0
                MOVS R0,#1<<17+1<<21
                STR R0,[R7]

                LDR R7,=LPC_INMUX_BASE
                MOVS R0,#1
                STR R0,[R7,SCT1_INMUX0]                     @ input #0 is pin 32 (PIO0_16)

It sets up the counter to measure the time between edges of a signal, and interrupts on each edge.
The processor is running on a 11.2896MHz crystal, multiplied up to 45.1584MHz; so the 45 prescale means it output in microseconds (almost)

[lpcware]

Content originally posted in LPCWare by IanB on Wed Apr 13 07:41:48 MST 2016
That overshoot is nothing to worry about  - it may not even be real and be a result of where your ground clip is connected.
It's also a nice, tidy square pulse, so neither hysteresis or glitch filtering will make any difference.

Much more interesting would be the output from the opto (the input to your hysteresis).

What type is your opto? Some of them are REALLY slow, and they are slower still if they are allowed to go into saturation or you are using a large value pull-up resistor.

The opto only switches off if the mains waveform is between +1V and -1V, it is on the rest of the time. (1V is the forward voltage drop of the LED)
If the mains peak is 169V then it reaches 1V at 15µs after zero crossing (8.3ms/π * sin^-1(1/169)), so you really only have 30µs during which your output is definitely OFF. If the mains is distorted around zero crossing and the slope is greater than it should be then the pulse could be so short it ceases to exist.

The pulse is only longer than the theoretical 30µs due to the fact that β of the phototransistor isn't large enough to get enough current through the pull-up resistor to switch the 74HC14 low. β isn't a parameter to rely upon, it varies with temperature, collector current, phase of the moon - any excuse to be a different value from what you were expecting.

Also the opto is much slower to switch-off than switch-on, and slow switch-off would shorten your pulse, not lengthen it.

So my suggestion for the zener diodes would ensure that there is ±16V when the opto is definitely OFF equating to 250µs, making sure you always get a good pulse.

[lpcware]

Content originally posted in LPCWare by jdupre on Tue Apr 12 16:35:01 MST 2016
I should note that the input signal is a normally high 5V.  The scope images were offset to show detail.
Input pin is p0.2 on LPC1517.

This is a low volume product of which 150 exist at this point.  Although I definitely want to find a solution to the problem (via software or hardware change), I first want to understand what is happening.

[lpcware]

Content originally posted in LPCWare by jdupre on Tue Apr 12 16:20:31 MST 2016
I'm starting from scratch with my SCT code in an effort to understand what is going on.

event 0:
happens in state 1 only
falling edge condition on input 0
captures to register 0
limits the counter

Initialization routine sets state 1 and un-halts the timer.

The ISR logs the current time (from a separate microsecond timer) and the capture register to an array.
When the array is full, everything stops and prints out the results.

What I see is that when I do not have my glitch filter enabled, the the ISR is fired at both the fall and rise of my input signal.
When I enable the glitch filter, then the ISR only fires on the fall event.  But both of you are telling me that the glitch filter shouldn't matter.
(The input pin is configured in digital mode, pull-up enabled, hysteresis on, and the 10ns glitch filter in it's default on setting.)

I have attached 'scope screenshots of the input pulse.  There is large overshoot on the fall, but not so much on the rise.

So, why is the rise of the input causing the fall event to occur???

[lpcware]

Content originally posted in LPCWare by IanB on Tue Apr 12 12:21:52 MST 2016
A couple of zener diodes will cost you threepence. You'll have to be making an awful lot of them before the labour cost of writing a routine to identify and ignore invalid data becomes the more cost effective solution! (and if you are making an awful lot, then the zeners will be less than a penny)

[lpcware]

Content originally posted in LPCWare by starblue on Tue Apr 12 11:43:32 MST 2016

---

Quote: jdupre
This input signal is coming from AC power routed through an opto-coupler and a schmitt inverter to clean it up.
(That is, it's an AC input zero-cross detection circuit.)

---

Schmitt-trigger inverters already have hysteresis (that's the meaning of Schmitt-trigger). So hysteresis on the input pin won't help.

---

Quote: jdupre
The input pin has custom glitch filter enabled. (72Mhz/8 x 2clk = 222ns)

---

AC power is slow as molasses compared to that, so I would be surprised if it helps.

The right thing is probably some software solution, for example discarding the bad data.

[lpcware]

Content originally posted in LPCWare by IanB on Tue Apr 12 02:05:54 MST 2016
I've used that circuit many times (usually to sync phase-fired triac dimmers with the mains zero crossing) but, of course, the resistor dissipates twice as much power on a 230V supply so it now falls foul of energy efficiency regulations. The output pulse does tend to depend a lot on the gain of the opto (which is not the same for both + and - going signals) and on the distortion of the mains waveform. I suspect your problem may be the distorted waveform caused when something very inductive just dumped a lot of energy back into the mains.

I've never used the glitch filter - hysteresis always takes care of it, and I've never needed to add a Schmitt trigger. If there's anything nasty going on, you'll see it on the output of the Schmitt trigger using a 'scope; but if it only happens once in 500 cycles you might be a long time finding it.

A couple of things to try:
1) Two back-to-back zeners in series with the opto (say 15V) - that should increase the noise immunity around zero crossing by about 20dB (no good if you need to sync to zero crossing)
2) Use an ordinary opto (PC817 type instead of PC814) and look for both edges. (Don't forget the 1N4148 in inverse parallel with the opto's LED)

Is your power supply a "conventional" transformer? If so get the signal from the secondary. If it is a split bobbin transformer the high leakage inductance and low inter-winding capacitance stops the interference.

[lpcware]

Content originally posted in LPCWare by jdupre on Mon Apr 11 16:45:22 MST 2016
The INSYNC bit is set by default.  SCT clock is system clock running at 72MHz.

Input signal is a falling pulse, about 450us wide that occurs 120 times a second.
This input signal is coming from AC power routed through an opto-coupler and a schmitt inverter to clean it up.
(That is, it's an AC input zero-cross detection circuit.)
The input pin has custom glitch filter enabled. (72Mhz/8 x 2clk = 222ns)

What I'm trying to do is relatively simple:
Fall of the input signal resets the timer, and captures to reg0 to measure frequency of the pulse.
Rise of the input captures to reg1 to measure the pulse width.
Both events trigger an interrupt to deal with the captured data.

The problem I'm dealing with is that sometimes in some locations the pulse width being captured is measured way too short (< 1us when it should be  between 400 and 500).  When this happens the following capture of the fall event is also way off (7800us when it should be around8333 us).  It is as if the clock is getting reset when the rise event happens.   This error is not occurring constantly, only once every 300 to 500 cycles or so.  And it only happen in some locations, so I assume that has to do with noise on the AC line input which may be getting through to the digital side.  

[lpcware]

Content originally posted in LPCWare by IanB on Mon Apr 11 12:04:55 MST 2016
Overshoot shouldn't register as a transition, unless there is a *lot* of ringing. It's signals that rise and fall slowly, and hover about in the middle that cause multiple transitions.

Do you have a picture of your signal from your oscilloscope? Where does the signal come from?

Are you using it to trigger a capture event on an SCT? IF so, set the INSYNC bit. I couldn't get it to work without it despite what it says in the manual!

[lpcware]

Content originally posted in LPCWare by jdupre on Mon Apr 11 10:50:04 MST 2016
Hmmm...  I am seeing extra triggering of fall/rise events which I thought was related to overshoot on my input signal.  If what you say is true, overshoot on a falling or rising edge should not register as a transition.

I suppose I need to do some more testing...

[lpcware]

Content originally posted in LPCWare by IanB on Sun Apr 10 00:07:36 MST 2016
The values on page 56 are minima and maxima - so if your input voltage is >70% of Vdd then it is guaranteed to be a ONE and if it is <30% it is guaranteed to be a ZERO. Anywhere between it could be read as either. The transition between ONE and ZERO takes only a very small voltage (a few mV) but that could occur at a point anywhere between 30% and 70% of Vdd, and the transition is at the same voltage regardless of whether the voltage is rising or falling.  Generally it doesn't differ much from 50% Vdd. The transition voltage will be the same on all pins of a device and doesn't vary over time.

With hysteresis enabled, all that you can really tell from these specs is that the high-to-low transition voltage will be 350mV LOWER than the low-to-high transition voltage, but the absolute voltage at which it occurs can be anywhere between 30% and 70% of Vdd (but it's generally about in the middle).

Your circuit should ensure that any signal that needs to be read as a ONE exceeds 70% of Vdd and any signal that needs to be read as a zero is below 30% of Vdd.

If you don't stick to the specs, then your prototype will work, most of your production batches will work, but then one day you will be scratching you head when you build a whole batch that doesn't!

[lpcware]

Content originally posted in LPCWare by jdupre on Sat Apr 09 22:58:12 MST 2016
I don't understand how the "hysteresis voltage" listed in the data sheet affects the High/Low transition points.

On page 56 of the datasheet for the 15xx, I see HIGH-level input = 0.7VDD minimum  and LOW-level input voltage is 0.3VDD maximum.  So yeah, there isn't much difference between what is considered high and low.   The "hysteresis voltage" is documented as 0.35V minimum when 3.0V <= VDD <= 3.6V.

So when hysteresis is enabled, what should the voltage have to be for transition from high to low and what should it be for transition from low to high?

Also, should the hysteresis option affect the trigger points for falling and rising edge conditions on an input in the same way as high/low transitions?  (i.e. the SCTimer peripheral's inputs can trigger on high/low conditions or falling/rising edge conditions.)

[lpcware]

Content originally posted in LPCWare by IanB on Tue Feb 09 15:44:28 MST 2016
Don't overestimate how "fast" your input signal is! With a clock speed of 72MHz most real-world signals are "slow".
Even if the input signal is clean, you will get random high-low switching near the threshold if there is noise on the power supply, especially if the power supply comes from some form of switched-mode. Hysteresis is a really good idea.

[lpcware]

Content originally posted in LPCWare by starblue on Mon Nov 09 06:04:50 MST 2015
Hysteresis uses voltage, the transition from low to high logic state happens at a higher voltage than from high to low. So if you are near the threshold and have some small amount of noise it won't switch back and forth randomly between high and low.  This is important if you have slow edges, which stay a long time near the threshold.

For the value of the hysteresis see the data sheet.

The glitch filter uses time, it discards pulses which are shorter than a certain time, 10ns for the LPC15xx (see the user manual).