Page 1 of 1

LmacRxBlk:1

Posted: Tue Aug 14, 2018 12:58 pm
by MorseIot
From time to time using urequests I get the error message OSError -2 and the message in loop LmacRxBlk:1. I only recover the ESP after resetting hardware

Any way to solve this problem ???

Re: LmacRxBlk:1

Posted: Tue Aug 14, 2018 1:43 pm
by bitninja
I get similar messages when using uftpd.py and I transfer a large number of files or one large file, but it does not usually force me to reset. I was under the impression that it was coming from an underlying network layer and not MicroPython itself.

Perhaps you can look at https://github.com/robert-hh/FTP-Server ... r/uftpd.py and see if he has any code to trap this error.

Re: LmacRxBlk:1

Posted: Tue Aug 14, 2018 5:24 pm
by pythoncoder

Re: LmacRxBlk:1

Posted: Wed Aug 15, 2018 3:25 am
by bitninja
I found this in the documentation that may help...

http://docs.micropython.org/en/latest/e ... datasheets
Socket instances remain active until they are explicitly closed. This has two consequences. Firstly they occupy RAM, so an application which opens sockets without closing them may eventually run out of memory. Secondly not properly closed socket can cause the low-level part of the vendor WiFi stack to emit Lmac errors. This occurs if data comes in for a socket and is not processed in a timely manner. This can overflow the WiFi stack input queue and lead to a deadlock. The only recovery is by a hard reset.

The above may also happen after an application terminates and quits to the REPL for any reason including an exception. Subsequent arrival of data provokes the failure with the above error message repeatedly issued. So, sockets should be closed in any case, regardless whether an application terminates successfully or by an exeption, for example using try/finally:

Code: Select all

sock = socket(...)
try:
    # Use sock
finally:
    sock.close()