Hydra FW crashes with

My latest incident was an application that DOES set network criteria in code, and ran for weeks, then when rebooted it bricked. I can easily replicate this, and have found that aborting the thread reduces (but not eliminates) the chances of this happening.

Right now I am bricked, so I can’t replicate anything at the moment.

Once I get unbricked I will try more tests without any Ethernet code to see what I can make happen. Though this still shouldn’t happen even with setting Ethernet, shoudl it?

using System;
using System.Threading;

using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;

using GHI.Hardware.FEZHydra;

namespace Hydra_Console_Ethernet_Forum_Test
    public class Program
        public static void Main()
            OutputPort Socket5Pin9_PA24 = new OutputPort(Pin.PA24, false);

            while (true)


Using the above code, I reset the board 100 times and there does not seem to be an issue.

The Hydra in this test is using the latest Ethernet firmware (, ENC28 module connected to socket 3, LED7R connected to socket 5, and only powered by PD module with external power connected.

If you will please, try to run this test to see if the same issue will happen.

The test was to deploy the program, then reset the board. I waited until the LED blinked again before resetting it.

Have you tried any testing without a DP and just using the USB input for power? It was stated that even power issues shouldn’t cause these symptoms, but I don’t have a compatible 12v power adapter to use and the USB seems to power it just fine and my usb wart is capable of 2A.

I Just repeated the test with a DP module but only powered by the PC, no external power or USB hub. The test is still not failing. I am able to reset the board and the device is not being corrupted.

I am researching the issue. There are some issues of data corruption using that particular chip. Nothing specific, but check this one:


Read section “Problems”. I wonder if slowing SPI will help as it helped them.

@ Architect - but according to some posts, the see the issue without writing to flash, which should be impossible.

What if we just chase down when something is written to flash? There is confirmation that it happens when the only thing written to flash is IP settings, and it seems to me that it shouldn’t happen even then.

I wonder if floating WP pin can be an issue here.

In my case the issue not reproduced when not writing to flash.

I just bricked again while trying to deploy my project. It did not finish and did not startup my project.

Ok, newest firmware is doing better, I haven’t bricked board #1. Board #2 only bricked back to the boot loader, but I never got to verify that it had the newest firmware. I now have the newest firmware on it and it seems to be doing fine with the resets.

Helping will be very difficult if we are on the same page. We agreed to try this with latest firmware already. Now I see you have jus uploaded the latest firmware?

I spoke to soon as it just bricked on me. I unplugged it from my wall-wart micro-USB plug and then plugged into my laptop to update new code, and when I plugged in it said unrecognized device and my app is not loading as it should when it gets power.

I always tried with latest firmware. You can check DeviceInfo from my first thread.
IMO LED blinking only test definitely points on flash writing issue.
Since I started device testing without flash writing I never had FW crash (brick).
Hydra passed about 80 iterations of reboot and LED blinking and about 40 iteration of
more heavy tests of heavy network traffic and reboot.
The part of reboot were performed using MFDeploy command line and others using reboot button.
Hydra was connected to PC using USB cable.
Just to compare the same test with flash writing (by setting static address to NIC) failed after 15-18 iterations.
I would suggest to concentrate on flash writing issue.

The MFDeploy lost connection to Hydra from time to time and I had to use button for reboot, but this was much less painful than making FWUpdate.

This makes more sense. The problem can only happen when writing to flash.

The next question is, does it happen worth the non ethernet firmware. I think this is related to the ethernet firmware only.

So, can someone confirm this, repeatedly?