domints/ESP-Ruuvi-Collector

ESP32 programmable space exceeded by sketch

Closed this issue · 7 comments

Quas7 commented

Hi,

not sure, if the included libraries just grew in the meatime but I cannot upload this to my lolin32 lite because of exceeding the program memory limit.

"Der Sketch verwendet 1699106 Bytes (129%) des Programmspeicherplatzes. Das Maximum sind 1310720 Bytes."

Might have to play with the partition table, if I find time for it.

Yes, you definitely need to change partition table. I thought I put that in readme, but in the end I didn't put any at all. I'm so sorry. If you'd like me, I could check later, in the evening, which partition table I used.

However, this code seems to be unstable. It hangs after some time and does not return consistent results - it sometimes do not see all the sent beacons.
I was talking on Ruuvi slack with some people about that and we ended aknowledging that it is really hard to use Bluetooth and WiFi at once on ESP32 and I didn't have enough resources to fix the problems.

I guess I should put that in the README too...

Quas7 commented

Ok. Luckely, today it is quite easy to change partitions for ESP32 as you pushed for this feature in the Arduino IDE.
I implemented protocol v3 for my RuuviTag firmware. It also runs stable after increasing the char fields array to 256. Before that I experienced random reboots. I assume, that malformed mData due to RF communication fails leads to a buffer overflow.
I started a pull request #2, if you would like to merge it.

Thank you for these changes.
For how long did you test it? I think it was running quite not bad for few days and it hung later completely. But maybe it was rebooting too, sometimes.

Quas7 commented

Ok, I tested not long enough.
But it looks like that there is a watchdog timeout following a late response from the influxdb.
The error is normally "error: -11" not "error: -1"

ruuviTag,device=esp temperature=20.700,pressure=99408,humidity=48,milivolts=2971
error: -1
ASSERT_PARAM(-218959118 0), in arch_main.c at line 325
Guru Meditation Error: Core  0 panic'ed (Interrupt wdt timeout on CPU0)

Also, he task watchdog gets triggered.

ruuviTag,device=esp temperature=20.630,pressure=99387,humidity=48,milivolts=2977
E (873287) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (873287) task_wdt:  - IDLE0 (CPU 0)
E (873287) task_wdt: Tasks currently running:
E (873287) task_wdt: CPU 0: Btc_task
E (873287) task_wdt: CPU 1: IDLE1
E (873287) task_wdt: Aborting.

I added a yield() in the loop() with my last master-commit but not sure, if this will help at all.
I will also try to increase the time for the wdt.

Quas7 commented

I added a loop() time measurement and set the wdt to 3000 as in this example:
https://github.com/espressif/arduino-esp32/blob/master/libraries/ESP32/examples/Timer/WatchdogTimer/WatchdogTimer.ino

Background on the WDTs here:
https://github.com/espressif/esp-idf/blob/master/docs/en/api-reference/system/wdts.rst

The loop time seems to be >3000 but I also added a few serial.printf that increase this as well.

loop time is = 2068
ruuviTag,device=esp temperature=20.550,pressure=99351,humidity=48,milivolts=2977
loop time is = 1007
loop time is = 1035
loop time is = 1053
ruuviTag,device=esp temperature=20.550,pressure=99352,humidity=48,milivolts=2977
loop time is = 2014
ruuviTag,device=esp temperature=20.550,pressure=99352,humidity=48,milivolts=2977
reboot
Guru Meditation Error: Core  0 panic'ed (Interrupt wdt timeout on CPU0)

Will test now, if there is a WDT timer limit that works.

Quas7 commented

After reading a few more threads on esp32 watchdog, it seems that triggering this way too often results in a crash of the esp32.

I ran a few hours now with 20sec watchdog timeout and got these error logs.

First, there are triggers on core0 and core1 for the interrupt wdt like these:

current loop time: 1006 / MaxTime: 5982
ruuviTag,device=esp temperature=20.040,pressure=99349,humidity=45,milivolts=2971
**error: -1** _(this should be -11 not -1 ... I assume, some communication glitch with too long timeout set)_
reboot
Guru Meditation Error: Core  1 panic'ed (Interrupt wdt timeout on CPU1)
...
current loop time: 1006 / MaxTime: 9035
ruuviTag,device=esp temperature=22.270,pressure=99582,humidity=73,milivolts=2983
reboot
Guru Meditation Error: Core  0 panic'ed (Interrupt wdt timeout on CPU0)

This might be related to the http/tcp processing of the arduinoinflux.cpp lib. I added some yield() to this lib to reset the watchdog there.

Also, the task watchdog gets triggered like this:

ruuviTag,device=esp temperature=20.110,pressure=99264,humidity=44,milivolts=2977
error: -11
current loop time: 14375 / MaxTime: 14375
ruuviTag,device=esp temperature=20.110,pressure=99265,humidity=44,milivolts=2977
E (1435977) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (1435977) task_wdt:  - IDLE0 (CPU 0)
...
ruuviTag,device=esp temperature=22.370,pressure=99673,humidity=56,milivolts=2977
current loop time: 13682 / MaxTime: 13682
current loop time: 1004 / MaxTime: 13682
ruuviTag,device=esp temperature=22.370,pressure=99673,humidity=56,milivolts=2977
E (500353) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (500353) task_wdt:  - IDLE0 (CPU 0)

I will increase now the watchdog to 30seconds, as the application only requires a temperature and humindty datapoint per minute anyway.