You are reading a single comment by @SteveHayles and its replies. Click here to read the full conversation.
  • Hi Steve, thanks! Any chance you could put a USB-TTL UART in there on the RX line so we can see if that missing \n is caused by a real Espruino Serial issue, or an ESP8266 bug? How often does it happen?

    Annoyingly I had another bug recently reported because the AT module used just to split on \r and not \r\n - it got changed maybe 2 weeks ago. Actual issue is here: https://github.com/espruino/Espruino/iss­ues/1512

    Unfortunately I think your fix may well fail in the case that you get socket data that contains just a \r?

    In the current builds, presumably that error just causes a socket timeout which resets your connection? It's not then a big deal to trap and reconnect - which you'd have to do because WiFi could be flaky?

    Best solution could be to revert that AT command lib change and to just tweak the offending library to use a 'handler' rather than a 'linehandler'

  • Hi, I will dig out a USB-TTL converter and try my other UART code but I am I right in thinking that there is no exposed Rx line to the ESP8266 on an Espruino Wifi board ?

    The code wasn't really a proposed fix, I think it helps explain and debug the problem more than anything. I wouldn't want you to bounce around with the AT handler, this is a genuine exception created elsewhere. For sure I can catch the error and close / reopen the socket and it's not stopping me making progress.

    One interesting observation is that I have written a small conditional debug log for when this happens and in several hours of running I have had around 100 of these situations and every one of them has happened during the OK response to an AT+CIPSEND. Don't spend too long on it !

    Regards, Steve

About

Avatar for SteveHayles @SteveHayles started