W5100 Sometimes Won't Connect After FW Upload

I'm having persistent problems with W5100 shields on Dues. Most of the time, they work just fine. But, when I do a firmware upload, the W5100 somehow gets into a state where it seems to be just out to lunch, and nothing short of power-cycling gets it going again. I can repeatedly reset the Due, but the W5100 just sits there with only a single red LED lit. Everything else in the system works as expected, and this is happening on numerous different sets of hardware, so it appears there is something happening in the firmware upload process that puts the W5100 into a state it cannot recover from.

Anyone have any ideas what might be going on, or how to fix it?

Regards,
Ray L.

I never heard of the possibility to update the firmware on WizNet5100 chips. The datasheet says the protocols are hard-wired, so I wouldn't expect a firmware update routine. Do you have information about this? Can you post a link?

pylon:
I never heard of the possibility to update the firmware on WizNet5100 chips. The datasheet says the protocols are hard-wired, so I wouldn't expect a firmware update routine. Do you have information about this? Can you post a link?

You misunderstood. Not updating firmware on the W5100, but on the Due. Ethernet working fine. Upload new Due firmware, and W5100 no longer even attempts to connect to the network. Only a power cycle seems to get it working again. I've been seeing this for about tow years on countless different Dues and W5100 boards.

Regards,
Ray L.

Does that happen using either the native or programming USB port of the Due or just on one of them?

pylon:
Does that happen using either the native or programming USB port of the Due or just on one of them?

I only use the Programming Port.

Regards,
Ray L.

I cannot find any reason for such a behavior. Uploading a sketch over the Proramming Port does activate the erase pin and shortly later the reset pin on the SAM3AX. The processor enters the SAM.BA monitor after that (if it received a hash character on the serial interface) where the upload program sends commands to write the flash. I couldn't find information about what the SPI interface state is during this so it might be floating and picking up random signals.
The Ethernet Shield (I don't know what hardware you're using) is reset about 150ms after the processor (it has a special chip for that delay), so the freeze state may depend on the length of the sketch transfered because that might influence the time the pins are not in a defined state.

Does pushing the reset button on the shield also not show any reaction of the WizNet chip? That signal is connected to the reset controller and should hardly reset the chip the same as a power cycle would. If it doesn't I guess we have found a new hardware bug.

Unfortunately, the Due reset button is very hard to get at in my system. My impression is that in the past when I could reach it, it would get the Ethernet working again. My new hardware will put the W5100 reset under software control of the Due, and I plan to add some debugging functions to the firmware to try to determine what the W5100 state is when this happens, and to try re-initializing it without resetting the Due.

Regards,
Ray L.

Unfortunately, the Due reset button is very hard to get at in my system.

I thought about the reset button on the Ethernet shield not the Due. Although the effect should be comparable. I get the impression that you don't use an Arduino Ethernet shield but some other with the WizNet chip. Maybe it lacks the reset controller of the Ethernet shield which may be a reason for the behavior you experience. This little chip pulls the reset pin of the WizNet 5100 down about 150ms after the reset line of the Due came up again. This way the reset of the WizNet5100 is delayed compared to the Due which might be necessary.

pylon:
I thought about the reset button on the Ethernet shield not the Due. Although the effect should be comparable. I get the impression that you don't use an Arduino Ethernet shield but some other with the WizNet chip. Maybe it lacks the reset controller of the Ethernet shield which may be a reason for the behavior you experience. This little chip pulls the reset pin of the WizNet 5100 down about 150ms after the reset line of the Due came up again. This way the reset of the WizNet5100 is delayed compared to the Due which might be necessary.

No, I am using an Arduino Ethernet shield, it's just not mounted directly to the Due, but instead they are separately mounted to another board, with all connections as if they were simply plugged to each other.

I may be able to reach the Ethernet shield reset button. I will try that next time this happens. But won't that also reset the Due? They both pull down the same reset signal.

Regards,
Ray L.

But won't that also reset the Due? They both pull down the same reset signal.

Yes, unfortunately. You may fix that but that means hacking the hardware.

I thought that resetting the Due isn't a problem for you, at least that was my impression reading your first post.