Hello:
I am having some trouble with the SD demo application. I have the Web Platform 1.1. By following the instructions in the Readme file, I have gotten the web-platform-SDcardServer.v0a to build successfully.
I installed a 4G microSD card (formatted with SDFormatter). When I download my hex file, the server acquires an IP address properly and I can ping it just fine. Unfortunately, I get nothing when I try to access the server from a browser, and then it just seems to hang (I can no longer ping the board).
I saw the remarks here: http://dangerousprototypes.com/docs/SD_ ... erver_demo (http://dangerousprototypes.com/docs/SD_card_web_server_demo), where changes to 'enc28j60.c' are discussed to avoid lockups. I mechanized the "more correct" fix by adding the 9 NOP's, but it still behaves the same way.
I am probably doing something dumb... Any recommendations?
-Thanks
Did you try one or both of the "less correct" fixes detailed on that page? If not give them a go and let us know what happens :)
Trev:
Change #1 -- same symptoms
Change #2 -- same symptoms
Change #3 -- same symptoms
All of the above (Change #1 + Change #2 + Change #3) -- same symptoms
-Tom
:-(
When it stops responding to pings is the heartbeat LED still blinking? The answer might help locating the issue.
I went back to the baseline, with only the "preferred" change adding the 9 NOP's (seems mundane enough)...
After a reset, the heartbeat LED is blinking fine, and it pings OK. As soon as I try to access the HTTP server, it hangs and the heartbeat LED stops blinking.
I guess it's time for the debugger... I have an [ancient] homemade PIC programmer (parallel port). I am hoping it is compatible with the ICSP connector (and the modern MPLAB)...
As described here http://dangerousprototypes.com/forum/in ... opic=460.0 (http://dangerousprototypes.com/forum/index.php?topic=460.0) setting MAX_HTTP_CONNECTIONS = 1 improves the situation, although it does not solve the problem entirely as described towards the end of the referred thread.
@Markus
I don't think the MAX_HTTP_CONNECTIONS setting has any influence over whether the PIC locks up.
@diviney
You are entering uncharted territory. The "fixes" I documented in the Wiki have never failed to resolve the lockup issue until now. I'm wondering whether it's significant that you're using the v1.1 hardware. BTW, what version of the TCP/IP stack are you using? The fixes related to 5.20b.
Interesting thought...
I am using v5.31 (Dated 19 October 2010)
You might want to run up the v5.20b stack available from http://www.microchip.com/stellent/idcpl ... odeId=2896 (http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2896) and see if the issue remains.
Well, I tried again with the v5.20b stack.
Still no luck, in fact it seems worse.
Now, after a reset, the heartbeat only blinks anywhere from 1 to 3 times before it hangs. With the 5.31 stack, the heartbeat (and ping) would run fine until I tried to access a web page. If I try hard enough, I can catch a ping before the board hangs after the 1-3 blinks.
I tried the various fixes including the Nop()'s. No different.
Is there a way you can send me a known good HEX file that works with an SDHC card?
I'm pretty sure the board is OK because it runs perfectly with the non-SD Card build (MPFS files, on-board memory).
-Tom
I'm more tempted to send you one of my known good working v1c web platforms, but I guess you're up over (versus downunder :)
I've attached a known good HEX file for the SD server with 4Gb micro-SDHC card. It has debugging output via USB for the page/file being requested (115200) and will echo any characters typed, but is otherwise the original with the ethernet reliability mods added. It's been running non-stop for several months with nary an issue (shadow.sentry.org on port 81).
I wait with baited breath...
By your words I am kind of stuck up over - actually pretty precisely on the opposite site of the globe. Not sure if it's the internet connection, too many folks trying to connect to your web platform after you posted the link or a greneral flaw in the Microchip TCP/IP example ... out of three times I try to toggle a LED or push a button I get two "connection to demo board was lost" messages. I hope no smoke is rising from your board due to my excessive connection attempts ...
Seriously, I doubt that any of the web platform ports of the original Microchip TCP/IP Stack Application Demo work stable (regardless if web platform v1c or v1.1) when under load. I've tried it on both web platform versions with different versions of the stack and the results were not very satisfying when opening multiple connections. Someone with more free time than I have atm may want to take look at the timers/interrupts ...
[quote author="Trev"]
... It's been running non-stop for several months with nary an issue (shadow.sentry.org on port 81).
I wait with baited breath...[/quote]
[quote author="IPenguin"]
By your words I am kind of stuck up over - actually pretty precisely on the opposite site of the globe. Not sure if it's the internet connection, too many folks trying to connect to your web platform after you posted the link or a greneral flaw in the Microchip TCP/IP example ... out of three times I try to toggle a LED or bush a button I get two "connection to demo board was lost" messages. I hope no smoke is rising from your board due to my excessive connection attempts ...[/quote]
No smoke :) I did notice the relays going (the LEDs indicate relays on/off). It's more likely to be a bandwidth issue as my upstream is "Oct 13 22:17:10 router-3 DSL: Link up 28 US 997 DS 14056 (INTL:ADSL2+)", yep, just 997bps. I might also have to blame my wife who's playing with her shiny new iPod Touch's web browser at the moment on the same link ;)
Seriously, I doubt that any of the web platform ports of the original Microchip TCP/IP Stack Application Demo work stable (regardless if web platform v1c or v1.1) when under load. I've tried it on both web platform versions with different versions of the stack and the results were not very satisfying when opening multiple connections.
I benchmarked it with 2 concurrent connections configured and hit it with 4 concurrent connections (see the stats http://dangerousprototypes.com/forum/in ... 71#msg4271 (http://dangerousprototypes.com/forum/index.php?topic=460.msg4271#msg4271)) and it was perfectly stable after adding the lockup fix.
Accessing the same port 81 device from the university where I work rarely suffers from any timeouts except when the university is experiencing a DOS attack on its AARNet gateway (usually from within its own network) or someone is saturating my link with downloads from my real website on the same link.
When I tried again later it performed much better. :)
Thanks for the link to the benchmarks. They are pretty much in line with what I experienced when I tried the demo in May or so.
Since I had no intention to use HTML nor any other TCP based protocol on the web platform I never tried to see if there is a way
to improve the performance of the TCP/IP Stack Application Demo. Once bonybrown got uIP running (http://http://dangerousprototypes.com/forum/index.php?topic=605.0) I went off into UDP territory
and have been happy with the web platform ever since! :)
Trev:
Thank you for posting the HEX file... I find the results interesting (although perplexing).
Your hex file at least seems "stable". When I flash it, the heartbeat is perpetually good. I can ping the board just fine. When I attempt to access the http server, I get no response, but the board remains up and running just fine. The heartbeat continues and I can still ping it after an un-responsive web page request. You mentioned the debugging output... This may yield a clue as to where my problem is. If I look at the USB serial port at 115K, it does indeed echo any character that I type. It does NOT however show anything else. When I try to access a web page on the SD card, the browser gets no response and times out. There is nothing shown on the serial port either. It is as though the http request is just not being received. As you mention, the serial port should show the page / file being requested? For some reason it does not.
WAIT --- Something else that was said in passing triggered a thought --- It was mentioned that your server is running on Port 81. Maybe this should have been obvious, but I was just letting the port default. When I try Port 81, your build works fine !!! And, it does indeed echo the file request via USB !!!
Still doesn't explain why I can't seem to get a good build myself, but proves my hardware is OK.
-Tom
[quote author="diviney"]
WAIT --- Something else that was said in passing triggered a thought --- It was mentioned that your server is running on Port 81. Maybe this should have been obvious, but I was just letting the port default. When I try Port 81, your build works fine !!! And, it does indeed echo the file request via USB !!!
[/quote]
Excellent news.
Still doesn't explain why I can't seem to get a good build myself, but proves my hardware is OK.
Indeed that is strange - I was almost convinced it was a hardware issue. Let me know if you want the source for the HEX file.
Trev:
One more time... I tried to build the SD application. Here are my exact steps:
1. Downloaded and installed Microchip Applications Library (MCHP_App_ Lib v2010_02_09_Installer).
This contains the 5.20 version of the TCP/IP stack.
2. Made a working copy of the C:Microchip SolutionsTCPIP MDD Demo App directory tree.
3. Took these 6 files:
Maindemo.c/.h, HardwareProfile.h, TCPIPConfig.h, TCPIP MDD SD Card Demo App-C30.mcw/.mcp
contained here: web-platform-SDcardServer.v0a, and replaced them in the working "TCPIP MDD Demo App" folder
4. Opened the project and "Build All" -- (MPLAB v8.60), no errors
Resulting HEX file runs, pings, but hangs upon receipt of first web request.
5. Added the 9 Nop()'s in the WriteReg function of ENC28J60.c after Dummy = ENC_SSPBUF;
Resulting HEX file runs, pings, but hangs upon receipt of first web request.
My hexfiles are attached (without and with the Nop()'s ). Maybe you could give them a try. This is very frustrating.
-Tom
Have downloaded and will let you know later tonight, time permitting.
OK, I've tested the HEX files. You're right - the web platform pings ok, but hangs almost as soon as you send it an http request. Bizarre!
Going back over my previous posts on the topic, I came across this one http://dangerousprototypes.com/forum/in ... opic=475.0 (http://dangerousprototypes.com/forum/index.php?topic=475.0) where I mention curing lockups by removing another line from the source. You might want to try that.
Trev:
Per your suggestion, I made the following changes (to TCPIPConfig.h)...
1. Changed MAX_HTTP_CONNECTIONS from 2 to 4
2. Got rid of 2nd one of these: {TCP_PURPOSE_HTTP_SERVER, TCP_ETH_RAM, 200, 200}
3. Changed MAX_MPFS_HANDLES from 0x07 to 0x09
Same story with a slight twist... It pings, then when I try to access a page it hangs (heartbeat stops). After a LONG time (maybe 20 seconds), a web page from the SD card pops up in the browser. Everything is still hung though (no pings, no further activity with web pages, nothing).
-Tom
See email...