Hello all, in my frustrated attempts to get working the J11D ethernet module I wrote some code that reboots the module. To my horror the device continuously reboots and I have no chance to take control. Please please does anybody know how I can break this cycle. It’s all my silly fault but I spent many hours trying to make use of the Gadgeteer network stuff but it doesn’t seem to work as expected, especially DHCP and the network UP/DOWN events.
Thank you.
Have you tried erasing your app via mfdeploy?
Hi Justin, thanks for the quick reply. I cannot even use mfdeploy because the USB is constantly disconnecting, is there a trick I am missing? I cannot believe I got myself into this crazy loop situation.
Derek
I would think then it’s a firmware reflash…
PS…been there done that with infinite loops 
PPS welcome to the nut farm 
Thanks Justin.
I reloaded the firmware and it’s now clean again, pew!
One thing I noticed though is that I can no longer look at the devices network configuration via MFDeploy, it gives me an error “Device has old or unsupported configuration” no matter what I do. Before the firmware reload I was able to set the IP address etc.
Derek
Good news - they are pretty hard to totally kill…
Are you running the latest and greatest 4.2 firmware or 4.1?
Hi,
It’s 4.2. All seems ok except for the configuration problem.
Derek
There’s a chance you need to use the 4.2 version of MFDeploy - not sure if you’re running the one from the 4.1 directory?
I also have a suspicion there’s a change that means the static network settings in MFDeploy aren’t used - just set them via your app.
Hi Brett,
Thanks for the reply. Just checked that I am using the 4.2 version and from the 4.2 tools directory. The file version also states 4.2. Still mfdeploy will not let me look at the network configuration. It was possible before I reinstalled the 4.2 firmware. I am so confused. Do you know if the configuration still remains in the device even though I reinstalled the firmware?
I think the biggest question is how should all the basic networking things work i.e. DHCP and STATIC. Should I set it all in code and ignore the configuration or vice-versa or maybe a blend of the 2, it’s not clear what has to be done. Last night setting a static IP in code had no effect until the device was rebooted.
The strange thing right now is that I am debugging the app again (thankfully to the firmware reinstall) and I set a breakpoint just after I get the network information and I can see the IP address is set to the address set by my DHCP server (router) of last night. At the moment I am working stand alone with no network so how the IP address is being picked up is anyones guess, probably from the configuration that I can no longer see.
Sorry to ramble on but there are so many little things that don’t seem to work properly and is preventing me from developing my product.
Thanks,
Derek
Can you clarify, were you running 4.1 or 4.2 before this recent reinstall (not that it’s overly important, but may lead us to explain more)
Setting a static IP address in code. That should always work. It will use the CODE settings not any stored settings
Setting a dynamic IP address via DHCP. That should always work. It will use the DHCP address it’s offered (assuming it is offered one) and won’t use any stored settings.
If the network isn’t connected, then DHCP may fail back to an address in the firmware - but that’s an invalid test, isn’t it? Who cares what the IP address might be if the network isn’t connected.
Hi Brett,
I was on 4.2 from the start and there are no differences at all, just reloaded the firmware
Yes, all I want to do is choose to use DHCP or STATIC at the start of my app and that’s all. I really do need to know if the network is up and usable but there seems to be no way of knowing without using a socket.
During my tests last night I noticed all sorts of strange behaviour and inconsistent results. The worst one for me was when I declared a STATIC ip which succeeded in code but the device was not PING’able at that address. It was still PING’able by the previous address until I reboot, then it uses the new address. It is as if the device has to know about the address much earlier than the start of the c# app.
This why I started to reboot the device immediately after setting the static ip address (is how I got into a bad loop).
Some observations on start-up:
The network UP event never came but the network DOWN event always came.
ReleaseDhcpLease() set the IP to 0.0.0.0
RenewDhcpLease() did nothing at all
DHCP generally sensitive to some DHCP servers, simply ingores them (as it seems)
It’s really good to talk about this stuff, last night I felt like I was on a tiny island with all this.
Thanks,
Derek
While USB specifications say ports should provide 500mA, we rarely see a port that can actually provide 500mA. We always recommend the use of powered hubs or a power pack instead of relying on the USB power. Use a powered hub from a known brand, not a cheap hub. If your device has the option of using a power pack (for example the USB Client DP Module) then you can use a power pack instead. 9V 1A is typically recommended but check the bottom of the circuit board for printed voltage range. All power connectors on GHI products are 2.1mm with positive on the inside and negative on the outer ring.
Not using a powered hub or power pack can cause:
[ul]Unexplained behavior
Device does not function
Device functions intermittently
Device functions but network fails
Device functions but SD card fails
Device functions but firmware update fails[/ul]
(Generated by QuickReply)
Hi Gus,
Thanks for your help I will try the power solution later today.
Is there a good simple example of DHCP and STATIC ip for the Spider?
I don’t know if you followed all my thread but I have an issue where I cannot see the network configuration via mfdeploy. I was able to do this before I reloaded the 4.2 firmware. Now it tells me that ‘Device has old or unsupported configuration’, how can I correct this?
Sould I even care about this in 4.2?
Thanks,
Derek
I wouldn’t worry about the MFDeploy issue just yet - I think there was a breaking change that meant this is expected, but I don’t have 4.2 myself so can’t check readmes or wxperience it myself (I also don’t have a spider)
I wonder whether your inconsistent results were a direct result of the changes you’re doing or trying out.
The one thing I would say about DHCP and networking - if you don’t use the defined MAC address for your board (ie the one on the sticker) then you’ll potentially get issues like this and networking won’t work on all routers/dhcp servers. A worse situation is when you have the same MAC address on multiple ports; make sure that’s not the cause.
And if you have IP level issues, the best approach for understanding these is actually a network packet capture. Use Netmon or wireshark to capture the packets going on.