Smaller and with more free memory. The images are 83 to 134 KB smaller than beta.28 (M5StickC: 1,601,824 → 1,482,512 bytes, 75 % of the update slot instead of 81 %), and an M5StickC has 84 KB of usable memory at rest (about 62 KB on beta.28, estimated: it could not tell). Nothing was removed:
- the firmware is built without C++ exceptions, which nothing in it used but every part carried the tables for;
- the web page stores the English texts of its translations once instead of once per language (22 KB);
- the web server's task had a 16 KB stack and uses 3 KB of it, the MQTT client kept a 7 KB buffer for one message a cycle (that message is now written straight to the connection), and a few buffers are only taken while they are used.
The restart of #639 can no longer happen. On some networks a board restarted every few days with "crash" as the cause. @forTT78 found it from a core dump: the mDNS responder of the ESP-IDF version under the firmware reads a NULL pointer when the known answers of a truncated query empty the answer it had scheduled. The firmware now clears the "truncated" flag of an mDNS packet before that code reads it, so it never schedules an answer that way: such a query is answered like any other. Checked with packets built for it: they restart a board without the fix and do nothing to one with it, which keeps answering to espaltherma.local.
Firmware update from the web page.
- One upload at a time. Pressing the update button twice sent two uploads that mixed on the board (@stav242): the buttons now stay off until the upload ends, and the board refuses a second upload while one is being written.
- The page restarts the board first when it has been running for more than five minutes, waits for it, then uploads: a board fresh from a restart has all its memory free for it. This starts with the update after this one, since the page doing the update is the one of the firmware you run.
- An upload that is cut is written in the event history with how far it got ("cut at 812 KB after 66 s, memory down to 12 KB"), and the half-written update is dropped.
The update check, the daily heartbeat and the report only run with the memory for them. An HTTPS connection takes 54 KB while it is made. The test before one counted memory that only code can use, so it could pass with too little: it now looks at the usable memory and its largest piece, and comes back an hour later when there is not enough. The log says "Report sent" or "Report not sent" (it said "sent" with an error code).
For diagnosis. /api/heap on the board: the usable memory, its largest piece, what the last HTTPS connection took, the unused stack of each task (ESP32-C6 only for now) and the free memory at each step of the start. /api/status has heap_data, heap_data_min and heap_block next to heap, which also counts memory that only code can use.
Not in this release: Arduino core 3. It was tried for the mDNS problem. On a classic ESP32 it leaves 22 KB less memory and makes the image 200 KB larger, so the firmware stays on core 2.0.17 (the ESP32-C6 is on core 3, as before). M5Unified and M5GFX are now pinned to 0.3.0, the versions beta.28 was built with: a new release of them changed the image size by 24 KB.
Update: System → Firmware update → Check for an update, or the web installer. Card: 1.0.36, unchanged.