domints / ESP-Ruuvi-Collector

ESP32 firmware serving as a bridge between Ruuvi Tag with Ruuvi firmware and InfluxDB written in Arduino IDE
MIT License
11 stars 5 forks source link

ESP32 programmable space exceeded by sketch #1

Closed Quas7 closed 5 years ago

Quas7 commented 5 years ago

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.

domints commented 5 years ago

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.

domints commented 5 years ago

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 5 years ago

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.

domints commented 5 years ago

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 5 years ago

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 5 years ago

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 5 years ago

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.