Teensy 3.1 with Wiznet WIZ820io crashes

Status
Not open for further replies.

CyberNick

Member
Hi,

I am trying Teensy 3.1 with the WIZ820io & Micro SD Card Adaptor, the WIZnet WIZ820io and the OctoWS2811 Adaptor.

Soldered together in a board stack, OctoWS2811 adapter on the bottom, then Teensy 3.1 then the WIZ820io adaptor and the WIZ820io on top. Teensy is powered through the +5V and GND pins on the OctoWS2811 adapter and the VIN and VUSB pads on the Teensy are cut apart. The power supply is providing 5.19 V measured at the pins on the OctoWS2811 adapter and it is rated for 100W or 20A. I power a LED strip from the same supply as well, the total draw of the strip should be 65 W when all of them are on on full intensity, which during the testing they never were because it's way too bright.

I have installed Arduino 1.0.6 and Teensyduino 1.20.

First noticed a problem with the example sketch called "ArtNet", included with the OctoWS2811 library. It would hang after 24 hours or so, sometimes shorter sometimes longer. I realized after some testing that it appears that the Teensy is not hung but the WizNet is, at least that's how I interpret not being able to ping the WIZ820io, but being able to reload the sketch and reboot Teensy without removing the power from it. The same problem happens on two separate but identical Teensy hardware setups.

I came across some problem reports with WIZ820io and WebServer, so I loaded the WebServer example from the Ethernet library and crashed it in short order by reloading the page several times with the F5 button on my PC. (Note that no LEDs were on during this test, so all the 20A power was available to Teesy.) The crash looked similar as the crash with "ArtNet" which took a long time to happen. It does not respond to ping, but reloading the sketch works.

Now I'm convinced that the problem is with the WIZ820io or the library that I'm using with it but I don't know how to solve it. Please help.
 
Is the Wiz820 powered from a 3v3 source other than Teensy's power? The current required exceeds what Teensy can provide.
 
No, I don't have additional power to the WIZ820io module. I didn't see in the documentation any mention of that and frankly I'm not sure how to go about doing that. I know I can get things such as 3.3V 800mA Linear Voltage Regulator - LD1117-3.3 TO-220 but I don't know how to add it to this setup. I need help with that.

I have a couple of other questions...

1. The power into Teensy in this setup is not from USB, it's through the pins from the board bellow and those pins continue up into the wiz820io adapter board as well so it's directly connected to the same 5v source as the Teensy. Does that mean that the WIZ820io adapter does not have a 5v to 3.3v regulator that can provide enough power? Or is that not the way it's powered?

2. How much power does the WIZ820io module need?
 
Looking at the image of the WIZ820io adapter it looks like it has a 3.3V regulator and two filter caps on board.
If you followed the online instructions for the assembly of the Adapter, you should be OK.

You could try to power the Teensy/Adapter combo separately from USB for a while to see if this still happens or if the freezes stop. Provided that it that the freezing does not happen so frequently, this may take several days to observe, but it's worth trying.

If the freezes go away then you may want to add some capacitance like a 470uF capacitor or more to the output of the power supply for some additional filtering. That is generally not a bad idea!
 
Last edited:
Even though I've never personally seen the WIZ820io crash, obscure software bugs are always a possibility...

I came across some problem reports with WIZ820io and WebServer, so I loaded the WebServer example from the Ethernet library and crashed it in short order by reloading the page several times with the F5 button on my PC.

Can you give me some more details, so I can try to recreate this test here?

Hardware: Does the crash happen when no LEDs are connected? If I just solder together a Teensy 3.1, Octo board, SD+Wiz820 adaptor and add a WIX820io, will that give me the same hardware you're using? Is a SD card in the socket (that could matter). Is *anything* else connected, even if it might seen unrelated?

Software: Are you running the example from File > Examples > Ethernet > WebServer without any changes? If anything has been edited, even seemingly unimportant changes, please let me know before I start.

PC: Windows or Linux, and which version / distro? Which browser? How rapidly are you hitting F5? Small details might matter.

I do have all the hardware here. WIX820 support is important, so if there's some software problem I've never seen yet, I really do want to find it. Please help fill in these details, so if there really is a software issue, I'll have the best chance of reproducing it here.
 
OK, so I tested again to remove some variables.

I disconnected the LED strips from the Octo board and from the power supply. So only the Octo + Teensy + Wiznet are attached to the power supply, measured 5.23V at the pins.

Here's a link to the power supply that I have: 100W 5V 20A switching power supply

I am using Windows 8.1 OS & Chrome browser. There is no card in the SD card slot.

The Octo and Teensy are soldered together with 2 x 14 pin double headers, octo on the bottom and long side of the pins pointing up, the WizNet adapter has 2 x 14 pin sockets soldered to it and plugs in to the headers protruding up from the Teensy. I have two versions of the way the Wiznet is soldered, one the pins are trimmed and it's flush as in the instructions and one it's raised about 5 mm up and there is an air gap between the two boards. Both versions crash the same.

Loaded the example sketch from File > Examples > Ethernet > WebServer, modified the IP address to 192,168,3,21. Loaded the sketch on the Teensy and opened the serial monitor. Opened a new tab on Chrome browser went to the address http://192.168.3.21/ hit enter, saw the web page. Hit F5 about 2 times per second for 20 or so seconds, appeared to be OK. Just held F5 down for 2 seconds and crash happened. Repeated it several times and appears it doesn't crash until I just hold it down briefly.
 
Last edited:
Hey Paul,

I am wondering if you were successful in reproducing the Wiz820io crash? I am still experiencing this problem. With the Artnet example from the OctoWS2811 library it usually takes a long time, but crashes in a very similar way as what I've described above. Is it a stupid mistake that I'm making that does not deserve an answer???

Thanks,
Nick
 
I'm still having this problem.

I have a new power supply (MeanWell RSP-320-5) delivering 5.05 V to the Teensy, measured at the pins.

Still crashing. Crashing after 24 hours or so (sometimes much sooner and sometimes much later) with the LED strips connected and the ArtNet example running accepting data from Jinx!. And also crashing in short order with just the Tensy, octows2801, wiznet adapter and wiznet stack of boards with nothing but network cable attached and running the example WebServer. Basically everything as described above, now with a better power supply.... no change.
 
@Paul, I'm at a loss as to why my setup is crashing and am wondering if you've had the chance to look into this problem, if not, please try to make some time for it soon.

Thanks,
Nick
 
@Paul, I'm at a loss as to why my setup is crashing and am wondering if you've had the chance to look into this problem, if not, please try to make some time for it soon.

Thanks,
Nick
I re-read this thread but an still not sure you are powering the Wiznet from other than the 3.3V from the Teensy.
 
I don't understand why the Wiz820io keeps crashing... I need help.

I suppose a workaround might be to reset the Wiz820io, but I'm not sure how to test from my sketch if it needs a reset. Any suggestions?

And I need to do a bit of hardware modification to the WIZ820io & Micro SD Card Adaptor:

... the pads can be cut apart and the left+center joined to allow pin 8 to control the WIZ820io powerdown feature.
 
I used the predecessor WizNet 812MJ. On an ARM7. My own driver. After my test/debugging, I had 100 of these running without hanging or deadlocking. I didn't use its reset.

No other SPI device in use?
 
IIRC the WIZ820io actually needs to be reset after startup. Paul recognized this early on when integrating it into the Ethernet library and pulling down its reset line is part of the libraries intialization code.
 
I have found a hint on the problem:

everytime you want to call client.stop(); in the EthernetClient.cpp disconnect(_sock); is called even if status() == SnSR::CLOSED

but if I tried to add this condition into a if-clause it still hang up.

I don't know if there is something in the following (i havn't tried)

EthernetClass::_server_port[_sock] = 0;
_sock = MAX_SOCK_NUM;

I just fixed problem when I try to call the stop function:

if(client.status()!= 0) client.stop();
else {
Ethernet.begin(mac, ip);
}

maybe it works because of W5100.init(); is called in begin(); and in the init() there pulls down the reset pin from wiz820io

If anyone had found out better idea - please let me know.

I guess the problem is caused because at some time the socket number is not called correctly if requests come too fast. And maybe if you send a W5100.execCmdSn(s, Sock_DISCON); to a socket which is closed the module crashes.
 
Last edited:
I guess the problem is caused because at some time the socket number is not called correctly if requests come too fast. And maybe if you send a W5100.execCmdSn(s, Sock_DISCON); to a socket which is closed the module crashes.

Bringing this thread back to life because it still seems to be an issue. If I have a single TCP socket open with continuous communication (about 1 - 6 byte recv a second) the WIZ820io/W5100 module will crash, and stop responding to all communication (no ping, no TCP connect). The Teensy module itself stays alive and I can send a serial command through the USB interface to pull the reset pin on the W5100 to bring it back to life. For me it usually happens in 1-4 hours.

If I stick to UDP communcation, no issue. Edit: scratch that, it happens with straight UDP as well even without active communication.

I can post repro code if that is helpful.
 
Last edited:
The problem is still present yes, I have this on almost all my projects that rely on Ethernet. I've 'circumvented' it by implementing retries and a reset of the Wiznet when the retries don't work.
 
Is there an error that you noticed that you can pick up? I'm basically calling udpSocket.parsePacket() and tcpServer.available() to see if there is anything to read.

In my case the Teensy is acting as a receiver so it might be normal to not receive any communication for a period of time, although it will keep polling to see if there is any data to be read.
 
Mine is acting as a client. I suspected something with the sockets too, maybe the Wiznet running out of available sockets. I used readSnDPORT() to check which sockets were connected, but turned out the Wiznet only used one socket like it had to. I didn't look into it any further because the retry/reset workaround worked well enough for my application.

The long term stability of the Ethernet lib remains an issue imo. I sometimes get out-of-control clients too: they get stuck in a loop sending the same data over and over. But this happens only so sporadically I haven't made the time figuring this one out.
 
I wrote some client server repro code that brings the WIZ to its knees in about 2 seconds. Once I get that all cleaned up I'll start a new thread and maybe someone can figure out what is going on.
 
Mine is acting as a client. I suspected something with the sockets too, maybe the Wiznet running out of available sockets. I used readSnDPORT() to check which sockets were connected, but turned out the Wiznet only used one socket like it had to. I didn't look into it any further because the retry/reset workaround worked well enough for my application.

The long term stability of the Ethernet lib remains an issue imo. I sometimes get out-of-control clients too: they get stuck in a loop sending the same data over and over. But this happens only so sporadically I haven't made the time figuring this one out.

Are you using DHCP? There are issues with that, I think related to the known ARP bug in the W5200 used in the 820io. I've configured a router for the min DHCP lease time of 120 seconds which allows the Wiz820io to renew every 60 seconds. This compresses a year of renewals into 24 hours. I see failures and have written code to work around them. Teensy doesn't hang but the Wiz820io gets unresponsive and can't even be pinged. DHCP renewal fails so then it can't communicate on the Ethernet. I've been capturing Ethernet with WireShark and also capturing SPI cycles with a Beagle probe.

We're laying out a new test board with patterns for the Wiz820io and also the Wix550io which is not a drop-in, sadly, though it doesn't have the known 820io bugs and is also cheaper. I'm back on this issue this week since we have to get reliable Ethernet working on a commercial product.

[Update] There is a new WIZ850io (using W5500 chip) which IS a hardware drop-in for the WIZ820io (using W5200 chip) fooptrint. However the reset timing (500 usec for W550 vs 2 usec for W5200) and other firmware is different. The WIZ550io is not recommended for new designs, the WIZ850io is. We just got some in and also a new board back on which we plan to use the WIZ550io module.

Bruce
 
Last edited:
Are you using DHCP? There are issues with that, I think related to the known ARP bug in the W5200 used in the 820io.
I use DHCP yes, and the behavior is indeed as you described.

So the Wiz550io doesn't have this issue? I've switched some of my applications over to this board because it's cheaper, so this could be a nice extra :) .
 
Are you using DHCP?
Bruce

During this test I was actually static to rule out any issues with lease.

I rewrote the code to work around a few issues and it stayed up overnight so that's a good start. Here's a list of problems I found, some where my own creation to some degree.

- I was calling client.available() in a loop and reading 1 byte at a time off the stream. This seems to cause W5200 lockup issues somehow, so now after I call client.available() I read however many bytes it said were available (1 byte at a time is still ok) before calling client.available() again.

- During writing a test for the above I found that if you attempt to read more bytes than are available it happily complies, and client.available() wraps negatively and becomes a high value unsigned short (in the 65000 range). This causes a pretty immediate W5200 lockup. This might just be a performance vs safety thing where the bounds check was removed for performance.

- Polling UDP sockets, even if they aren't receiving data, seems to eventually lead to a W5200 lockup. I haven't got to the bottom of this one yet, but it might be a resource issue. In my original design I was using 4 server sockets, 2 TCP, and 2 UDP and for right now I have this cut down to 1 TCP.

- The last issue is related to the way that Arduino handles client sockets returns from the server object and was mostly a misunderstanding on my part based on weak samples from arduino.cc. When the client object is returned from server.available() you have to keep that object in scope otherwise there is no way to detect disconnects and no way to dispose of the client socket if they do disconnect. This makes the main loop code a bit weird but easy enough for a single client.

Edit: With the revised code it survived 12 hours of running before pooping out. Improved, but not exactly stable.

Bruce, looking forward to how you make out with the W5500.
 
Last edited:
Here is also crashing. Usually takes hours or a day, I tough the problem was related to the example of octoWS2812, but seeing that other people has problems with other sketches makes me think the problem resides in the ethernet library or maybe a power faliure? I will keep digging.

I am using Teensy 3.2 with the WIZ820io & Micro SD Card Adaptor, the WIZnet WIZ820io and the OctoWS2811 Adaptor. I'm not using DHCP.
 
Status
Not open for further replies.
Back
Top