Button module sometimes fires wrong events using FEZ Spider II


The Button module sometimes fires the wrong event, 1 out of 10. I investigated the problem and I could reproduce it using a very simple program using just the FEZ Spider II and a Button module.

void ProgramStarted()
    button.Mode = Button.LedMode.OnWhilePressed;

When I press the button the LED will sometimes not turn on, and when I release the button the LED will sometimes not turn off. I used ILSpy to investigate “NETMF 4.3\GTM.GHIElectronics.Button.dll” assembly to see what the Button class does and there is a interrupt handler that calls this:


The value is used to handle switching the LED and calling the ButtonPressed and ButtinReleased event, which is sometimes incorrect. When I implement a timer that calls button.Pressed property, the value seems OK. Almost seems like a sequence problem where the button state is stored after the interrupt is fired?

I used FEZ Config to update both the Loader (TinyBooter) and the firmware (TinyCLR) to version

Does anyone has the same problem?

1 Like

Interesting I did not know that…what is the difference?

The version of the buttons is 1.4.

I also tried the same test with the same buttons on my FEZ Reaper. There they work fine.

[em](Couldn’t replay for 8 hours because it isn’t allowed by the spam protection after the first post…) [/em]

1 Like

Or you could have taken a look at the source code on BitBucket


The only secrets that GHI is rumored to have are @ Gary’s secret lists and not so secret lists, which is why he now has new secret lists.

@ Duke Nukem - is on the new secret lists for spilling the beans about the secret lists.

Definitely take a look at the posted driver code, you can just plug it in manually and set break points to see what’s going on.

@ Bas van der Linden - Even though it works fine on the FEZ Reaper, can you try or have you already tried a different button on the FEZ Spider II?

Hi John,

I started with two buttons on the FEZ Spider II and they had the same behavior. I also tried different ports. Same behavior. Then I used one of the buttons on the FEZ Reaper where I didn’t have the problem.

the button driver code is doing something I do not recommend.

There is a delay between the occurrence of an interrupt and its appearance at the interrupt handler. The event queue thread handling causes this delay.

the driver is reading the live value of the input port, instead of using the bool value passed to the interrupt handler, which is the input value which caused the interrupt. this can result in a race condition, and unexpected results.

with a faster cpu a problem is less likely to occur.


@ Mike - How do you know stuff like that? Lots of us could benefit from a little course on topics like this…

The button driver is the SIMPLEST of all drivers known to man, and still its difficult to get right… obviously.

The contacts of a mechanical switch bounce when they are triggered/released. An interrupt will catch the initial change of state but the actual input signal will alternate between hi/low several times before settling. If you read the state of the input right after the interrupt is generated you have a good chance of reading the bounce.

Generally for a mechanical switch you want to denounce the signal, wait about 10ms after the interrupt to read the switch state and compare to the original interrupt state. If they match it is a good input, if they don’t it was noise.

I noticed on my switch module that there is a spot for a capacitor. This may have been included for some analog filtering of the signal.

@ njbuch - interrupts and the event queue is a subject that used come up a lot. at my age I remember technical tidbits but have no idea when I learned them…

@ Mike - Thanks for the catch, this should be fixed for the next release.

@ Bas van der Linden - If you want to try this change right now, you can add the button driver to your project (https://www.ghielectronics.com/docs/122/gadgeteer-driver-modification) and make the changes we made in https://bitbucket.org/ghi_elect/gadgeteer/commits/eba1405f769bd03e7241b5ca8cc305d5a4ba4be1.

Hi John and Mike,

First of all. Thanks!

I tried it and it solved triggering the wrong event. But now I notice that 1 out of 20 button presses, an event pair (both ButtonPressed and ButtonReleased) is also missing. (And thus also no LED switching). The code change is still an improvement, I think, because it prevents receiving the wrong events.

I did some extra testing. I polled for the Pressed property and it does registers the button press, when there are no events. Also tried two buttons and different ports. All the same behavior. Then I also used the Joystick and its JoystickPressed and JoystickReleased events. It has the same behavior as the buttons. To be sure, I also tested with the original button driver and there also an event pair is missing occasionally (I just didn’t notice it previously).

So, could it be something with my FEZ Spider II ?

@ Bas van der Linden - Good that its moving forward. Every year when this topic comes up again someone links to this: [url]http://www.eng.utah.edu/~cs5780/debouncing.pdf[/url] which might give you some hints as to what is going on.

I have always felt that buttons where crappy. But essentially the GHI button module might not be of a high quality on the button mechanics. If you want the VIP Executive button with no glitches, you can pay $50 for this one [url]http://www.mouser.com/ProductDetail/Apem/AV031001A2/?Apem%2FAV031001A2%2F&qs=sGAEpiMZZMvxtGF7dlGNpnEySZReSZQ5IUMN1cxKg7E%3D[/url]


I always send you to Jack’s page :slight_smile:

I discovered that G120/MF4.3 sometimes misses external interrupts. In my application the external interrupt is generated by an 8 bit micro controller and i could easily create a work around by generating a number of pulses. But of coarse thats not possible with just a simple button ???

Me too. And Brett? Why is that?

because it’s his IP ? That’s all…

@ Brett - i was referring to why The g120 sometimes looses interrupts.