Weird Intermittent reset problem on EB023 (TCP/IP module)

[eeedelli]

Hi all,

The last time I played properly with micros was about 25 years ago, with Z80s and long before the internet, so I am ‘rather rusty’! Flowcode seems great compared with having to do everything in C or assembler (or even hex, as I sometimes used to do it in the ‘good old days’!), though the bewildering array of registers in an 16F877A compared to an 8085 or Z80 would take some getting used to!

Anyway, over the last couple of days, I’ve been having a play with some e-blocks that I got a couple of months ago as I have only just got a new laptop which I wanted to act as a host.

Having written a few test progs for LEDs, switches, LCD etc, which seemed fine, I’ve moved on to the EB023 TCP/IP module. I’ve loaded up the test programme for TCP_IP sending. All I had to do was modify the IP address and gateway to match my own LAN subnet address. Instead of using a crossover cable (which I don’t have to hand), I’ve just plugged it into my firewall router. It appears to work, generating the blue web page saying ‘hello world’, asking how I am and generating the page refresh number.

However, I’m getting some odd random behaviour of the Wiznet module. The scenario is as follows:
The test PC is at 192.168.2.15 (“Goliath”)
The router/gateway is at 192.168.2.1 (“router”)
There is a linux machine (“Linux1”) at 192.168.2.14
The e-block unit is at 192.168.2.20

I have taken the precaution of adding 192.168.2.20 to the trusted zone in the zone alarm firewall on Goliath (which, in theory, is not needed since there is a hardware firewall in the router but, just in case I end up stupidly plugging something insecure into the 'cool' side of the router, I’ve left it there). Dropping Zone Alarm off doesn’t seem to help anyway. Access to internet and the usual programmes on Goliath remains normal.

When powering up the e-block, the LCD correctly shows the initialising message and the blue webpage comes up ok when the IP address for the e-block is keyed in to the URL window in the browser. Pressing F5 causes the LCD to show the ‘sending HTML’ message and the page counter onscreen increments as it should. However, after a random time, pressing F5 results in a ‘connection refused’ message at the browser.

I’ve had Wireshark running and can observe that the e-block appears to get stuck in a mode where it merely sends resets as soon as anything tries to send a Syn to it to initiate comms. This appears to happen randomly after any other comms on the LAN (i.e. that's what seems to cause it but it doesn't always do it). However, the e-block will happily bounce pings back without any problem even when it's not co-operating. I’ve had a scope on the SDA, SCK and INT pins on the EB023 and they’re quite happily toggling up and down once per second as normal but the LCD fails to display any request so is, presumably, not receiving any useful incoming data from the Wiznet module.

The only way to rectify the problem is by hitting the MCLR button on the EB006 programmer board, whereupon all is well … until the next time it happens!

Assuming I’ve remembered to attach them, there are three versions of Wireshark (formerly Eathereal) test files which show the problem occurring. As you will see, it is sometimes possible to have other comms on the LAN without crashing the Wiznet module. There are also some occasions on which it tries to duplicate an ACK. In fact, earlier today, I observed it stuck in a loop where it was doing just that repeatedly in response to an F5 of the browser, which was only killed by my hitting ‘stop’ in the browser window (after which it was in sulk mode requiring the EB006 to be reset again).

As there doesn’t seem to be any way of controlling the Wiznet module (which is the whole point of it – plug and play!), is this indicative of a fault in that module itself?

Any ideas anyone?

[Benj]

Hello

I've not come across the Wiznet module acting like this so it could be a malfunctioning Wiznet module. It may be possible to edit the software to get around this. Eg if the Wiznet has not responded in a long time then recall the initialise function. Or try including the initialise function in your main loop to see if this gets around the problem.

Let us know how you get on.