I have a FEZ Cobra unit with V4.1 SDK in operation at a customer site. Principally there the Cobra runs a webserver on top (using HTTPListener) and controls digial IOs below. Now, I have been having this nagging problem that the unit is not reachable over network after having worked for 2-3 weeks. Rebooting the unit brings the it back on the network (uses static IP address). I know,much has happened in the GHI world ever since, and I am wondering if there was some issue with the firmware that could be causing this issue. Is there a chance that migrating to the the SDK v4.2 would solve the problem? I realize this could be kind of vague without specific code and debug info… (can I attach a zip of the source code to the post?). Thanks for any pointers! Cheers.
There’s a lot of change in 4.2 around network stack, and my personal suggestion is that you probably will introduce more turbulence than solve if you head down that path.
Sharing a project file to help troubleshooting is probably not going to be overly helpful I’d expect - it’s likely that nobody will have the same firmware as you do just sitting around or ready to go. My suggestion is diagnostic logging in the app, logging to the SD card, and see what that gets you. I think there are probably many people who have similarly configured apps that have not shown any kind of network issue, on 4.1 on EMX, so I suspect you’re going to need to capture info from an unhandled exception or something… but come morning US time there’ll be a whole swag of other brains to peruse your problem and you may get some other great ideas then.
Hi Brett, thanks for your reply.I tried logging information from the application - there was no exception (handled / unhandled). The board seemed to stop responding on the network (with wireshark I could see the icmp message, but no response). The code was waiting on HttpListener.GetContext. I am now going to attach a PC with usb cable and have the code running in debug mode.
@ rganesh - Are you using TimeService() api on the board ? Be carefully that if the NTP primary server doesn’t respond, it lock in the start forever. But in my case the EMX was ICMP pingable.
dobova, thanks for the suggestion. I do not have TimeService in use, so that rules out one possible reason.
I am preparing a laptop with development environment on it so that I can connect via USB and leave it running in debug mode. Although, I am not sure what I would do when the device does stop responding on network - is there some way to dump the entire stack and heap content for analysis? I am also going to keep wireshark running with filter set to the ipaddress of the device (again, not sure what that will bring). Kind of lost here …