Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WiFiSocketClass::connect gets stuck at handle events #250

Closed
axelbusch opened this issue Oct 10, 2018 · 7 comments
Closed

WiFiSocketClass::connect gets stuck at handle events #250

axelbusch opened this issue Oct 10, 2018 · 7 comments
Assignees
Labels
status: waiting for information More information must be provided before work can proceed

Comments

@axelbusch
Copy link

axelbusch commented Oct 10, 2018

My application receives data packets via an RFM69 based chip, packages them into a JSON representation and sends them via WiFi to a nodeJS based backend.
I have a SAMD21 design board with several peripherals, including the ATWINC1500 for wifi. I use the WiFi101 library. However, sporadically (sometimes after 30 min, but more often after several hours) the code gets stuck in WiFiSocketClass::connect at handle events in the loop:
while (_info[sock].state == SOCKET_STATE_CONNECTING && millis() - start < 20000) { m2m_wifi_handle_events(NULL); //Code gets stuck here }
I decreased the timeout from 20000 to 4000, but whitout success.
It should be mentioned that connect is called quite often, i.e. about 2-3 times per minute.
At first I thought about too little available RAM. My application uses about 10-12kb of SRAM, so before I start the connection I have about 20kb available RAM.
I use the latest firmware.

What could be the problem of the freeze? Any idea?

bool sendWiFiMessage(SensorData* data)
{
  WiFiSSLClient client;
  client.setTimeout(2500);
  if (!wlanUp())
    wifiConnect();
  if (client.connect(statusServer, statusServerPort)) {
    postDataMessage(client, data);
  }
  else
    return false;
  int timeout_at = millis() + _timeout;
  while (!client.available() && timeout_at - millis() < 0) {
    client.stop();
  }
  if(!checkServerOkMessage(client)) 
      return false;
  //Stop connection
  if (client.connected()) {
    client.stop();
    return false;
  }    
  return true;
}
@Rocketct
Copy link
Contributor

Rocketct commented Oct 19, 2018

Hi @axelbusch, thank you for open the issue, could you please share a minimal sketch that reproduce the problem? and check which version of the ATWINC1500 firmware you have?

@Rocketct Rocketct added the status: waiting for information More information must be provided before work can proceed label Oct 24, 2018
@desvdp
Copy link

desvdp commented Nov 2, 2018

Hi @axelbusch , when you say your code gets "stuck", is it the WINC1500 module which becomes stale or your own code running on the SAMD21? I'm having a similar issue but in my case it's clearly the WINC1500 that gives up. As a matter of fact, the problem might have been described a couple of times before, such as for example in: #86. @sandeepmistry; might there still be an issue where the WINC1500 hangs, possibly by overflowing the RX buffers? At least in my case I can confirm that when it happens the RSSI is reported 0 while the conneciton status reports "all good".

@sandeepmistry
Copy link
Contributor

@desvdp

might there still be an issue where the WINC1500 hangs, possibly by overflowing the RX buffers? At least in my case I can confirm that when it happens the RSSI is reported 0 while the conneciton status reports "all good".

Not that I'm aware of when used with a SAMD, with the latest version of the lib socket data should not block other operations.

If you have a minimal sketch and steps to reproduce the issue, we can take a closer look.

Also, have you updated the WINC1500 to the latest firmware via the WiFi101 firmware updater in the IDE?

@desvdp
Copy link

desvdp commented Nov 2, 2018

@sandeepmistry I currently don't have a simple sketch at hand, I'll see if I can reduce the one I'm working with to the bare minimum. In essence, when it comes to using WiFi101 I'm implementing a simple http server and I'm also running the ArduinoOTA lib (including its mDNS) all configured with a static IP address. What I see is that after some time (hours) the WiFi stops responding, where the yellow led on the Feather M0 Wifi I'm using is continuously lit. As mentioned the RSSI reports 0 in such case; drilling down a bit more it turns out the call "m2m_wifi_req_curr_rssi" returns a negative result (I'm now waiting to see which...M2M_ERR_MEM_ALLOC is stop a possiblitly), so it's not a timeout on handle events imho. I'll keep you posted as I find out more, if you have stuff for me to try I'm happy to do so. Given the coming and going of reports on this behaviour I'm actually stating to wonder if an external factor (some rogue packet?) might have anything to do with it. Oh, almost forgot : I'm running the latest version on the master branch of this code together with FW19.5.4 of the WINC1500

[update] can you maybe elaborate a bit on "with the latest version of the lib socket data should not block other operations" ... I was assuming this is in the master branch, is it? What do you mean by blocking other operations, wifi operations, or something else ? Thx !

[update 2] I had modified my sketch, removing the WiFi101OTA functionality, after which the sketch ran for almost 18hrs, including 30000+ calls to the web service it's hosting (curl for loop), this was a new record for my board. To confirm this hypothesis I modified the included SimpleWebServerWiFi example by adding the WiFi101OTA calls, that sketch is now running ...

@S2Doc
Copy link

S2Doc commented Jan 23, 2019

Having very similar problem, occurs once every 3-7 days (sending MQTT packets every 5 seconds). Seems to be failing at about same place, ie somewhere in WiFiClient::connect() which in turn calls WiFiSocket::connect(). Also using Adafruit M0 Fether with WINC1500. Also using WINC firmware 19.5.4 because Adafruit suggests not upgrading beyond that.

Has anyone found the cause or solution to this problem?

@Rocketct
Copy link
Contributor

Hi @S2Doc could you please open a issue for your problem because this will be close due to lack of feedback from who open the issue @axelbusch and seems that with last update all goes fine for @desvdp, in the issue that you open, please, share also a minimal sketch that reproduce your problem, and write with version of the firmware and library you are using.

@Rocketct
Copy link
Contributor

Closed due to lack of feedback

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: waiting for information More information must be provided before work can proceed
Projects
None yet
Development

No branches or pull requests

5 participants