PowerState.RebootDevice & Ethernet circuitry

Hello,

 

I wrote a very small web server for the Netduino Plus 2; the only purpose of the server is to give the user the ability to change the IP configuration of the board (enable DHCP or set a static address).

 

At the beginning of my Main() routine is a piece of code that retrieves the IP configuration from SD (if any, otherwise, it uses defaults), programs the network interface accordingly, and then starts the web server.

 

Once the user has entered the new configuration, I store it to the SD card, then reboot the device with [font="'courier new', courier, monospace;"]PowerState.RebootDevice(false)[/font]. The [font="'courier new', courier, monospace;"]Main()[/font] routine restarts, but then the Netduino card cannot be accessed from the network ; it just does not answer ; for the rest, it appears to be alive and well. I have to remove and re-apply power to get it back to responding to the network.

 

I tried RonZon's approach to hard reset the Ethernet chip (http://forums.netdui...+ethernet +port), but that apparently does not change anything (though I'm not sure what I'm really doing as I'm kind of working blindfolded, not havving an oscilloscope to put on the /ENC_RESET signal...).

 

Any idea how to change the IP configuration on the fly without powering off the Netduino ?

 

BTW, this is with the .Net MF 4.3 and the 4.3 beta 1 SDK.

 

Thanks,

Pyt.

 

The code you link to is sending the wrong value on the pin at the very least, use Aaron's code linked in the reply here

 

http://forums.netdui...ripheral-power/

The code you link to is sending the wrong value on the pin at the very least, use Aaron's code linked in the reply here

 

http://forums.netdui...ripheral-power/

 

Hmm, I believe the value was right (the signal is active low), but anyway, thanks for the hint. I tried to enhance my reboot routine :

public static void Reboot() {    OutputPort ethResetN = new OutputPort((Cpu.Pin)50, true); // reset signal for Eth chip, active low    OutputPort powerEnableN = new OutputPort((Cpu.Pin)47, false); // power enable for Eth chip, actie low    ethResetN.Write(false); // reset Eth chip    Thread.Sleep(50); // sleep 50ms    powerEnableN.Write(true); // turn power off    Thread.Sleep(1000); // sleep 1s    powerEnableN.Write(false); // turn power back on    Thread.Sleep(100);    ethResetN.Write(true); // release reset signal    PowerState.RebootDevice(false); // hard reboot}

but to no avail. This is still not equivalent to unplugging/replugging the netduino device. My guess is there must be some part of the very early Ethernet chip initiallization which is not re-run when PowerState.RebootDevice() is called. Or maybe I just goofed somewhere...

 

The overall logic of my program is as follows :

public static void Main() {    // This is where the IP configuration gets set according    // to information stored in the SD the last time around.    NetConfig.Initialize();    // Start the web server in a separate thread    // (prompts the user for a new IP address)    new Thread(WebServer.Run).Start();    // More logic here to spy on the switch and reboot when it    // has been pressed for more than 3 secondss.    // The reboot can also be triggered by an action through the    // web server}

Chris, any hint ? (Happy new year by the way, and thanks for staying on line at this time of year...)

 

Thanks,

Pyt.

Hi Pyt, The hard reset should--literally--do a hard reset on the board. Which should be equivalent to pressing the reset button or powering down/up the board. It's possible that there's a timing issue somewhere in the core NETMF ENC28J60 driver which is occurring in conjunction with or because of the power-down/power-up sequence. In theory...if you shut off the ENC28J60's power and wait a few moments--and then simply do a hard reset--the board and initialization sequence should behave exactly like they do when you plug in a board. BTW, tiny differences in resistors and capacitors (within their +/- % tolerance ratings) could cause something to work perfectly on a board even though there was a timing issue--while not succeeding on another board. Chris