We are having some trouble using Ethernetbuiltin on the G400D module:
When running the code using visual studio debgger, the ethernet fails to initialise properly - although no exception occurs, the device cannot be pinged, and the device cannot send data on the network - but when the device is reset and allowed to run without the debugger attached, it is possible to ping the device, and the device is able to send data on the network normally.
I have attached a simple code snippet as an example. when the code is run in visual studio, networking fails. but when the device resets, it is possible to ping it.
@ ryanc - Which SDK are you using? What line does it fail at?
Even if “ethernet.NetworkInterface.EnableStaticIP” works outside of VS, I would change it to “ethernet.EnableStaticIP” in case we ever do further initialization in the interface.
I have tried SDK 2015, and also the latest 2016 pre-release (both with their corresponding tinybooter and firmware updates applied)
I have also tried visual studio 2015 and 2013 , and used different G400D SOM modules in each case.
I have also tried different PCs.
Note that it works fine on the G400 Raptor board with EthernetENC28 board.
So the issue seems to be specific to G400HDR with Ethernetbuiltin
Initially, like @ leforban i suspected it was our hardware, so I wired up a G400HDR board, and manually soldiered wires onto a EthernetJ11D module with a breakout board- same result.
in visual studio with the debugger attached, no network - but when resetting the device, it works fine.
regarding your comment on my using “.NetworkInterface” , I have tried it directly (ethernet.EnableStaticIP) , and the result is the same.
I wish to point out that I have noted that if you use the debugger to step through the Ethernet code, you can ping the device. However if you attach the debugger BUT do not step through the code, then you cannot ping the device. This is more the case for me, when I do not wish to check the Ethernet code, but rather debug some other area of the devices operation by using the
.
I feel this is where GHI is missing the bug that we are trying to point out. They show it works when they step through the code (as it seems Dat has done), when the debugger is attached. However none of the posts I have seen (including a lot of @ leforban, where I noted the original problem) have pointed out this subtle difference. All of the responses seem to be looking for a crash or an exception thrown, where the problem is simply that the Ethernet does not work under this condition. The code executes without crash, but somewhere along the line, the device can't be pinged.
If GHI can please try to run the code, with the debugger attached, but without stepping through the code, I feel they may reproduce this bug.
I have replicated this behaviour on a G400D using the built in Ethernet connection using the GHI 2015 R1 package with .net Micro 4.3 (QFE2) using the following code on our custom hardware, with a continuous ping of 192.168.0.133 running on my pc:
using System;
using System.Threading;
using Microsoft.SPOT;
namespace EthernetTest
{
public class Program
{
public static void Main()
{
try
{
GHI.Networking.EthernetBuiltIn ethernet = new GHI.Networking.EthernetBuiltIn();
ethernet.Open();
ethernet.EnableStaticIP("192.168.0.133", "255.255.255.0", "192.168.0.1");
while (true)
{
Debug.Print("Sleeping...");
Thread.Sleep(500);
}
}
catch (Exception e)
{
Debug.Print(e.Message);
}
}
}
}
I however was not able to get any partial operation under Debug mode, as mentioned by others. As long as the Debugger is attached, the network does not respond. If I reboot the device without attaching VS, the ping responds.
I then tried downgrading the GHI package to 2014 R5 along with the TinyBooter update via SAMBA, updated the GHI library references in the above code and then everything works without issue when the debugger is attached. I rebooted the device/reran the code in debug mode a couple of times to be sure.
I then tried upgrading to the next GHI package I have available which is 2015 R1 Prerelease 3 which worked initially but after I rebooted the device it again resulted in the same behaviour as in 2015 R1 and I couldn’t get it working again after that.
I then moved back to 2014 R5 and brought the Ethernet back to life again, even after many reboots & reattaching VS.
For good measure, I repeated the 2014 R5 and 2015 R1 PR3 tests above on a G400HDR board + JD11 connector with the same result.
I didn’t step in the code. I just did pause to capture the image after ping it.
But for sure, I just tried again, only click f5 then wait for few seconds for network is ready (depends on your network, because your code has no event). Ping it => work fine.
Let me know if you find out the way to reproduce it. Thanks
can you guys try to use MFDeploy as a debugger instead VS and see if the same issues occur:
if that doesn’t help would you please try to put your code in a Thread and start that thread with delayed timer to see if there is a race condition happening.