With 3.1, here is what I get on a clean boot: OVMS# module memory Free 8-bit 133180/282048, 32-bit 8164/24420, SPIRAM 4148396/4194252 And, again with 3.1, here it is after starting SIMCOM modem, wifi in APCLIENT mode, TR vehicle module, and Server v2: OVMS# module memory Free 8-bit 79520/282048, 32-bit 8164/24420, SPIRAM 4136036/4194252 OVMS# module tasks Number of Tasks = 18 Stack: Now Max Total Heap 32-bit SPIRAM Task 3FFAEB34 1 esp_timer 392 648 6656 55140 644 0 Task 3FFAF7E0 2 eventTask 444 3116 4608 7620 0 0 Task 3FFC3F68 3 CanRxTask 420 420 4096 0 0 0 Task 3FFC8060 4 ipc0 396 444 1024 10848 0 0 Task 3FFC8660 5 ipc1 396 444 1024 12 0 0 Task 3FFCA488 8 IDLE 356 484 1024 0 0 0 Task 3FFCAA1C 9 IDLE 360 488 1024 0 0 0 Task 3FFCC3B0 10 Tmr Svc 396 3276 6144 7816 0 0 Task 3FFCF8F0 14 Housekeeping 364 2716 6144 53420 0 0 Task 3FFC8AB0 16 tiT 496 2752 6144 7112 0 0 Task 3FFD79C8 17 SIMCOMTask 452 2260 4096 4404 0 0 Task 3FFDB8C8 18 AsyncConsole 756 4964 5120 45864 15488 0 Task 3FFDCD84 19 mdns 416 1736 4096 108 0 0 Task 3FFE147C 20 wifi 424 2296 4096 5180 0 0 Task 3FFE3D74 21 pmT 416 464 2560 0 0 0 Task 3FFE6C30 22 NetManTask 732 2556 7168 2488 0 0 Task 3FFEAB08 23 Vrx Task 452 452 4096 0 0 0 Task 3FFEAD0C 24 OBDII ECU Task 424 424 6144 0 0 0 I think something got broken with a recent build of ESP-IDF so that our ‘module memory’ and ‘module tasks’ is not showing SPIRAM usage correctly. But, it is definitely used and certainly helps ease the stress: OVMS# module memory Free 8-bit 133032/282048, 32-bit 8164/24420, SPIRAM 4148396/4194252 OVMS# obdii ecu start can3 OBDII ECU has been started OVMS# module memory Free 8-bit 125000/282048, 32-bit 8164/24420, SPIRAM 4147772/4194252 --Task-- Total DRAM D/IRAM IRAM SPIRAM +/- DRAM D/IRAM IRAM SPIRAM AsyncConsole 13896 6144 15488 0 +1876 +6144 +0 +0 We are far from perfect, but I think good enough for some factory firmware. Anything else will come as OTA. Regards, Mark.
On 21 Mar 2018, at 3:12 AM, Michael Balzer <dexter@expeedo.de> wrote:
Am 20.03.2018 um 06:47 schrieb Greg D.:
Ok, interesting. Am I seeing an out-of-memory crash? I can't tell...
It seems like the webserver status button is the worst offender, probably because it's doing a lot of work and building a big payload. Very often hangs for a while before responding, and if so, usually results in the job queue overflow. If I catch it quick enough and hit home or some other shorter task, the overflow will drain and I'll get the new screen; otherwise a crash. Sometimes there will be a timeout mixed in. I'm wondering if our little squirrel in the ESP32 just can't pedal hard enough...
Most crashes now are related to lack of free memory.
Regarding the status page I just hit the page 10 times:
OVMS# mo m Free 8-bit 27264/283200, 32-bit 27544/55820, SPIRAM 0/0 I (784440) webserver: HTTP GET /status D (785010) webserver: Serve /status: 6068 bytes used, 21200 free I (787240) webserver: HTTP GET /status D (787830) webserver: Serve /status: 6064 bytes used, 21168 free I (788720) webserver: HTTP GET /status D (789290) webserver: Serve /status: 6104 bytes used, 21164 free I (790110) webserver: HTTP GET /status D (790700) webserver: Serve /status: 6100 bytes used, 21164 free I (791530) webserver: HTTP GET /status D (792120) webserver: Serve /status: 6068 bytes used, 21200 free I (792980) webserver: HTTP GET /status D (793550) webserver: Serve /status: 6100 bytes used, 21164 free I (794400) webserver: HTTP GET /status D (794980) webserver: Serve /status: 6068 bytes used, 21200 free I (795860) webserver: HTTP GET /status D (796730) webserver: Serve /status: 6100 bytes used, 21164 free I (797160) webserver: HTTP GET /status D (797740) webserver: Serve /status: 6064 bytes used, 21168 free I (798430) webserver: HTTP GET /status D (799020) webserver: Serve /status: 6060 bytes used, 21200 free OVMS# mo m Free 8-bit 27264/283200, 32-bit 27544/55820, SPIRAM 0/0
So no memory loss and no crashes.
The 6K is just the buffer usage after processing. The commands executed for the status page need additional RAM, but above 20 K free, the page normally has no problems.
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev