Interrupt handler firing when it shouldn't?

NETMF & Gadgeteer
1

Hi,

In my PandaII project, I’ve added a simple class “SomeClass.cs”:


using System;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using GHIElectronics.NETMF.FEZ;

namespace InterruptTest2
{
    class SomeClass
    {
        private InterruptPort _MyInterruptPort = new InterruptPort((Cpu.Pin)FEZ_Pin.Interrupt.Di42, false, Port.ResistorMode.PullDown, Port.InterruptMode.InterruptEdgeBoth);

        public SomeClass()
        {
            _MyInterruptPort.OnInterrupt += new NativeEventHandler(_MyInterruptPort_OnInterrupt);        
        }

        private void _MyInterruptPort_OnInterrupt(uint data1, uint data2, DateTime time)
        {
            Debug.Print("You should not see this message.");
        }

    }
}

In “Program.cs” I instantiate the class:


using System;
using System.Threading;

using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;

using GHIElectronics.NETMF.FEZ;

namespace InterruptTest2
{
    public class Program
    {
        public static void Main()
        {
            SomeClass someInstance = new SomeClass();

            Thread.Sleep(Timeout.Infinite);
        }

    }
}

I’ve run the program on 2 different FEZ Panda IIs now, yet I get the same output. Namely, the interrupt handler seems to always fire, printing the message “You should not see this message.” even though I set InterruptMode to InterruptNone. Does anyone know why?

Here’s the SDK/firmware info:

SDK Version 1.0.17
October 06, 2011

Pinging… TinyCLR
HalSystemInfo.halVersion:
HalSystemInfo.halVendorInfo:
HalSystemInfo.oemCode: 0
HalSystemInfo.modelCode: 0
HalSystemInfo.skuCode: 0
HalSystemInfo.moduleSerialNumber:
HalSystemInfo.systemSerialNumber:
ClrInfo.clrVersion: 4.1.2821.0
ClrInfo.clrVendorInfo: Microsoft Copyright © Microsoft Corporation. All rig
ClrInfo.targetFrameworkVersion: 4.1.2821.0
SolutionReleaseInfo.solutionVersion: 4.1.7.0
SolutionReleaseInfo.solutionVendorInfo: GHI Electronics, LLC
SoftwareVersion.BuildDate: Sep 28 2011
SoftwareVersion.CompilerVersion: 410561
FloatingPoint: True
SourceLevelDebugging: True
ThreadCreateEx: True
LCD.Width: 0
LCD.Height: 0
LCD.BitsPerPixel: 0
AppDomains: True
ExceptionFilters: True
IncrementalDeployment: True
SoftReboot: True
Profiling: False
ProfilingAllocations: False
ProfilingCalls: False
IsUnknown: False

Thanks!

2

We never tested interruptnone as if we do not need interrupts then we would normally use InputPort

3

Gus, the original code used InterruptEdgeBoth – and the interrupt handler kept firing with that setting, so I changed it to InterruptNone, and it still does it.

Could you perhaps run the code and see if you can replicate my issue? I get the feeling that maybe I’m overlooking something really obvious . . . .

I will change the code back to use InterruptEdgeBoth.

4

Keep it simple, connect that pin to GND and see what happens.

5

Sounds a bit like my problem with the interrupt. It kept firing with 6- 8 ms timing on one of the edges, but not on the other. Incorrect interrupts are related to glitch filtering. But they are definitely there. Even with glitch filtering disable! Changing the glitch filter timing changed the time between unwanted interrupts. I repeat: glitch filtering was disabled - also because InterruptEdgeBoth does not support it.

6

Grounding the pin made the errant interrupt go away, but isn’t that what ResistorMode.PullDown is supposed to do?

I’ll try tinkering with the glitch filter timing with the pin floating to see if that makes a difference.

7

Here’s a summary of what I found so far using InterruptEdgeBoth in all cases:

1.) When using ResistorMode.PullDown and leaving the pin electrically floating, the phantom interrupt triggers as soon as I attach the event handler.

2.) When using ResistorMode.PullDown and physically grounding the pin, the phantom interrupt no longer fires (which is good).

3.) When using ResistorMode.PullUp, the phantom interrupt does not appear, regardless of whether the pin is floating or grounded (which is also good).

4.) Setting GlitchFilter to True or False did not change the interrupt behavior, nor did playing with Cpu.GlitchFilterTime. So the glitch filter doesn’t seem to be a factor in my case.

I think I’ll be using ResistorMode.PullUp from now on, but this behavior does raise a few questions about what’s going on under the hood:

Why is it necessary to physically ground the input pin if that’s what ResistorMode.PullDown is supposed to do?

Why does ResistorMode.PullUp seem to work when the pin is left floating, but ResistorMode.PullDown makes the phantom interrupt appear?