Framed Display crashes ESP #676
Comments
|
forgot to mention: The crash does not happen on any web interaction. Go to devices and click "edit" of the framed display. Serial output shows then: INIT : Booting version: (custom) Panic /home/john/ArduinoPortable/arduino-1.8.5_ESP2.4.0/portable/packages/esp8266/hardware/esp8266/2.4.0/cores/esp8266/core_esp8266_main.cpp:133 loop_task ctx: cont
wdt reset ` |
|
This call to backgroundtask is comparable to yield(), isn't it? |
|
So omitting it is not a solution but merely a hint on what is going wrong.
…-------- Ursprüngliche Nachricht --------
Von: Gijs Noorlander <notifications@github.com>
Gesendet: 5. Januar 2018 23:11:42 MEZ
An: letscontrolit/ESPEasy <ESPEasy@noreply.github.com>
CC: s0170071 <drk@posteo.de>, Author <author@noreply.github.com>
Betreff: Re: [letscontrolit/ESPEasy] Framed Display crashes ESP (#676)
This call to backgroundtask is comparable to yield(), isn't it?
This yield() should perform more time limited things like WiFi stuff, periodical stuff (multiple times per second tasks) and such.
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#676 (comment)
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
|
|
It is in ESPEasy.ino (line 1322). |
|
if you replace the backgroundtasks() with just webserver client handling it does also crash if you press the edit button while the display scrolls. I would love to try lwip2 but can't get it to compile yet, ESPEasy uses some functions which are not available with lwip2 any more. |
|
In the mega branch, I updated the library for the OLED. So maybe you can also test with that one? |
|
no success.
|
|
Yep it is. |
|
I just added a printf at the end of the plugin and two more in the scroll routine: The Output without crash is: and with crash: So: it does not finish the scroll loop but directly returns from the plugin call. Sounds an awful lot like a full stack to me. I googled a bit but could not get a hold of the SP register address. Might be worth monitoring. |
|
I am currently writing default constructors for all the structs in ESPeasy.ino and I will create a commit for them. (you don't want to do that again, which is a painful cut'n-paste job. |
|
I cannot checkout the pull request. GitKraken shows 7 pending requests but when I click on it it would create a new one. When I do the same thing with the core git I can pick a pr and it checks it out. |
|
As a test, you can try to copy the files from my changes to your local branch. |
|
There is a function missing... /home/john/Arduino/scetchbooks/ESPEasy_git/ESPEasy/ESPEasy.ino: In function 'void loop()': |
|
That was in #621 Maybe we should add some workflow/Git introduction to the wiki, since I also struggled a bit in the beginning. |
|
oh man, sigh. |
|
I have created a separate path for my Arduino builds. This contains a symbolic link to the src directory just so Arduino IDE sees an ESPEasy directory with .ino files and the other path (the git repository) is being used for GitKraken and Atom + PlatformIO. But I think we should definitely create an issue and/or a forum topic to gather information on how to use a good workflow and should document this on the wiki. |
|
Agreed. I would even go a step further and create a setup tool / script to have a "one click ready to use as described" environment.
I do have four portable Arduino IDE's, one for each core version. Each with a different board URL. Not to forget to pick the right board, port, lwip,...
Gitkraken with two repos checked out. Then the shortcuts for the libs and the src folder for the ide: that's a real pain :-| . Usb driver.
Maybe platformio, an account for it. Settings for platformio.
Having such a setup tool would make it a pleasure to try a fresh setup if things become strange...
And it's a good starting point for additional operations and a documentation.
Mega bonus: debug. There are rumors that there is some sort of soft JTAG available. But setting this up would probably take its time. Or the gdb stub with visual gdb. But wait, wasn't this the purpose of platformio?
Ah, and there is also visualmicro with their soft debugger. haven't tried it yet.
You see, lots of work. And once you're done you get doubts about the directory structure.
…-------- Ursprüngliche Nachricht --------
Von: Gijs Noorlander <notifications@github.com>
Gesendet: 8. Januar 2018 12:10:33 MEZ
An: letscontrolit/ESPEasy <ESPEasy@noreply.github.com>
CC: s0170071 <drk@posteo.de>, Mention <mention@noreply.github.com>
Betreff: Re: [letscontrolit/ESPEasy] Framed Display crashes ESP (#676)
I have created a separate path for my Arduino builds. This contains a symbolic link to the src directory just so Arduino IDE sees an ESPEasy directory with .ino files and the other path (the git repository) is being used for GitKraken and Atom + PlatformIO.
In Linux it is really easy to create symbolic links (`ln -s`) and in Windows it is also possible. For example, see: http://forum.arduino.cc/index.php?topic=335588.0
But I think we should definitely create an issue and/or a forum topic to gather information on how to use a good workflow and should document this on the wiki.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#676 (comment)
|
|
I found out the "hard" way last weekend that PlatformIO does not yet support ESP12e boards for debugging. |
|
isn't this related to memory issues @mvdbro mentioned with core 2.4.0? It uses much more memory, which could explain those crashes. |
|
are you using mqtt? |
|
@TD-er thats too bad :( usually i work around stacktraces or use the arduino ide + exception decoder. (used it for 1 or 2 hard bugs in the past) |
|
added this to v2.0 since its probably an underlying core issue. |
|
i could reproduce this problem and was memory related. latest commit fixes it. |
|
Just tried 2.0 with core 2.3.0 and 2.4.0rc2 Didn't test any further. |
fixes letscontrolit#654 letscontrolit#676 and could be triggered by letscontrolit#683 in some cases.
|
we've changed the way the Device type is selected. Once its selected, you need to click "delete" (bottom of the screen) to reset it so you can select another device. (this actually saves lots of memory) Indeed 2.0 is stable, mega is 2.0 + new features. altough we're lagging a bit, we still need to merge those changes back to v2.0. (doing that as we speak) so perhaps you could try with the megabranch after that to see if the chunking is ok again. |
* [switch] Fixed switch behavior and default settings. (#675) As described in #673 . The problem was partly related to the default values stored in flash ("0"), which was not a valid value for the switch type. When upgrading from an older version of ESPeasy, make sure to check the switch type (normal switch or dimmer) and save the settings for the switch device again, even when nothing was changed. Default configuration and new added switches will now work like intended. When a controller is enabled (e.g. Domoticz MQTT or -HTTP) and the button is pressed multiple times, the ESP may reboot. See issue #674. * ABC calibration feature added (#606) * [Flash info] Detailed flash information (#678) Last few days a number of issues and forum topic was about the type of flash used on the ESP boards. This is an extension of the detailed information page. Perhaps also merge with the newer and more clear layout of pull request #624? That pull request was only merged to the mega branch. I kept the changes local, but perhaps they should be placed in the "Storage" section introduced with #624. Maybe also that pull request should get merged into the v2.0 branch. * Bugfix/v2.0 crash switch (#682) * [crashes] Added constructors to initialize all members in structs Numerous structs are defined, but none of them have default constructors and there is no guarantee the members will be set when used. With these default constructors, the parameters at least have an initialized value. * [PubSubClient] Add bound checks on the internal buffer Not sure if this was really causing an issue, but proper bound checks are always a good thing. * [Crash Switch] Disabled delayBackground and added yield() calls Something really fishy is going on with the delayBackground function, which will result in crashes when pressing the switch multiple times, with Domoticz MQTT enabled as first controller. Disabled for now and delay(1) added to give background tasks a chance to do their work and make sure the watchdog doesn't perform a reset. * [CI build errors] Commented out some unused variables Travis considers them as error and fails the checks. * [CI check] Out-of-bounds check fix * actually ignore MQTT messages that are too big. * moved mqtt stuff outside of backgroundtasks(). fixes #683 in my test scenario * [Adafruit MPR121] Change deprecated name setThreshholds to setThresholds (#685) See #684 * fixed plugin id of "Communication - Kamstrup Multical 401". (accidental octal notation) * changed devicecombobox handling to save a lot of memory on device page. fixes #654 #676 and could be triggered by #683 in some cases. * [CPPcheck] v2.0 ControllerSettingsStruct some variables not initialized (#692) Fixing these cppcheck errors: 101.43s$ cppcheck --enable=warning src/*.ino -q --force -I src --include=src/ESPEasy.ino --error-exitcode=1 [src/ESPEasy.ino:500]: (warning) Member variable 'ControllerSettingsStruct::HostName' is not initialized in the constructor. [src/ESPEasy.ino:500]: (warning) Member variable 'ControllerSettingsStruct::Publish' is not initialized in the constructor. [src/ESPEasy.ino:500]: (warning) Member variable 'ControllerSettingsStruct::Subscribe' is not initialized in the constructor.
|
all fixed now in both branches. if i only fill the first few fields, it works like expected. |
|
mega is working, 2.0 not. But the crash is gone. |
|
The difference is that Mega is using a newer library version for the Framed OLED. (and a few small fixes) |
|
strange v2.0 is working with my oled display. i'm using the wemos oled display. |
|
ah ok..will add a ifdef to v2.0 so it gives a compiler errror |
Steps to reproduce
compile master with core 2.4.0 (fix the min max issue as mentioned in the forum)
set up a framed display, activate it.
interact with the web interface the very moment scrolling takes place.
Does the problem presist after powering off and on? (just resetting isnt enough sometimes)
y
Expected behavior
Tell us what should happen?
System configuration
Wemos D1 mini.
ps.
in the function
void display_scroll(String outString[], String inString[], int nlines, int scrollspeed)there is a call to
backgroundtasks();disable it and the issue is gone.
Question is: what are the drawbacks ?
The text was updated successfully, but these errors were encountered: