Mountaineer button fails after Ethernet connect

Archive
#1

The button on the Mountaineer Eth board stops working (=stops firing ButtonPressed or ButtonReleased events) as soon as an Ethernet cable is plugged in. It works when the module is reset without Ethernet connected. It also works if the module is reset while Ethernet connected. It continues to work when I unplug the Ethernet cable. But it stops working as soon as I plugin the Ethernet cable.

Tried with both static and dynamic (DHCP) IP address.

I am using the .NETMF 4.2 QFE1 with the original firmware (4.2 QFE1).

Here is a minimal test program to reproduce the behavior:


public partial class Program
{
    void ProgramStarted()
    {
      buttonForMountaineer.ButtonPressed += OnButtonPressed;
      buttonForMountaineer.ButtonReleased += OnButtonReleased;
    }

    private void OnButtonPressed(ButtonForMountaineer sender, ButtonForMountaineer.ButtonState state)
    {
      Debug.Print(DateTime.Now + " Button pressed");
    }

    private void OnButtonReleased(ButtonForMountaineer sender, ButtonForMountaineer.ButtonState state)
    {
      Debug.Print(DateTime.Now + " Button released");
    }
  }
}

Can anyone reproduce this? Is there a workaround or bugfix available?

#2

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)
#3

Can you actually deploy a LED blinking component in your test app and see whether the actual issue is that the framework stops responding, or if the timer keeps going but the Ethernet stack causes the dispatcher mechanism to stop working/responding?

#4

@ Brett - Thanks for the suggestion. I tried that and it shows that the LED continuous blinking. I observed a short (approx. 1 second) “hiccup” when connecting the Ethernet cable, but after that it continues blinking.

Here’s the new extended test code:


  public partial class Program
  {
    private readonly Timer _timer = new Timer(250, Timer.BehaviorType.RunContinuously);
    private bool _debugLED;

    void ProgramStarted()
    {
      buttonForMountaineer.ButtonPressed += OnButtonPressed;
      buttonForMountaineer.ButtonReleased += OnButtonReleased;

      _timer.Tick += ToggleDebugLED;
      _timer.Start();
    }

    private void ToggleDebugLED(Timer timer)
    {
      Mainboard.SetDebugLED(_debugLED = !_debugLED);
    }

    private void OnButtonPressed(ButtonForMountaineer sender, ButtonForMountaineer.ButtonState state)
    {
      Debug.Print(DateTime.Now + " Button pressed");
    }

    private void OnButtonReleased(ButtonForMountaineer sender, ButtonForMountaineer.ButtonState state)
    {
      Debug.Print(DateTime.Now + " Button released");
    }
  }
#5

What if you wired a button?

#6

@ Gus - Currently I have no external Gadgeteer button available. Have to buy one first and will report the results.

#7

Are you comfortable using a wire?

#8

@ Gus - Yes, I could shortcircuit certain pins using a wire. But I already ordered a bunch of Gadgeteer equipment (including a Fez Spider Kit, breakout boards and additional buttons). This will make it a lot easier for me. The stuff is scheduled to arrive next Wednesday. I will get back to the forum when I have new results with external buttons.

#9

We were able to reproduce the problem. We haven’t found the root cause yet, but are investigating. We’ll post here as soon as we know more.

Cuno

#10

@ Gus - Today I tested with an external (GHI) button connected to the Mountaineer Eth board at port 5. The same thing happens here. The button stops working after plugging in an Ethernet cable.

@ Cuno - Any news from your side? Do you know if this problem only occurs with 4.2 QFE1, or also with the 4.2 QFE2 firmware?

#11

Yes, it also occurs with the QFE2 firmware.

Our friends at CSA Engineering, who have written the Ethernet driver, have now found the culprit. A GPIO is used incorrectly, in a way that results in “stealing” of the interrupt handler. They are working on a correction.

We expect Microsoft to publish the new release of the Gadgeteer Core within the next couple of weeks. We’ll then publish an update to both NETMF and Gadgeteer for both Mountaineer boards.

#12

@ Cuno - Thank you so much. This is really good news.

Does that mean that the Mountaineer firmware will also be upgraded to NETMF 4.3?

#13

Yes, definitely.

#14

@ Cuno - What is the status/schedule for the 4.3 upgrade for the Mountaineer firmware?

We are still suffering from the hang-ups when Ethernet is disconnected/reconnected.

#15

@ candritzky - We first deployed the software to a customer site for initial testing, but now we are close to a more general beta release. This should happen before the end of this month. We’ll post about it on the forum here, and you will be able to get it from here:

Best regards

Cuno

1 Like
#16

Could you please test your setup with the new beta 1 release?

https://www.ghielectronics.com/community/forum/topic?id=13619

Thanks and best regards

Cuno

#17

Did the upgrade of the Mountaineer Eth board to .NETMF 4.3. Everything worked fine.

But I cannot test my program with the new firmware as my design also uses some GHI Gadgeteer components (Button, CharDisplay). These seem to work only with .NETMF 4.2 though the GHI SDK claims to be (and require!) .NETMF 4.3. I am very confused about GHI version compatibility. I installed the latest GHI SDK (“NETMF and Gadgeteer Package 2013 R2”), but it seems not to support .NETMF 4.3.

#18

GHI SDK supports 4.2 only at the moment.

#19

Time for a community module 4.3 sdk, bit of search and replace for the factory support and bobs your uncle :smiley:

#20

Supporting 4.3 in our gadgeteer SDK should be easy. I will request it.

3 Likes