iotpanic / s Goto Github PK

Samuel I'm trying to test fragmentation sending this two packets (Just update txt -> to bin)

And I'm getting a reset in the firmware.
Package 1:
1573067790816-pixel-out.txt
Package 2:
1573067794315-pixel-out.txt

Serial output:
UDP Listening on IP:
192.168.0.73:1234

11 17 19 53 0 C8 0 0 50 0 0 48 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1D 36 81 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
11 17 19 53 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 B2 0 Guru Meditation Error: Core 1 panic'ed (StoreProhibited). Exception was unhandled.

Can you please take a look and try to reproduce it?

I want to write this ticket to give a bit more background of the issue. This amount of bytes is on the edge of the MTU max transport unit of the ESP32.
On the test tool using RGB I send 466 pixels (with 465 still runs)
The numbers that the testing tool reports are:

Payload: 1398 Frame size: 1413

Adding this debug line just before the memcpy in line 58 of s.cpp reports:

            Serial.printf("Before memcpy: t.index:%d t.size:%d m.len:%d freeHeap:%d\n",t.index,t.size,m.len,ESP.getFreeHeap());
            memcpy(t.pyld, m.pyld, m.len);

Before memcpy: t.index:540 t.size:1415 m.len:1407 freeHeap:235796 (starts with 236Kb free)

After memcpy -> It does not die in memcpy, didn't discover yet when it does.

But I see two issues here:

1. The main show stopper is the payload limit when they should be stil some room more to send via UDP (Not much, last time I checked was 1470 bytes). It's not hitting the MTU limit per UDP if I see it right, and if did should not be a reason to hang, since we checked previously when that happens simply the onPacket callback is not called

2. There is a very small but consistent memory leak that can be tracked adding this debug line.
   It starts at 235000 free Heap and every 50 seconds the heap reduces itself in 10Kb. I was looking at it all the time today and I never caught it resetting but when the heap goes below freeHeap:58720 bytes it dies and resets itself.

But so far apart a part of this issues is working really fast so I think it has a lot of potential.