EMX lockup on software reset


Are there any I/O pins that must be held specifically high or low to ensure correct EMX operation?

We use EMX units on a custom board however it does not always reset on a software reset.

When do we see a software reset? Well the most common is during a VS2010 debug session on the unit where the debugger does a ‘reboot’ of the board after downloading assemblies. The board normally hangs until you press a hardware reset.

Where else do we see it? Well we have the watchdog enabled… we have to since the PPP layer locks up sometimes when reconnecting to a network over a GSM module. So if the watchdog fires, which is very rare, we’d expect the unit to correctly restart. But it doesn’t, it hangs. Just like on downloading assemblies.

Hence the question… what special stuff do we need to do to make software resets work 100% reliably?


Button Up, Center and Down. Plus MODE pin.

How come this isn’t done on the Cobra Gus, which we saw as an example board of using the EMX?

The only reference in the documentation I see to the Button pins is in section 5 where it says they can be high/unconnected.

We have them unconnected.

Are you using soft or hardware reset. in another word:




You need to use Microsoft.SPOT.Hardware.PowerState.RebootDevice(false); // Hardware reset.

Hi Joe,

We are using




So… we aren’t doing the reset. GHI is, when things go wrong. :slight_smile:

The other time is from Visual Studio. When you click ‘run’. The process there is the assemblies are loaded. Then the unit reboots.

(Debug Output Window shows:



Except the unit often requires (but not always), a press of the hardware reset line by hand to make the unit actually reset.

Connect the debugging interface through MFDeploy and check the debugging messages. and then when the Watchdog triggers the reset and it locks out, try to pin the device from MFDeply and see if it responds to the ping.

Another option is to make a software Watchdog ( a C# timer that resets the device) since the case you explained about PPP will not lock the whole system.


This post came up from another person


Note that we ARE disabling the ethernet oscillator… and it appears that this then causes the EMX to not start up properly after a s/w reset.

Is this a bootloader bug where you are expecting the ethernet to be active on power on, and when disabled from code, a reset causes this bug to show?


So of you enable the oscillator and reset if will work fine?

Are you using RLP? (I ask this because I have similar issues with the FEZ Cobra and still trying to figure it out)