This project is read-only.

Gathering data from service needs device restart

May 15, 2014 at 8:51 PM
Edited May 15, 2014 at 9:16 PM
Sometimes reading data from sensor stops working and turning off and on the device from the power seems to solve the problem (Gadgeteer low budget device problem?). Clicking the small button placed on the FEZSpider mainframe helps, too! It seems that the problem occurs when I have got gadgeets working and I try to refresh the service from the browser (be pressing F5 at the address http://192.168.0.10/temperature).

At the end of that message there is a part of log, when at the end my device finally stops. BUT as you can see everything was working pretty much well (for about 5minutes of testing) to the moment when I started to refreshing the data (and sending web events), when I crashed the program aftrer about a 45sec.

The VS Debuger stopped at that moment, BUT I could restart the device (by clicking small button at the Gadgeteer SpiderMainframe) - the service started to work as previusly (in the browser), but VS didn't print anything else (I assume device was working without the debugger, just in the net).


I also changed the SpiderBoard to other, deployed the solution and....I was able to reproduce the problem (quick refreshing the service just make it quicker to crush). This time my VS stopped without any exceptions in log. Now I am a little bit confused, because I wasn't able to reproduce that to my other device (LightSensor). Is it a problem with both of my SpiderMainframes or (more probably) with Temp&Humidity hardware sensor or with the software?

(In both cases, that is this mail and earlier one, I didn't engaged the Platform solution. Everything was just tested on AllDevices.sln Gadgeteer, and every mainframe is just in 1.0 version, it if helps in anything)...



Part of the LOG of my VS that prints messages when I refresh in a browser and it crases:

"HomeOSGadgeteerDevice_TempHumiditySensor_MicrosoftResearch_48442029061122239447", }
Accepted connection from 192.168.0.15:16013
Accepted connection from 192.168.0.15:16014
Accepted connection from 192.168.0.15:16015
wifiTimer start - currentAP UPC0047455 wifiUp True IP 192.168.0.10
wifiTimer end - currentAP UPC0047455 wifiUp True
{"temperature" : 22.170000000000002
"DeviceIP" : "192.168.0.10", "DeviceId" : "HomeOSGadgeteerDevice_TempHumiditySensor_MicrosoftResearch_48442029061122239447", }
Accepted connection from 192.168.0.15:16016
Accepted connection from 192.168.0.15:16017
Accepted connection from 192.168.0.15:16018
{"temperature" : 22.149999999999999
"DeviceIP" : "192.168.0.10", "DeviceId" : "HomeOSGadgeteerDevice_TempHumiditySensor_MicrosoftResearch_48442029061122239447", }
The thread '<No Name>' (0x2a) has exited with code 0 (0x0).
Temp&Humidity web event from 192.168.0.15:16013 - response {"temperature" : 22.149999999999999
"DeviceIP" : "192.168.0.10", "DeviceId" : "HomeOSGadgeteerDevice_TempHumiditySensor_MicrosoftResearch_48442029061122239447", }
Accepted connection from 192.168.0.15:16019
The thread '<No Name>' (0x2b) has exited with code 0 (0x0).
Temp&Humidity web event from 192.168.0.15:16014 - response {"temperature" : 22.149999999999999
"DeviceIP" : "192.168.0.10", "DeviceId" : "HomeOSGadgeteerDevice_TempHumiditySensor_MicrosoftResearch_48442029061122239447", }
Accepted connection from 192.168.0.15:16020
#### Exception System.Net.Sockets.SocketException - CLR_E_FAIL (1) ####
#### Message:
#### Microsoft.SPOT.Net.SocketNative::send [IP: 0000] ####
#### System.Net.Sockets.Socket::Send [IP: 0018] ####
#### HomeOSGadgeteer.Networking.Responder::SendResponse [IP: 01a1] ####
#### HomeOSGadgeteer.Networking.Responder::Respond [IP: 0036] ####
#### HomeOSGadgeteer.Networking.WebEvent::OnWebEventReceived [IP: 006c] ####
#### System.Reflection.MethodBase::Invoke [IP: 0000] ####
#### Gadgeteer.Program::DoOperation [IP: 001a] ####
#### Microsoft.SPOT.Dispatcher::PushFrameImpl [IP: 0054] ####
#### Microsoft.SPOT.Dispatcher::PushFrame [IP: 001a] ####
#### Microsoft.SPOT.Dispatcher::Run [IP: 0006] ####
#### Gadgeteer.Program::Run [IP: 0020] ####
#### SocketException ErrorCode = 10054
Accepted connection from 192.168.0.15:16021
#### SocketException ErrorCode = 10054
A first chance exception of type 'System.Net.Sockets.SocketException' occurred in Microsoft.SPOT.Net.dll
Accepted connection from 192.168.0.15:16022
Accepted connection from 192.168.0.15:16023
#### SocketException ErrorCode = 10054
#### SocketException ErrorCode = 10054
Exception sending web event response (connection was probably terminated)
The thread '<No Name>' (0x2c) has exited with code 0 (0x0).
The thread '<No Name>' (0x2d) has exited with code 0 (0x0).
wifiTimer start - currentAP UPC0047455 wifiUp True IP 192.168.0.10


What can be a problem?
May 15, 2014 at 8:54 PM
Edited Jun 8, 2014 at 6:37 PM
James Scott gave a tip:

"It looks like it could be something like you’re maxing out the number of sockets that can be open at any one time. Can you check if this might be the case and throttle it?"

and thanks a lot for a concern - but how can I check it?

EDIT: (another answer):

"After looking at your code, I don't think its an issue with holding onto sockets. It may be an issue in the WiFI driver from GHI, or in the NETMF networking code. I do not have a solution for you (more investigation and debugging would be necessary for the above problems) but I can propose two workarounds:

1) don't give it so many requests in parallel

2) implement a watchdog timer in the Gadgeteer code, e.g. a separate thread which wakes every so often to see if the wifi stack is working and if not resets the device automatically. One way of determining if the wifi stack is working is if incoming requests are received e.g. at least once every 30s (this could increment a counter which could be checked). Another way would be to find a call that throws an exception once it is in a bad state, which normally does not throw an exception, and call that in the watchdog timer thread."
Jun 8, 2014 at 6:49 PM
Edited Jun 8, 2014 at 6:50 PM
Hi,

thanks for the support.

Finally, my problems have been solved after updating the wifi driver! One time trying to test that issue again I got a blue screen:
"rtwlanu.sys DRIVER_IRQL_NOT_LESS_OR_EQUAL"
and followed the problem description in the internet. It seems that after updating from Windows 8 to Windows 8.1 the Wifi driver didn't update automatically and I had "1025.1.423.2013 Realtek" version while there was newer: "1026.4.1023.2013".
The solution for it I found here:
http://cogitoabsurdum.wordpress.com/2013/12/13/lenovo-yoga-13-fixes-10-update-wifi-drivers-from-windows-update-fixes-wifi-problems-for-most/

Cheers,
Kamil
Marked as answer by kamilhawdziejuk on 6/8/2014 at 11:45 AM
Aug 8, 2014 at 10:43 PM
Edited Aug 8, 2014 at 10:44 PM
James, in reference to your ast tips about "reseting the device automatically" - could you write how to do it programatically?

It seems that my problems came back so I added that code to HomeOSGadgeteerDevice.cs:
     public void Reset(string ip, int port)
    {
        WebServer.StopLocalServer();
        wifi.Interface.Disconnect();
        wifi.Interface.Join(currentAP, wifiPassword);
        WebServer.StartLocalServer(ip, port);
    }
and used it periodically in Program.cs by firing:
hgd.Reset("192.168.0.12",80)
but it doesn't help.
Aug 11, 2014 at 9:09 AM
Kamil,

The call you want is simply:
 Reboot(); 
from within a Gadgeteer main Program class (this is a helper method implemented in the base class). This should be equivalent to pushing the reset button.

Underlying that, this calls:
Microsoft.SPOT.Hardware.PowerState.RebootDevice(false);
which you can call from anywhere as it is a static method.

Ta
James
Marked as answer by kamilhawdziejuk on 8/11/2014 at 1:20 PM
Aug 11, 2014 at 9:20 PM
Edited Aug 11, 2014 at 9:22 PM
I tried
Microsoft.SPOT.Hardware.PowerState.RebootDevice(false);
just before, but I got some strange exceptions (like I was referencing wrong version of dll, but I didn't) and it didn't work.

However Reboot() is just what I was looking for;)
Thanks again, it works!