mega169 pin change interrupt problem

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

I am using a mega169 to read 7 toggle switch lines on port E. The port is initialized like this:

	DDRE = 0; // Port E is switch inputs
	PCMSK0 = 0xff; // all pins of Port E generate interrupts

The pin change interrupt register is set up like this:

		EIFR = 0xff;
		EIMSK = 1<<PCIE0; // allow interrupts from pin changes on port E

My problem is that sometimes the interrupts are generated, and sometimes not, and I cannot find any kind of condition that affects this.

The switches are set up in a NO configuration, and the inputs of the port are pulled to ground via 47K resistors. When the switch is "active" it pulls the port pin to VCC. Rise times are in the nsec region (about 4ns, according to my scope). I cannot find anywhere in the ATmega169 data sheet whether the PCINT pins are level or edge driven, but either way, I should be OK. Scope shows that pins are at ground when off, and go to VCC when switch is activated. It does not seem to be pin specific; I can switch virtually any switch and get several times in a row where no interrupt is generated, then several times when it isn't, then it will work again. At this point, I'm clueless.

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

How are you determining that it doesn't fire? Buttons can bounce and can disguise a simple "turn on the led".

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.

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

theusch wrote:
How are you determining that it doesn't fire? Buttons can bounce and can disguise a simple "turn on the led".

I have a number of things that should happen when the interrupt occurs. In addition, I have a couple of lines of code to set/clear a pin on another port that I can observe with my 'scope.

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

davetelling wrote:
I can observe with my 'scope.
If you have a scope then presumably you can look at the INPUT activity at the pin as well as the output activity of the pin toggled by the ISR?

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

Can we assume you are NOT using any sleep mode that turns off the I/O clock ?

 

Edit

My memory is failing me:

15. External Interrupts

...

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

...

Pin change interrupts on PCINT30:0 are detected asynchronously. This implies that these interrupts can be used for waking the part also from sleep modes other than Idle mode.

That statement about triggering even if configured as outputs provides a way for you to test your ISR without the complication of push-button switches.

 

Last Edited: Wed. Jan 15, 2020 - 02:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

N.Winterbottom wrote:

Can we assume you are NOT using any sleep mode that turns off the I/O clock ?

 

Edit

My memory is failing me:

15. External Interrupts

...

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

...

Pin change interrupts on PCINT30:0 are detected asynchronously. This implies that these interrupts can be used for waking the part also from sleep modes other than Idle mode.

That statement about triggering even if configured as outputs provides a way for you to test your ISR without the complication of push-button switches.

 

I can see both switch input and interrupt response on the 'scope. Whether or not I get  an interrupt seems to be more-or-less random.

I am using sleep mode, and I run an async 32.768 KHz crystal on timer 2, which also interrupts to wake the system. that seems to work flawlessly. Just for fun, I disabled the sleep mode (basically the main loop just runs continuously) and that did not seem to make any difference. At this point, I'm going to see if there is some kind of weird interaction between the timer2 interrupt and the pin change process.

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

Well... to quote the bard, "...the fault is not in our stars, but in ourselves"  (or in my case, the fault is not in the hardware, but in the wetware!)sad It turns out the the function that is activated by the interrupt (I set a bit in the ISR, and when the system wakes and enters the loop, that bit is tested and branches accordingly) I disable the switch interrupts as I process the various conditions. It just happens that I was testing an alarm function that ran for about a second, and that time, no new switch interrupts could occur. I was trying to flip switches too quickly, as this morning I found that if I flipped the switch, the alarm would occur (as it should) and if I waited a bit after closing that switch and flipping another, it would work correctly, but if I did this too fast, the second switch wasn't "seen". So, at this point, I have some time optimization to do. Thanks to all who offered advice!