Restored Connection With shard7

[shard7]

It should be possible to add some additional self-checking code in WiServer to make sure it balances malloc/free calls (or at least spit out an error message). The allocation calls are pretty solid for the normal operating modes, but I should review the code and make sure it covers all the strange exceptional cases that may occur from time to time.

[John_Ryan]

I had not seen that thread so thanks for the link Greg.

The sketch is for WiServer "web server", but in its present state it could be run as just server.

I've also run tests after rebooting the shield and all is fine, the return is consistently 394 bytes. So I'll implement the MemoryFree library and start a new batch of tests = )

[John_Ryan]

I just discovered my board isn't responding. It's been connected for about a week, and I've had it connected for weeks at a time in the past with no problems.

The weird thing is, the LED indicator is on.

I tried pinging the local IP addy and no response.

I've tried remotely accessing the board and no response.

So I've reset the board and it works fine again. But this is very concerning, I'm using a sketch that I've used for months and now suddenly the board appears to have locked up with the LED on?

[GregEigsti]

As a data point - this may not be a WiServer issue. In my issues where I have had to implement WiShield reset code I have the same symptoms that you are having. Board appears locked up and the connection light is lit. Might be a lower level WiShield driver issue.

Greg

[John_Ryan]

ummm... well, problems here and problems there all add up to one big problem of reliability.

I did modify the sketch to include g2100.h for RSSI so if there's a culprit then thats probably it .. but where to begin!!!

Maybe a watchdog timer, assuming that hasn't already been tried?

[GregEigsti]

Well you could remove your RSSI addition; but I doubt that is it (if you are doing no more than what spidermonkey04 and I have done) - pretty simple stuff.

Might try adding Serial.println()'s at crucial points to monitor the "state of the machine". Or what happens if you revert back to a clean/fresh distro of the AsyncLabs code off of GitHub.

Sorry that I don't have anything better for you

Greg

[John_Ryan]

The sketch without RSSI and g2100 works fine, I've had it running constantly for weeks at a time. Added RSSI and g2100 and flop, off it goes, this time its only lasted 2 days and I just discovered its locked up again.

But RSSI is another bit of information I'd like to be able to access from WiPiler, its a pretty handy piece of data. But the implication is that there's a problem with g2100, so anyone else using it on a sketch thats required to run for long periods will eventually hit exactly the same problem.

I could take it out, but thats just a temporary reprieve for g2100 and it's likely to become a mission critical issue for someone else further down the track.

So I'll try a clean fresh distro of the library's and see if that helps.

[GregEigsti]

g2100 has to be included at some point in the stack. I wonder if its the dual/multiple inclusion that is causing an issue.

Greg

[John_Ryan]

yeah that crossed my mind as well Greg, but if I take it out then I won't be able to use RSSI : (

I don't quite understand why it needs to be included in the sketch if its already being included in Wiserver.cpp

[GregEigsti]

Probably not being included in the "dependency chain" that the sketch is part of (e.g. included by files that the sketch does not include). Anyway and interesting experiment might be to include g2100.h but not call the RSSI stuff - just to see if having it included is causing a problem.

Greg