Main Site Documentation

Spider Ethernet Issues with JD11 Module


#1

I have worked with a MountaineerEth for months and recently “upgraded” to a Spider with the hopes of taking advantage of some of the Premium features it supports.

However, I find that getting the built-in ethernet to work to be incredibly frustrating. The forums had a long discussion about this several months ago, but like most topics on this forum, the number of issues was large and no clear resolution was described.

My Setup
TinyBooter Version: 4.2.7.0
TinyCLR Version: 4.2.7.0
Network Configuration set via FEZ Config tool
Default network settings for Built-in Ethernet:
MAC Assigned, DHCP Enabled, DNS addresses set to 0.0.0.0

My Problem
Anytime I call:

NetworkInterfaceExtension.AssignNetworkingStackTo

It generates a NetworkInterfaceExtensionException. There are conflicting code samples on the site, but it does not matter if I assign the stack to the EthernetBuiltIn object or an instance of the module name.

Additionally, as many others have noted, the yellow LED on the JD11 module is always lit.

Where should I start?


#2

There has been some issues with older firmware and sdk. please use the latest sdk and firmware 4.2.10.0. That should solve some of your problems.


#3

First issue has been resolved.

Gadgeteer project.

@ Patrick, I appreciate you including a specific firmware version number in your response. Too often on these forums and this site the phrase “upgrade to the latest version” is used, and for posts that are several months or years old, it is not clear. Also, this site does not make it very easy to determine what the latest firmware is at any given time.

@ Gus et al at GHI, I would recommend that your new FEZ Config tool could alert the user that a new version of a given firmware is available.

Now that I can assign the networking stack, I see another issue (possible bug):


static EthernetBuiltIn ethBuiltIn = new EthernetBuiltIn();
NetworkInterface netInterface = NetworkInterface.GetAllNetworkInterfaces()[0];

NetworkInterfaceExtension.AssignNetworkingStackTo(ethBuiltIn);

// Some time later in the code

Debug.Print(ethBuiltIn.NetworkInterface.IPAddress);
Debug.Print(netInterface.IPAddress);

The built-in interface IP Address is always 0.0.0.0
The “get all” interface IP Address gets assigned correctly via DCHP.

The same issue happens if I do it the “Gadgeteer” way. If I assign the networking stack to an instance of a JD11 module, it never updates its IP address property, but the global “get all” interface instance does.

This is clearly a workaround, but isn’t this another bug?


#4

@ nicholas.goodman - I see the same thing regarding IP addresses when using this version of the firmware on a Cobra I (also EMX).


#5

@ Gus - I highly second the motion of the phrase “upgrade to the latest version”

Please put the actual rev level on the support page not just “4.2” use “4.2.10.0” then its clear for everyone what is the “latest version” !


#6

@ andre.m - It is very good information but it doesn’t have the actual rev number.


#7

@ andre.m - Really

It should be on the opening page https://www.ghielectronics.com/support/.net-micro-framework

You shouldn’t have to go digging to find it and besides someone is putting the date there why not put the actual rev number.

I wasted two days thinking I had the “Latest firmware” 4.2 but not so. Watching the Forum a big number of issues are from having the wrong firmware installed myself included.

Not complaining just trying to make things better.


#8

That would be a nice feature! I vote for that :slight_smile:


#9

Then the tool will have to communicate with the network to get the latest version, which will possibly get firewall warning, which may scare some users :slight_smile: But I like the idea though.


#10

Hey Gus,

I am pretty sure most Windows installs have HTTP / port 80 open by default. A simple approach would be to have www.ghielectronics.com host an xml document, the tool determines if it can reach that URL, and if so downloads the data over HTTP.


#11

I personally don’t see that as a show stopper. Most apps are auto updating these days and need a network connection. If they don’t want it, its a simple thing to opt out of. However, it would be much nicer if this feature existed in VS and ran on first compile/deploy.


#12

@ nicholas.goodman -

Make sure DHCP is disable then these function will see correct IP which set as static.


#13

Andre and I had a chat about what might be “missing” from the current “Version information” that the 4.2 developer page has. Here’s my thoughts - yes, now it’s off topic to the originally posted question.

Seems that people don’t want to download the latest SDK and install it just to find out what firmware version it has, or even to find they are already running it. OK, I get that - I can’t remember what day I downloaded the SDK, although the file lands on my PC with the date I did that, and the “simplest” thing for me to check is the release notes on my PC since I know then what SDK version is installed, and then I need to make sure I have that same firmware loaded on my device(s) so I check with MFDeploy.

What would then help me see how old my installed SDK is, is a table that has release dates and firmware versions. Quick and to the point. Here’s one I mocked up - the first data is correct, the 2nd one may not be :slight_smile:

This page could just be linked right next to the “release notes and known issues” link as “version history” or something.

edit: image attached.