← index #18055Issue #17279
Off-topic · high · value 1.396
QUERY · ISSUE

ESPNow doesn't recover from buffer error

openby mrichar1opened 2025-09-10updated 2026-03-23
bugport-esp32

Port, board and/or hardware

ESP32_GENERIC_C3-20250809-v1.26.0; ESP32 C3 Supermini

MicroPython version

MicroPython v1.26.0 on 2025-08-09; ESP32C3 module with ESP32C3

Reproduction

From the sender, send a too-large message via ESP32 (>250 bytes), followed by more 'correct' messages:

e.send(peer, "a" * 10)
e.send(peer, "a" * 10)
e.send(peer, "a" * 10)
e.send(peer, "a" * 251)
e.send(peer, "a" * 10)
e.send(peer, "a" * 10)
e.send(peer, "a" * 10)

Receive the messages, catching errors:

while True:
    try:
        print(e.recv())
    except Exception as err:
        print(err)

Expected behaviour

The first too-large message should raise an exception. Subsequent 'correct' messages should then continue as normal.

Observed behaviour

The first messages appear as expected - once the long message is received, the exception is printed repeatedly and no further messages are seen:

[b' n\xf1h\x98\x90', b'bbbbbbbbbb']
[b' n\xf1h\x98\x90', b'bbbbbbbbbb']
[b' n\xf1h\x98\x90', b'bbbbbbbbbb']
ValueError: ESPNow.recv(): buffer error
ValueError: ESPNow.recv(): buffer error
ValueError: ESPNow.recv(): buffer error
ValueError: ESPNow.recv(): buffer error
ValueError: ESPNow.recv(): buffer error
<repeats forever>

Additional Information

A workaround for this issue is to deinit on ValueError, i.e.:

try:
    e.recv()
except ValueError:
    e.active(False)
    e.active(True)

Code of Conduct

Yes, I agree

CANDIDATE · ISSUE

declaring an "big buffer" on esp32-s3 (16MB Flash & 8Mb RAM) need "long" time to recover connection after crash

closedby chf-6309opened 2025-05-10updated 2025-05-10
bug

Port, board and/or hardware

esp32-s3 "generic" (from AliExpress) YD-ESP32-23 / 2022-v1.3

MicroPython version

MicroPython v1.25.0 on 2025-04-15; Generic ESP32S3 module with Octal-SPIRAM with ESP32S3

Reproduction

#LCD TFT size
width = 320
height = 480

# === Create a framebuffer RGB888 (3 bytes per pixel) ===
def create_framebuffer(width, height):
    return bytearray(width * height * 3)  # 460800 bytes - 461KB

called from main program:
buf = create_framebuffer(width, height)

Expected behaviour

with 8MB available RAM, expect that, even is the buffer isn't used, the access to the esp32 card will be possible.
The size of that buffer should be around 460KB, small compared to the 8MB available

When my program crash during tests, after the buffer allowance, it need minutes or more, to recover the USB link to the card, or before I include an:

del buf
gc.collect()

at the end of the program.

The fastest way is to do an hard RESET

Observed behaviour

the esp32 need minutes (more than five) before communication with PC and (portable) Thonny v4.17 is (again) possible, without the use of the hard reset.

First I didn't use the "Generic ESP32S3 module with Octal-SPIRAM with ESP32S3" firmware, so, the available RAM was little as ~300KB. Withe the Octal version I get;

Mémoire libre : **8312704 octets** [free memory]
stack: 736 out of 15360
GC: total: 64000, used: 8832, free: 55168, max new split: 8257536
 No. of 1-blocks: 176, 2-blocks: 22, max blk sz: 32, max free sz: 3410

MicroPython v1.25.0 on 2025-04-15; Generic ESP32S3 module with Octal-SPIRAM with ESP32S3

Type "help()" for more information.

>>> import gc
>>> gc.mem_alloc()
**10640**
>>> gc.mem_free()
**7785024**

Additional Information

No, I've provided everything above.

Code of Conduct

Yes, I agree

Keyboard

j / / n
next pair
k / / p
previous pair
1 / / h
show query pane
2 / / l
show candidate pane
c
copy suggested comment
r
toggle reasoning
g i
go to index
?
show this help
esc
close overlays

press ? or esc to close

copied