Espruino Wifi issues

[espruino-discuss]

Posted at 2017-05-08 by SteveHayles

Firstly huge kudos to the developers of Espruino; it's fairly mind blowing being to able to easily and quickly prototype systems on fast hardware with such a simple and well thought development process.

I have come across issues trying to get a reliable send / receive system using MQTT. The problems do not come from the MQTT libraries themselves and I think I have tracked the issues to the EspruinoWifi module which is causing the socket to close during a 'send' cycle.

The following code

send : function(sckt, data) {
    if (at.isBusy() || socks[sckt]=="Wait") return 0;
    if (socks[sckt]<0) return socks[sckt]; // report an error 
    if (!socks[sckt]) return -1; // close it
    //console.log("Send",sckt,data);
   
    var cmd = 'AT+CIPSEND='+sckt+','+data.length+'\r\n';
    at.cmd(cmd, 10000, function cb(d) {       
      if (d=="OK") {
        at.register('> ', function() {
          at.unregister('> ');
          at.write(data);          
          return "";
        });
        return cb;
      } else if (d=="Recv "+data.length+" bytes") {
        // all good, we expect this 
        return cb;
      } else if (d=="SEND OK") {
        // we're ready for more data now
        if (socks[sckt]=="WaitClose") netCallbacks.close(sckt);
        socks[sckt]=true;
      } else {
        socks[sckt]=undefined; // uh-oh. Error.      
        at.unregister('> '); 
      }
    });
    // if we obey the above, we shouldn't get the 'busy p...' prompt
    socks[sckt]="Wait"; // wait for data to be sent
    return data.length;
  }
};

attempts to send data using the well known CIPSEND, OK>, sendMyData, SEND OK pattern of the ESP8266 and if there is no incoming data during the send period then everything works fine.

The issue comes in that the callback data will sometimes contain other incoming data (say from an +IPD call) from the RX buffer in which case the final else clause (line 24) determines there has been an error.

I have tried various attempts to better synchronize calls to the SEND function and 'lock' any receive events but haven't been successful.

What does anyone think about simply returning the callback in any situation that is outside the normal flow ?

I have tried it as follows

} else {
  //socks[sckt] = undefined; // uh-oh. Error.      
  at.unregister('> ');
  return cb;
}

and it allows the socket to stay running but it still doesn't feel quite right. With a more explicit error clause (not sure what that looks like from the ESP2866 when it fails to send) it seems a workable solution and has allowed me to send and receive asynchronous (publish and subscribe independently) with decent size messages at upwards to 10Hz.

Any thoughts on whether it's a valid fix or whether there are better solutions ??

Thanks and regards,

Steve

[espruino-discuss]

Posted at 2017-05-09 by @gfwilliams

Sorry you've hit problems - but wow, thanks for tracking this down so far.

Do you have a simple example that'll reproduce this? And do you know what the value of d is when it does try and force-close the socket? I'd have hoped that the +IPD data would be trapped before it ever got to the send call.

I'd be a little worried about leaving the at.unregister('> '); in there, since it pretty mucth guarantees that the data packet will never be sent afterwards - but if there's something specific in d that can be ignored, we should definitely do that (although it could be a sign of a problem in the handling of +IPD data).

---

Posted at 2017-06-15 by dave_irvine

I think I might be running into something similar.

If I open a http get and a http post at the same time and pipe from the get to the post, I eventually get a freeze which I imagine is the esp8266 failing silently.

---

Posted at 2017-06-16 by @gfwilliams

It's odd - I was pretty sure I'd made some recent changes to help with this issue though. Do you think you could check on process.memory() (as in your previous post) as I guess it's possible that the piping has some problem if it runs out of memory during the pipe operation itself?