LmacRxBlk:1

All ESP8266 boards running MicroPython.
Official boards are the Adafruit Huzzah and Feather boards.
Target audience: MicroPython users with an ESP8266 board.
Post Reply
User avatar
MorseIot
Posts: 38
Joined: Fri Jun 29, 2018 12:32 am

LmacRxBlk:1

Post by MorseIot » Tue Aug 14, 2018 12:58 pm

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 ???

bitninja
Posts: 115
Joined: Thu Sep 15, 2016 4:09 pm
Location: Spring, Texas

Re: LmacRxBlk:1

Post by bitninja » Tue Aug 14, 2018 1:43 pm

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.

User avatar
pythoncoder
Posts: 3597
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: LmacRxBlk:1

Post by pythoncoder » Tue Aug 14, 2018 5:24 pm

Peter Hinch

bitninja
Posts: 115
Joined: Thu Sep 15, 2016 4:09 pm
Location: Spring, Texas

Re: LmacRxBlk:1

Post by bitninja » Wed Aug 15, 2018 3:25 am

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()

Post Reply