Cerbuino InterruptEdgeLevelLow always fires on D9

The following is very simplified code that runs on a Fez Cerbuino Bee Rev 1.2 with nothing connected to it at the time of testing. In my real world application, I have a motor controller connected, but I get the same iffy behavior with nothing connected.

If I use pin D5 in the test, then it works as expected … the interrupt never fires …

If I use pin D9 … the interrupt fires immediately.

Here is code, that makes very minimal changes (just to declare the interrupt and its handler) to the default template.

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

namespace GadgeteerApp1
    public partial class Program
        /// <summary>
        /// The only custom variable I have declared for this test 
        /// </summary>
        public InterruptPort FaultPin;

        // This method is run when the mainboard is powered up or reset.   
        void ProgramStarted()
            // Use Debug.Print to show messages in Visual Studio's "Output" window during debugging.
            Debug.Print("Program Started");

            ///The only custom code I have added to the default template
            FaultPin = new InterruptPort(GHI.OSHW.Hardware.FEZCerbuino.Pin.Digital.D9, true, Port.ResistorMode.PullUp, Port.InterruptMode.InterruptNone);
            FaultPin.Interrupt = Port.InterruptMode.InterruptEdgeLevelLow;
            FaultPin.OnInterrupt += new NativeEventHandler(FaultPin_OnInterrupt);

        /// <summary>
        /// The interrupt handler that shows the problem ...
        /// </summary>
        void FaultPin_OnInterrupt(uint data1, uint data2, DateTime time)
            Debug.Print("Received a FaultPin intterrupt");

Using code tags will make your post more readable. This can be done in two ways:[ol]
Click the “101010” icon and paste your code between the

 tags or...
Select the code within your post and click the "101010" icon.[/ol]
(Generated by QuickReply)

I’d ask why don’t you create the interrupt with edge triggered low setting in the first place; and if you do, does that change the behaviour?

The easiest way to fix your code tag problem is to click the pencil icon above/right on your original post, highlight the code section, then click the 101010 to the top/left of the post, then hit save/submit.

Check this thread as well:


@ Brett - Thanks for the tip on the code tagging … I will remember it for next time.

To answer your question about creating the interrupt with edge trigger low setting is: That is how I originally had it in my code. Splitting it out was part of me trying to circumvent the problem. The problem still exists either way.

@ Architect - I had read the thread you suggested prior to posting my original question. The thread you reference only applies when COM3 is in use. I am not using any COM ports, so not sure how this would apply to me. Perhaps I am missing something?

The code I posted is very simple, and can reproduce the problem on my Cerbuino WITHOUT ANY modules attached. I’d be curious if the same code works on somebody else’s bare Cerbuino board … any chance you or somebody at GHI can test it?

I would be happy to, but I don’t have my bee with me at the moment. I am sure somebody will jump in to help though.

@ Architect - Tx! Despite me being new here, I have come to appreciate (through my own experience and by reading other topics) how super-helpful and engaged the community here is :slight_smile:

Thank you! Glad to hear! :slight_smile:

I have managed to workaround this one for now, by using a different pin. But for the interest of the quality of the product, and other users who might need this pin, is there anybody who can try to reproduce this problem … I think it would be good to know if this is a problem on my own Cerbuino, or if it is a general Cerbuino problem.



I had an opportunity to test your code and D9 does indeed fire when you use InterruptEdgeLevelLow. I noticed however that you are using EdgeLevel instead of just Edge interrupts. To avert the undesired behavior you may wish to use Edge interrupts instead.

Tx Aron. I did eventually come to the conclusion(trial and error) to use Edge interrupts, but if I understand you correctly, then this is a bug. How does one go about reporting it so it can get fixed in a future release?

It may not be a bug. I am not sure the full nature of how level interrupts work, but in the interrupt initialization code, level interrupts are checked to see if the state is how it was selected and if it is, a forced interrupt is fired. That is why I believe the interrupt fired upon program start-up.

@ Aron - In my original tests, I swapped pin D9 (the one that fires the event) with pin D5, and then the interrupt no longer fires on start-up. If you still have the code, and you try see if D5 with the EdgeLevel behaves differently to the D9 with the EdgeLevel … as it does for me?

In the past, GHI did not support level interrupts, only edge interrupts. Does the newer equipment actually support level interrupts?

@ Mike - Good question. I do not see anything in the docs to suggest that they do or do not support it. Perhaps somebody from GHI can clarify for us?

Let me ask this please, why do you need level interrupts?

@ Gus - From the .Net Framework SDK Docs …
" The system dispatches only the first occurrence of a level interrupt until it is cleared by means of the InterruptPort.ClearInterrupt method.
With a nonlevel interrupt, every specified edge is dispatched, and the InterruptPort.ClearInterrupt method has no effect."

My hardware (motor controller chip) has conditions under which it will bring the pin low (invoke the interrupt) more than once in a very short period of time. I need to take action the first time ONLY.

I’m sure there are many different workarounds, but the EdgeLevel interrupt seemed to be the most elegant.

@ JackN - I agree that is a good use of level interrupts. Just wanted to be sure you understand it as most users don’t.

We did not support level interrupts but I see it coming in future. That is for our premium offers. On cerb family, which is open source, it maybe there but not sure how stable. This peice was developed by Oberon.

We will add this to our to do list.

@ Gus - Thanks :slight_smile: