Cannot Ping FEZ Hydra after updating to NETMF 4.3 QFE2 and NETMF Gadgeteer Package 2014 R4

I posted this on an archive but that was probably not the best place to be seen.

I have a Hydra with an ENC28. I have multiple systems that were based on NETMF 4.2 QFE2 and Gadgeteer Package 2013 R1 that have been working for several years. I could setup a board by updating the firmware and set the IP address using FEZ Config. I could then ping the Hydra to verify communication without any problems. Then I could download the software and verify it worked as well.

Once updating to NETMF 4.3 QFE2 and NETMF Gadgeteer Package 2014 R4 I can no longer setup the device and ping it. Nor does the software communicate any more. I am using Visual Studio 2013. The software sets up the Hydra as a UDP Server.

Socket serverSocket;
internal void CommunicationEngineUDP()
// setup Hydra as a UDP Server
serverSocket = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);
serverEndPoint = new IPEndPoint(IPAddress.Any, port);
serverSocket.SetSocketOption(SocketOptionLevel.Udp, SocketOptionName.Broadcast, true);

// send a message out every 2 seconds
timerUpdateData = new Timer(new TimerCallback(timerUpdateDataUDP_Tick),
null, // state
0, // due time
2000); // period

new Thread(ProcessMessagesManager).Start();

In the past I have not needed to include the ENC28 in the Program.gadgeteer display and haven’t used the reference to it. I tried to add it and then use:
ethernetENC28.UseStaticIP(“”, “”, “”);

to set the IP address when ProgramStarted starts. That didn’t change anything. Any ideas?

Check the MAC address. Make sure it is set and correct.

how about a complete sample showing initialization. you should be able to ping after initialization.

you might try to setup static address before you use the interface.

Can you clarify if you actually updated your code to use 4.3 and removed all the old references and replaced them with the new ?

I’ve done some experimenting.

I had previously updated to the latest tools set listed on .NET Micro Framework – GHI Electronics
I am using Visual Studio 2013 Professional Edition. I installed Microsoft .NET Micro Framework 4.3 (QFE2) the Gadgeeter Core that is listed on that page (4.23.1000) and NETMF and Gadgeteer Package 2014 R5.

I had used FEZ Config to update the firmware on the Hydra to 4.3.6. I loaded the Ethernet Configuration and changed it to what I needed. I had also generated a MAC address.

Step 1
I found a quick example in the Getting Started with .NET Gadgeeter document page 41. I created a new project. After creating the project, I switched the Target Framework from 4.2 to 4.3. I didn’t notice it at the time but when I created the project it defaulted to the Target Framework as 4.2. I copied the example and ran it then tried to ping the Hydra and it worked.

Step 2
For a quick test, I commented out ProgramStarted() in my project that I had updated to 4.3 and pasted the example into it. It compiles and downloads fine. I could not ping the Hydra so I am back to where I started. I looked carefully at all of the references between the Step 1 project and Step 2 and can’t find anything different.

Step 3
I decided to start from scratch and create a new project and import my code into the new project. That created a new problem. I couldn’t get Resources.GetBitmap resolved and when I imported bitmap files into Resources, it brought them in as byte arrays. I could see in the resources.resx file from the original project that there is a function for GetBitmap that appears to be automatically generated when the Bitmap is added to the resources.

    internal static Microsoft.SPOT.Bitmap GetBitmap(Resources.BitmapResources id)
        return ((Microsoft.SPOT.Bitmap)(Microsoft.SPOT.ResourceUtility.GetObject(ResourceManager, id)));

and an enumeration

    internal enum BitmapResources : short
        Screen_Saver_Logo = -8343,
        On = 1358,
        Logo = 16403,
        Off = 32185,

These did not get created in the new project. That’s another problem to fight and I decided to let it be for the moment and move on to Step 4.

Step 4
Wanted to start a new project but this time explicitly start with 4.3 selected from the .NET Gadgeteer Application Wizard. When I select 4.3 as the .NET Micro Framework version I get a message that indicates I need to download the latest version of the Gadgeteer Core. The GHI page points to the codeplex page for 4.23.1000 and that appears to be the latest.

I am thinking something behind the scenes is not updating in my existing project and if I could create a new one starting from 4.3 that might be the solution to the networking problems. If the GetBitmap problem persists, I will address that next.

Any ideas on what to try?

you keep saying 4.23 but I am sure you mean 2.43, right :wink: .

To me this seems like it hasn’t successfully installed the Gadgeteer libs, so I’d uninstall the GHI SDK and the Gadgeteer SDK, re-run the Gadgeteer SDK, then the GHI SDK. For me, with VS 2013 Ultimate (but should be no different with Pro), with the 4.3 QFE2 and 2.43.1000 SDK and GHI’s 2015R1Beta3 release, when I do the same thing as you do I can create a 4.3 app no worries

Thanks for the suggestion. I went back and uninstalled all of the tools except Visual Studio just to do a complete clean install. When I did I noticed I had two GHI 4.1 SDK items in Control Panel that were still installed. I unistalled them too and then reinstalled all of the NETMF tools. I used the NETMF and Gadgeteer Package 2014 R5 instead of the 2015 R1 pre-release. That resolved the issue with being able to create a 4.3 project directly.

If I open the existing project I have a few things to correct before it will build. Gadgeteer.Interfaces… is now Gadgeteer.SocketInterfaces… and SetupDigitalIO is now CreateDigitalIO and the way a breakout board handled the interrupts is a little different. I got through all of that with no problem. Then it builds and runs as it always has, the Ethernet socket communication just doesn’t work any more.

This is software that has been running on about 15 systems over a period of several years. It has been updated and redeployed many times with no problems. With the latest tools set, I can’t even ping the board after I updated the firmware. Before, I could always ping the board after updating the firmware and setting the IP address. I have never had to download a piece of software to the board prior to being able to ping it.

If I create a 4.3 project from scratch and pull the source files in I obviously have the same issues to fix with the digital IO but the resources now will not load as a bitmap and anything to do with Resources.GetBitmap and Resources.BitmapResources enumeration are all broken. When I add the bitmaps to the resources their properties are byte arrays. I started trying to resolve those issues again but got nowhere with it.

All I am trying to do is update tool sets and I am totally stuck now. Any ideas on what to do next?

Also, one thing I forgot to indicate. I did try the suggestion of opening the existing project, removing all of the references and adding them back but it didn’t solve the problem. I did that before trying starting and loading code back into a new 4.3 project.

On the bitmap problem, just as a check, I opened Visual Studio 2013 and created a Windows Forms project, loaded one of the same bitmaps used in the NETMF project and added it to the image resources. It shows that it is a bitmap. In NETMF it shows as a byte array.

Thanks for the suggestions. I ended up rolling everything back to use Visual Studio 2010 and GHI Gadgeteer 4.2.101 version with the version 4.2 SDK (QFE2) and the Gadgeteer Core version 2.43.800. Everything is working as it should. What I thought would be a straightforward update was nothing of the sort. Thanks again for the help.

You really should move forward, the 4.3 network stacks are an improvement over what 4.2 bought. There are some differences in how to initialize the network though, and there are plenty of examples here in how to do that.

There are some differences in the way the resources works in later VS versions. Getting binary resources in is no harder than before - what process did you use for adding the resource the way you did below ?

@ dwc - In 4.3 the networking stack was unified between the premium and OSHW offerings. As a result, the FEZ Hydra and FEZ Cerberus no longer have a default network configuration. You have to deploy a program which initializes the ENC28 before you can ping it. should get you started.

Thanks for the suggestions again. I will look at updating again. I thought it was a straightforward update and did what I should have never done. I did the update on a stable production machine prior to checking everything on an independent machine first. I will try again and see how it goes. Two questions though.

  1. With a NETMF Gadgeteer project, can you still load a bitmap and use Resources.Getbitmap… to use a bitmap in the project. I was unable to get this to work using VS 2013 Pro and the latest downloaded tool set.

  2. I never had a reference to the ENC28 in previous software. I instantiate a Socket and an IPEndpoint then setup UDP directly using the Socket. Do I now need to add the ENC28 to the Gadgeteer interface and make a call to ethernetENC28.UseThisNetworkInterface()? Is that all it should take? I am using a static IP address.

Thanks again for the help.

@ dwc - I remember there being an issue with bitmaps and resources in the NETMF tools but I can’t recall any specific threads at the moment. Regardless, it is an issue with NETMF itself, you may be able to find more information on and GitHub - NETMF/netmf-interpreter: .NET Micro Framework Interpreter

Take a look at the document I linked. Instead of calls to Dhcp, you’ll want to StaticIp calls where you can set your configuration.

@ John - Thanks. I had some time and came back to updating to NETMF 4.3 I was able to get the Ethernet interface to work as well as the Bitmap problem. The article you referenced was very helpful for the networking.

I pass the EthernetENC28 into my communication class of type Gadgeteer.Modules.GHIElectronics.EthernetENC28 and named ethernetInterface. I then called the ethernetInterface.NetworkInterface.Open() method. I then wait in a polling loop with a Thread.Sleep(100) method until the ethernetInterface.NetworkInterface.Opened property returns as true. After doing this, the Socket works as it used to.

As far as the Bitmaps not working, I was able to get that fixed too. Using a previous post answer I was able to get it to work with all but one bitmap. For some reason, one bitmap that had previous worked caused an exception to occur. Just changed the bitmap and moved on. The suggestion was from @ Architect and from here:
The suggestion was to change from Resources.GetBitmap(Resources.BitmapResources.test) to use
_bkg = new Bitmap(Resources.GetBytes(Resources.BinaryResources.test), Bitmap.BitmapImageType.Gif);

@ dwc - Happy to hear you got it all working.

@ andre.m - Apologize for this. it was a view of this forum and i’ve replied to the wrong post.

Sorry for that! i don’t want to spam!

*** i’ve deleted the post on this thread.