Pin change interrupt is unreliable with certain input signals

Go To Last Post
31 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I apologize upfront if this is going to be a lengthy post.

I started on a project where I wanted my ATtiny45 to wake from deep sleep, so I played with the pin change interrupt. I sampled a switch connected to PB0 and triggered a PCI on each pin change.

My impression was that sometimes switch presses were missed. I spent a lot of time on this and now think there is some 'issue' with the change detection logic.

I stripped down the software to the bare minimum which still reproduces the effect. Here it is, it's only 13 instructions long (it's a disassembly with a few comments):

 

       0:       rjmp    main		; reset vector, start main()
       2:       rjmp    main		; vec_1, not used
vec2:  4:       sbi     0x16, 1		; vec_2, pin change ISR; toggle PB1...
       6:       reti				; ...and that's it
main:  8:       ldi     r24, 0x1E	; DDRB    = 1 << PB4 | 1 << PB3 | 1 << PB2 | 1 << PB1;
       a:       out     0x17, r24
       c:       sbi     0x18, 0		; activate pullup on PB0
       e:       ldi     r24, 0x20	; GIMSK   = 1 << PCIE;
      10:       out     0x3b, r24
      12:       ldi     r24, 0x01	; PCMSK   = 1 << PCINT0;
      14:       out     0x15, r24
      16:       sei			; enable interrupts
.L4:  18:       rjmp    .L4		; spin

 

So, it just sets up the pins plus the PCI and then spins. The ISR will toggle PB1, then return. I expect to see one (or several, if the switch bounces) toggles on PB1 for each press and release.

I'm watching the pins with a fast scope.

 

Oh, and I should note that the low fuse is set to 0x24, so CLK is output at pin 3, and the chip is running at 128/8 = 16kHz.

 

Also with this minimum program I could see switch presses/releases being lost; i.e. I could see the switch transitioning from LO to HI, with a bouncing transition period, but NO PCI ISR triggered.

Note that I could clearly see if the ISR was triggered twice. I'd say that with my setup I had a single ISR call in about 70% of cases, two ISR calls in 20%, and ZERO ISR calls in 10% of switch presses/releases.

 

I also noted that, for my switch, the time between bouncing peaks was irregular but in the range of about 100usecs, which is quite close to the chip's cycle time at 16kHz.

 

After a while all this switch pressing got annoying, so I hooked up my scope's signal generator and tried to simulate the switch. I found a pattern that reliably causes the PCI change detection logic to fail.

It is quite simple: say, the input is LOW. Then, go HIGH for half a clock period; LOW for half a clock period; then HIGH and remain HIGH.

If this signal is applied to a pin and the initial rising edge happens while the clock signal is HIGH, the whole pin change is lost; PCIF won't be set, and the ISR won't be triggered.

 

This is consistent with the circuit given in 9.2.2, "Pin change interrupt timing", of the ATtinyx5 datasheet. I'm not an expert here, but I tried to apply my synthetic signal to this circuit, as shown in the attached timing diagram, and would expect the pin change to be lost.

As I understand it,

- the initial latch is transparent while CLK is HIGH, and keeps the state it had on the falling edge of CLK while CLK is low

- the signal that finally ends up in PCIF is generated from the XOR of the input and pin_sync, which is a delayed version of pin_lat

- with the given timing, this XOR is always low on rising edge of CLK, so PCIF is never set.

 

Looking forward to all comments. However, please note that this post is not about debouncing, so an answer like 'use a timer interrupt and poll your switch, that's better' won't really help. This is about the pin change interrupt :)

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You say it's not about bouncing but what happens if you activate the interrupt by a signal generated from the io of another micro so it's  guaranteed "clean".

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

>> what happens if you activate the interrupt by a signal generated from the io of another micro so it's  guaranteed "clean".

 

I did not try that; however, as I wrote, I'm generating the signal with a signal generator. This input signal looks certainly 'clean', also when viewed with an analog channel on the scope.

You can see the input in the attached screenshot, labelled "PIN0" (which should be better labelled "PB0")

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

and the chip is running at 128/8 = 16kHz.

 

What is 128?  why are you running at 16KHz?

 

First, do your results make sense when you run at 8 MHz??  Then start lowering your clock until it doesn't make sense---you will be able to better determine the timing issue.

 

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

First, thanks for your reply!

 

and the chip is running at 128/8 = 16kHz

Sorry, that was a bit short. The low fuse was 0x24, so

- clock source is the internal 128kHz oscillator

- CKDIV8 is in effect

-> resulting in a clock of 128kHz / 8 = 16kHz.

I'm running at this frequency mostly because signals in the kHz range are so much cleaner and easier to show on  the scope than signals in the MHz range.

It also makes it a lot easier to check out clawson's idea (another controller, running in the MHz range, produces the input signal for the slow controller running in the kHz range).

I just tried your suggestion - switched the low fuse to 0xa2. Now the chip is running at full 8MHz.

I adapted the input signal accordingly, for 8Mhz == 125ns clock period (steady low - high for 60ns - low for 60ns - steady high) -> same problem: if the rising edge hits when CLK is high, the pin change is missed.

 

Now, no switch will bounce in the 60ns range. Just for fun I tried 400ns peaks, and the pin change is detected reliably.

 

But, as I said, this is not so much about properly sampling a bouncing switch, it's about the pin change interrupt not firing.

I just can't believe that such a simple input makes the "pin change detection' logic fail.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I adapted the input signal accordingly, for 8Mhz == 125ns clock period (steady low - high for 60ns - low for 60ns - steady high) -> same problem: if the rising edge hits when CLK is high, the pin change is missed.

OK, I think we are getting somewhere...it sounds like you are simply trying to use too narrow pulses...for the IRQ capture to work, there is some minimum (I don't have a datasheet handy)..maybe it is 2 clock cycles?    Now start increasing your pulse width until it works reliably,  that will tells us where the minimum is.   

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Sun. Jun 28, 2020 - 06:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


mzinner wrote:

As I understand it,

- the initial latch is transparent while CLK is HIGH, and keeps the state it had on the falling edge of CLK while CLK is low

- the signal that finally ends up in PCIF is generated from the XOR of the input and pin_sync, which is a delayed version of pin_lat

- with the given timing, this XOR is always low on rising edge of CLK, so PCIF is never set.

 

I think you've got a good grasp of what's going on. Probably a better idea than the original author of the data sheet who completely missed out any explanation of this.

BTW: Many other AVRs are identical in this regard, it's not only TINY..

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


The setup & hold timing of the very first block is important.   And unstated anywhere, I believe.  Let's assume it is 20ns for setup & 5 ns for hold

So the question is how soon can PCINT(0) end and still ensure pcint_syn (green) still gets generated, assuming PCINT(0) starts immediately after just barley missing a clock pulse? 

  

 

 

  

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mzinner wrote:

After a while all this switch pressing got annoying, so I hooked up my scope's signal generator and tried to simulate the switch. I found a pattern that reliably causes the PCI change detection logic to fail.

It is quite simple: say, the input is LOW. Then, go HIGH for half a clock period; LOW for half a clock period; then HIGH and remain HIGH.

If this signal is applied to a pin and the initial rising edge happens while the clock signal is HIGH, the whole pin change is lost; PCIF won't be set, and the ISR won't be triggered.

 

This is consistent with the circuit given in 9.2.2, "Pin change interrupt timing", of the ATtinyx5 datasheet.

Ouch, yes, you seem to have found a serious design flaw.

Normally such edge circuits use 2 FFs, but Atmel's designer assumed a latch could do (maybe he was trying to get faster response?) but you found that has a flaw, with fast-pin changes.

 

A workaround may to be use a RC filter, and use the Pin hysteresis, to ensure the pin cannot change at a SysCLK rate.

Maybe a parallel C is enough, combined with Pullup current, and Pin Hyst. A ballpark calc is 50u*(1/16k)/250m  = 12.5nF, so try 22nF ?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

the whole pin change is lost

Oh, that's vital..you are saying if the pulse is wide enough, but preceded by a runt pulse during the clock high time, the whole thing is trashed anyway.  veeeeerry interesting!  

 

They don't really encompass that here:

If edge or toggle interrupt is selected, pulses that last longer than one clock period will generate an interrupt. Shorter pulses are not guaranteed to generate an interrupt. For both types of sensing, if low level interrupt is selected, the low level must be held until the completion of the currently executing instruction to generate an interrupt.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Very curious what Microchip might have to say about this.  Someone want to ping je_ruud?

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:
you are saying if the pulse is wide enough, but preceded by a runt pulse during the clock high time, the whole thing is trashed anyway

 

Yes, exactly.

I tried to draw it once more so the issue is more prominent.

 

 

Good news (for me, at least): things look brighter when in power-down mode. Here, the clock is OFF, and obviously some other circuitry is taking over. Then, the chip will wake up (and the pin change interrupt will fire) on the first edge, no matter what the input signal looks like.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

From OP:

sometimes switch presses were missed

 

joeymorin:   [why  does the whole post get quoted and not the selected part?]

Very curious what Microchip might have to say about this.  Someone want to ping je_ruud?

I'll start with how one can do a button press in less than one clock cycle?  Even at 16kHz (that's the clock, right?) that is 62us, right?

 

Now, isn't it a Martha Stewart "good thing" to >>not<< fire an interrupt at every glitch?  Is all this really a philosophical discussion, or a real or perceived problem? 

 

OP has done a lot of work to track down the situation.  I wonder how it might apply to other AVR models of various generation, and to different brands/architectures.

 

Apologies -- a more careful re-reading shows the problem with the "lost" edge.

 

Perhaps the last sentence is still a good query?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Mon. Jun 29, 2020 - 04:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
Even at 16kHz (that's the clock, right?) that is 62us, right?
The original post was talking about a 16kHz clock when the issue was first noticed.

 

Edit: corrected while I was typing...

David (aka frog_jr)

Last Edited: Mon. Jun 29, 2020 - 04:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is a big difference between  not picking up on a narrow pulse (hey: you need to make wider pulses), vs a narrow  & missed pulse causing a valid ,wide pulse to not be sensed. 

 

Question (I haven't traipsed through the diagram)...what if the normal pulse is separated from the narrow pulse, instead, by several clock cycles?  I'm assuming/hoping this "lockout" is already reset, the normal pulse is detected,  & that the trouble only occurs when the two pulses are immediately adjacent.  

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:
I'm assuming/hoping this "lockout" is already reset, the normal pulse is detected,  & that the trouble only occurs when the two pulses are immediately adjacent. 

 

Yes, a standalone pulse of half the clock period is - somewhat ironically - detected very well; a standalone pulse plus a 'normal' edge, not immediately following each other, results in one (or even two, if they are far enough apart) ISR calls.

 

It's this timing that is critical (here, as an example, a LOW->HIGH transition, HIGH->LOW should be the same):

- input is steady LOW

- input is LOW at some rising edge of clk

- input is HIGH at the next falling edge of clk

- input is LOW at the next rising edge of clk

- input is HIGH at the next falling edge of clk

- input is steady HIGH from then on.

Lost pin change timing

 

I think it was just my bad luck that I played with a 16kHz clock and my bouncing switch fulfilled these conditions often enough for me to notice :)

 

I'd like to repeat that I know nothing about hardware, so my explanation might well be wrong, but the effect is certainly there.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This don't sound good.

 

Some one (I don't have a studio7 here) should simulate the code.

If the model really is made from the code that generate the chip, it should also fail.

 

I always have one fast timer ISR that pull what I need.

 

As I remember it's 10 or 11 clk to make a ISR that check if a IO have changed (if nothing have changed), else it's only 2-3 clk slower than normal. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mzinner wrote:

I think it was just my bad luck that I played with a 16kHz clock and my bouncing switch fulfilled these conditions often enough for me to notice :)

 

I'd like to repeat that I know nothing about hardware, so my explanation might well be wrong, but the effect is certainly there.

 

Did you try adding a ~22nF cap across the switch, as suggested above ?

That slows down the fast edges, so that the chip does not 'see' such rapid changes. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

Some one (I don't have a studio7 here) should simulate the code.

I don't believe it is possible to create a stim file accurate to a quarter-period of the clock.  Is it?

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If a runt pulse (glitch) can block a later valid IRQ pulse, that seem rather problematic.  You'd think many would have encountered that along the way & had some discussions.  At some point, Atmel started adding "glitch" filtering to some of the later AVR series...was this an issue they spotted?

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

avrcandies wrote:
At some point, Atmel started adding "glitch" filtering to some of the later AVR series...was this an issue they spotted?
Doubtful.  The pin change logic is responsible for this newly demonstrated behaviour, whereas the filters you're referring to (generally for ICP) take as their input the output of the synchroniser for an input buffer, separate from the pin change logic.  That synchroniser is properly implemented as two FF in series but >>without<< the XOR that seems to be implicated here.

 

 

avrcandies wrote:
You'd think many would have encountered that along the way & had some discussions.
The conditions seem to be quite specific.  The runt input pulse appears to need to be out of phase w.r.t. the system clock by something in the neighbourhood of 1/4 of a system clock period, and also appears to need to be less than about 1/2 of a sytem clock period.  The actual limits of the phase and pulse length are surely a bit wider, but it does seem as though the candidate runt pulse would be rare in most real world situations.  Then again, it's possible that this has actually been observed before, but has been incorrectly diagnosed and/or unknowingly mitigated by some means e.g. RC filtering of inputs by the hardware designer ("There!  That fixed it!  That must have been the problem then!").

 

 

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

First, I want to thank you all for your input so far!

Who-me wrote:
Did you try adding a ~22nF cap across the switch, as suggested above ?

Not yet, and I should explain why. I'm sure that is a good suggestion that would fix it. I could, just as well, use a normal 1 MHz or 8 MHz clock as everyone else, that would also 'fix' it in a way. Or sample the switch periodically instead of relying on PCI.

 

I'm doing this mostly out of curiosity. I'm coming from a windows/linux application software dev background. I'm new to the embedded world, and I'm fascinated to see and watch every single clock cycle doing something.

 

One of my first fun projects involves a little device with a switch where you can input kind of a 'password', like a morse code, that unlocks the device. While developing this I found that my switch presses were not always detected as expected. That made me dive into the problem, until I had a stable case that showed the problem we're discussing.

 

And I just could not believe that something as basic as 'read in a switch' is not done 100% reliably. I wouldn't like this to work only 'most of the time'.

 

joeymorin wrote:
The conditions seem to be quite specific.

 

I don't know. As I said, I had a 'failure rate' (i.e. a switch press or a switch release not causing an ISR call) of a few percent, may up to 10 percent. I'd consider this rather fragile.

 

Now, noone is probably running at such low clock speeds, so the combination 'switch bounces with about clock frequency' might be unrealistic.

On the other hand,

- when going to higher frequencies inputs start to overshoot and undershoot,

- a bouncing switch or a noisy line is a very uncontrolled input, so it might happen just occasionally?

 

In the end, I think if there really is such a problem an application note would be nice, like 'if you want stable pin change interrupts, avoid pin changes in the vicinity of the clock frequency'.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have not played with the tiny45 (actually 85 but don't matter) for years but here is some thoughts:

 

This is PCINT0 (but probably don't matter which) and OC0A is on the same pin, does this mean that PCINT0 can be triggered by a timer compare ?

If that is the case there could be a chance that the error can be made with the timer running 64MHz!

 

And if the simulator can run the faster PCK then perhaps.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

If that is the case there could be a chance that the error can be made with the timer running 64MHz!

Coupled with this data-sheet statement one could build a self-contained test-bed

 

Observe that, if enabled, the interrupts will trigger even if the INT0 and INT1 or PCINT23...0 pins are configured as outputs. This
feature provides a way of generating a software interrupt.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Thanks for your suggestions!

 

I don't know how to get this timer idea '64MHz' working, so I did what clawson suggested - use another tiny to generate the signal.

 

The setup is this:

- a 'master' ATTiny, running at 1MHz with the software below

- a 'slave' ATTiny, running at 16kHz with the software from my first post. This slave is providing its clock signal at CLKO (pin 3)

- the master PB0 is connected to the slave CLKO for synchronization

- the slave PB0 is connected to the master PB1 to get the input signal

 

The idea:

- the master generates a signal with about 16 edges per second (nicely visible with a LED)

- however, each edge is preceded (or followed - equivalent) by a short 30+30usec pulse

- the edge is synchronized with the slave clock: the master waits for a rising slave clock edge,

  then delays the signal by 0...100% of a slave clock width

- the slave's PB0 and PB1 have an LED attached.

 

Since each input edge should result in an output edge we'd expect both LEDs to flicker in sync. In reality,

the input LED flickers constantly, while the output LED flickers for a few seconds, then is constant for a few seconds,

then repeats.

About half of the input pin changes are lost.

 

Is there a contact with Microchip that might be interested in this?

 

-------------------------------

 

This is the edge at high time resolution; compare with slave clock of 16kHz:

 

 

Many edges at millisecond scale; edge is offset by 0...100% of slave clock cycle. About half of the input edges are not detected.

 

 

Here the master software, compiled with "avr-gcc.exe -nostartfiles -mmcu=${AVR_TYPE_GCC} -Wa,-L -Os -o obj.o tiny.c"

//
// software to demonstrate pin change detection failure
//
// Two ATtinys are used. This is the code for the 'master' chip.
// The master is running with a 1MHz clock,
// the slave is running with a 16kHz clock.
// The master will toggle PB1 about 16 times a second.
// Each such edge is preceded by a short pulse of about 30usec;
// that is just half the clock period of the slave chip.
// The pulses are synchronized with the slave clock: the master waits
// for the slave clock's rising edge, then delays by a varying amount of
// time before generating the test signal.
// This way, the effect of 'when exactly, during the slave clock's
// cycle, does the edge hit' is checked.

#include <../include/avr/io.h>

// with all overhead this amounts to about 30usec == 1/2 slave cycle
#define PULSE_LEN 9

// about 1/16s, 60msec
#define TIME_BETWEEN_EDGES 16000

#define PIN_SLAVE_CLOCK_IN	PB0
#define PIN_OUT			PB1

void inline busyWait1(unsigned char volatile c) 	{ while(--c); }
void inline busyWait2(unsigned short volatile s) 	{ while(--s); }

void main()
{
	DDRB = 1 << PIN_OUT;

	unsigned char edgePosition = 0;
	while(1)
	{
		// Edge shift from 0...63 master cycles; loop takes 3 cycles
		if(++edgePosition > 64/3)
			edgePosition = 1;

		// Wait for rising edge of slave clock
		while(   (PINB & (1 << PIN_SLAVE_CLOCK_IN)));
		while( ! (PINB & (1 << PIN_SLAVE_CLOCK_IN)));

		// Shift edge over all of slave clock's period
		busyWait1(edgePosition);

		// The signal sent to the slave.
		// A short pulse followed by a normal edge.
		// Pulse length is 1/2 slave cycle
		PINB |= 1 << PIN_OUT; busyWait1(PULSE_LEN);
		PINB |= 1 << PIN_OUT; busyWait1(PULSE_LEN);
		PINB |= 1 << PIN_OUT;

		// busy-wait for about 1/16s
		busyWait2(TIME_BETWEEN_EDGES);
	}
}

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Interesting......They should at least give you a free t-shirt!

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I opened a case with microchip, here's the prelim reply:

 

Hi Manfred,
Thank you for taking time to test this and providing such a detailed description.
This is interesting! and your assessment seems valid to me. I have forwarded this details to the design team. Let me hear back from them and update
you accordingly.
Regards,Sadik

As for my practical problem with the pin change not detected, I went with Who-me's suggestion, a cap parallel to the switch - works like a charm.

Who-me wrote:

A workaround may to be use a RC filter, and use the Pin hysteresis, to ensure the pin cannot change at a SysCLK rate.

Maybe a parallel C is enough, combined with Pullup current, and Pin Hyst. A ballpark calc is 50u*(1/16k)/250m  = 12.5nF, so try 22nF ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mzinner wrote:

As for my practical problem with the pin change not detected, I went with Who-me's suggestion, a cap parallel to the switch - works like a charm.

Note that a parallel cap will result in high currents through the swtich, eventually causing damage to the contacts.

 

Use an RC instead.  If using the internal pullup, which is typically between 20K- 50K, use of an approximately 1K resistor will keep VIL below 0.05VCC, and switch current below 5 mA.  With @Who-me's suggested value of 22nF, the TC will be about 22 µs, plenty fast for humans, and plenty slow to avoid runt pulses.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


Hi, all,

 

I finally got a comment from microchip support which is not really satisfying... :(

 

 

 

Hi Manfred,

 

I heard back from our internal team that the pin change interrupt section in the data sheet didn't mention this behavior (glitch causes the perfectly normal edge to be lost), but fortunately, in the block diagram, it describes that this glitch may happen.

 

The solution could be to use RC-filter.

 

Thank you for testing this! Your observation is correct and this is the expected behavior.

What block diagram is he mentioning?

 

Thanks,

 

-manfred

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

that is really sad news.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What block diagram is he mentioning?

Ask them to SPECIFICALLY show you exactly what they are referring to that specifically mentions this.  Read the datasheet or look at the block diagram is not a suitable response, i light of the issue.  Their response sounds suspicious.  If I have logic that has a race condition and sometimes skips a count, you don't say ...look at the logic gates--this is an expected condition (will remember that line for the boss).

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!