# Netduino Interrupts Affected By PWM - Diagnosis of Issue

I've got a funny problem with interrupts and PWM signals that's causing false interrupts to trigger. What exactly is happening is that I'm using a hardware debounced quadrature rotary encoder. The pulses from the encoder are connected to interrupts which then I can determine the direction of rotation. Pretty standard routine. This works fine on it's own.

Now, I introduce a PWM output into my project. In this case, lets say I am dimming an LED. I load my program and the led works fine. When I rotate the encoder one "click", It appears that there are multiple interrupts that are triggered on the encoder..on the order of about 16 times the amount expected.

I've simplified the code all the way down and I've tried different different combinations of PWM and Interrupt pins and the response is always the same. The one bizarre thing I notice is that if I disconnect the jumper wire from the PWM pin to the LED, the problem goes away and the encoder starts behaving like it should. I'm baffled and can't figure out what's going on here?

How can I debug or test this? What's with the PWM jumper unplug and interrupts working properly? What does this sound like?

Also, I've asked this question on the Netduino and GHI electronics forums and haven't received any solutions.

simulate this circuit – Schematic created using CircuitLab

Actual Circuit:

Update: Based on the help in the comments, I've uncovered that there is some type of noise induced in the PWM jumper wires which affect the jumper wires connected to the rotary encoder. When the PWM jumper wires are near the encoder jumper wires, the problem condition exists. How to I eliminate this noise, other than keeping the jumper wires apart from each other. Furthermore, how do you eliminate this noise in the case of PCB traces?

• My guess is that you have a layout problem. The currents flowing in the PWM circuit are causing ground bounce, coupling, or level shifting such that the interrupts get triggered. Better layout, decoupling and routing of the high current and high dv/dt signals should solve there problem. – John D Apr 14 '14 at 18:06
• Have you got an oscilloscope you can look at the signals with? That would be a good start. – John U Apr 14 '14 at 18:42
• What amount of current does the LED draw and how is it connected to the Netduino? Did you use extra decoupling around the LED driver? Also take a look at this electronics.stackexchange.com/questions/90971/… – jippie Apr 14 '14 at 19:09
• @JohnU I'm working on getting an oscilloscope ASAP, BUT I do have a logic analyzer which shows the expected behavior for each click of the encoder. I recognize an oscilloscope is really what I need, but FWIW the logic analyzer giving expected results. – GisMofx Apr 14 '14 at 19:14
• What exactly are we seeing in your diagram? I'm assuming: A and B are connected to your input pins, C is connected to ground? – John U Apr 14 '14 at 19:22

Use software debouncing: In your interrupt routine deactivate interrupts (so no other interrupts after the current one are fired) and then set a flag, that the interrupt was called.

In your Main routine check for the flag, act on it and then enable interrupts again. Maybe add a small delay before enabling interrupts again.

This seems to be another solution to software debouncing:

 private static void Button1_OnInterrupt(uint data1, uint data2, DateTime time) {
// glitch filter. events within 50 milliseconds of the first event are discarded