Hi, i’m trying to get cable networking working on G120HDR (and IP is not assigned by DHCP).
I’ve a G120HDR rev. 2 with a ENC28 connected to the “gadgeteer” SPI socket.
The board is up to date (loader 188.8.131.52, frmware 184.108.40.206), NETMF 4.3.
I followed the neworking sample on the new G120 manual, and the “old” G120HDR developer’s guide to know SPI socket pinout on the board.
The code used is:
public class Program
static EthernetENC28J60 enc;
static bool hasAddress = false;
static bool available = false;
public static void Main()
NetworkChange.NetworkAvailabilityChanged += NetworkChange_NetworkAvailabilityChanged;
NetworkChange.NetworkAddressChanged += NetworkChange_NetworkAddressChanged;
var enc = new GHI.Networking.EthernetENC28J60(SPI.SPI_module.SPI2, G120.P1_17, G120.P0_5, G120.P1_14); //SHOULD BE RIGHT
while (!hasAddress || !available)
//Network ready now.
static void NetworkChange_NetworkAvailabilityChanged(object sender, NetworkAvailabilityEventArgs e)
Debug.Print("Network available: " + e.IsAvailable.ToString());
available = e.IsAvailable;
static void NetworkChange_NetworkAddressChanged(object sender, EventArgs e)
Debug.Print("The network address has changed.");
hasAddress = enc.IPAddress != "0.0.0.0";
When I launch the program, the output is:
Network available: True
It never goes out from the “Initializing” while.
The DHCP is done by a simple ADSL router (SIEMENS), and a PC on the cable used gets IP correctly.
((I also tried setting static IP, but HTTP requests seems not to reach the server (and I’m not sure about the best practice case to do it))).
Anyone can suggest some tests to help me figuring out the problem?
anyone with a G120HDR or a Cobra2 Net that can test some code ? I’m struggling to locate a ENC module to test this myself
@ Jacoporunchi Any chance you have an old-school network hub that you can put in the network chain to run wireshark to check what is being sent to your router ? To me there might actually be a fundamental issue where no networking is active (wrong pins configured in the constructor perhaps??) and you’ll pretty easily see that in that case.
How do you think you mapped the SPI2 connections ? The deeper I dug into the G120 manuals and teh image of the G120HDR (the v2 board) the more convinced I am that SPI2 isn’t exposed anywhere you can access it to wire it to the Gadgeteer socket !
Let’s start from wiring:
I connected the ENC28 to the G120HDR rev2 SPI gadgeteer socket (S) with gadgeteer cable only. (I also connected the USB client DP to the USB gadgeteer socket to debug the board, but I hope it is the problem). No other connections. (Other wires in the image are just LEDs, not used and disconnected in last and future tests).
In the old G120HDR developer guide
( https://www.ghielectronics.com/docs/38/developersguide-g120-module )
section Networking, the SPI socket seems to expose SPI2 by design.
So I used code
var enc = new GHI.Networking.EthernetENC28J60(SPI.SPI_module.SPI2, G120.P1_17, G120.P0_5, G120.P1_14);
as in the guide.
Should a network switch work with Wireshark?
if you have an advanced switch that can mirror traffic on one port (the one connected to the ENC28) to another port (PC running wireshark) then you can use it instead of a hub.
OK, so how about we take a small detour. Can you confirm that you can blink LEDs on the 3 GPIO pins on the S socket, based on their name ? Can you confirm that the ENC28 constructor takes the pins in the same order as the marked obsolete developers guide? And can you see LEDs flash on the SPI lines if the ENC isn’t connected ? (just trying to eliminate these pins as sources of failure)
Now it works, but…
I tried with LEDs to inspect pins, and all 4 are working (4, since I noticed also pin P1.16 is exposed on socket S, maybe internally, maybe not used).
I then reconnected ENC28 with gadgeteer cable to try wireshark, and it worked fine with the last program.
I’m happy for the result, but worried about about future similar problems.
It always worked with NETMF 4.2, and stopped on NETMF 4.3. I thought about a NETMF 4.3 problem, but now I think it was something hardware related…
So, since I reloaded the same program as before, I think it could be:
A wiring failure with gadgeteer cable (did you never see faulty gadgeteer cables/sockets?);
A problem with pins (like locked, and unlocked enabling them as output ports)(Is it a realistic idea or only a mad thing?)