letscontrolit / ESPEasy

Easy MultiSensor device based on ESP8266/ESP32
http://www.espeasy.com
Other
3.28k stars 2.21k forks source link

ESP32 not start after last upgrade #1802

Closed flexiti closed 5 years ago

flexiti commented 6 years ago

Let me start by saying that I'm obviously full of admiration for the work You put in. Personally, I think it's a great solution

However, recently this program is so unstable that I would consider stopping!!! all the changes before releasing a stable version. Uploading the new version is like Russian roulette, and usually something does not work. Now, for example, ESP32 does not start after the upgrade. (I will not mention the problems that I have with ESP8266)

Grovkillen commented 6 years ago

The ESP32 support is in Dev stage = anything can change. And the latest commit regarding ESP32 is clearly marked with what will happen if you update.

https://github.com/letscontrolit/ESPEasy/pull/1792

We are not yet officially supporting ESP32.

Sorry for your frustrations, we are still not 100% when it comes to documentation, especially not when it comes to "Dev" stuff.

TD-er commented 6 years ago

I will make 2 build images of the esp32 build, indicating different partition sizes. My idea was to merge it with special attention markers and before the nightly get some feedback from those that are aware of the changes. I made notices in about every reference to that commit/pr

flexiti commented 6 years ago

I suggest you stop adding add-ons and changes for a while, and focus on publishing a stable version. At the moment neither ESP32 nor ESP8266 can be trusted.

Grovkillen commented 6 years ago

What add-ons are you referring to? We're currently closing issues relating stability. No add-ons as I see it.

flexiti commented 6 years ago

add-ons - maybe an unfortunate word - every change that can generate a new error

eg.

but if you want to convince me that the version is stable .. it's a waste of our time;) I use 12 pcs of ESP8266 and 4 pcs of ESP32, I try both bin files and my own compilations and from the month after the tests I always return to the version from August because it somehow works, although here I hear that I should go back to the March version.

Grovkillen commented 6 years ago

No I'm not saying that it's stable, we would have released it then. I'm just trying to get to the essence of your situation, past the non-constrictive feedback :)

TD-er commented 6 years ago

The ESP32 was until a week ago using 0.12.0 core lib. That one was not able to run I2C. As soon as you would add >1 device it froze and Lots of plugins I tested were unstable. Now we can finally use core 1.3.0 (it finally can be build), which allows I2C devices. However, it is a lot bigger than 0.12.0, which makes it impossible to actually do anything with it. There was only about 5 - 10 kB left in the 'app' partition.

The reason I really want to have core 1.2.0 or higher on ESP32 is that it will allow me to run a debugger and add breakpoints to help me debug code which can be run on both ESP8266 and ESP32. I have the WROVER dev board here laying, but could not use it until now. Without debugger you have to add writes to log/serial or even debug using a scope by sending pulses to a pin. It looks really nice, but from a programming standpoint it is even more time consuming. So this is why I want to increase the partition size on the ESP32 to be able to actually do some testing. I will now make a separate entry in PlatformIO.ini to add a second build for ESP32, to allow all plugins from ESP8266 to be used on ESP32 for testing and debugging. At this moment all can be compiled except for BH1750 and the ones using serial port.

So the reason I am also working on ESP32 is to be able to actually see what's going on at ESP8266.

I am trying to get things to work stable and believe me, I am really working hard on it to find out what is causing all these watchdog issues. One of my ideas is that we might run into a stack overflow, and therefore I tried to free over a kB of stack space. The main reason I was merging the last merge this morning was to get the ones that know about the changes to test it. I also added about 4 or 5 warnings about the ESP32, that the last change would change the partition table. I had no time to make some builds this morning.

We should change the release/build cycli, since this isn't working.

TD-er commented 6 years ago

I made some split into building ESP32. Should I add the second one to the nightly build? You cannot change between the 'normal' ESP32 and the "1M8 partition" build without loosing settings. I will also add that to the README included in the ZIP.

LeeNX commented 6 years ago

A little offtopic, but is there a way to export the settings and re-import after flashing?

TD-er commented 6 years ago

Yes there is, but then you should have done that before updating. :)

rieders commented 6 years ago

Hello

Unfortunately I can not play the current version of the ESP32. I use ESP32 DEVKIT V1 and Wrooms32. Both have no firmware.

greetings André

TD-er commented 6 years ago

@rieders What is so special about those that the given versions cannot be used? And was it possible to run nightly builds on those boards? (e.g. builds of over a week ago)

flexiti commented 6 years ago

Todays source and ESP32...

rst:0x1 (POWERON_RESET),boot:0x12 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0018,len:4 load:0x3fff001c,len:952 load:0x40078000,len:6084 load:0x40080000,len:7944 entry 0x40080310 ŞU

rieders commented 6 years ago

?

flexiti commented 6 years ago

starts and hangs, rs232 log as above

TD-er commented 6 years ago

@flexiti Just to be sure, the version you test when starting this issue, is it self-built, or a nightly build? Obviously the one you just tested is a build you made yourself.

flexiti commented 6 years ago

sources updated, yesterday's sources worked, for today's not working anymore. Should not I compile? ;)

btw., for some time I have a problem with loading eg. Release mega-20180927, ESPeasy flasher display flash error at the end.

I'm not sure, but I do not know if this is not related to the latest Windows 10 updates

TD-er commented 6 years ago

Have you tried compiling it twice? And there haven't been many changes merged since yesterday. Only related to default values initialization and a plugin. Both not related to booting if you have valid settings.

flexiti commented 6 years ago

Now I see, when it is compiled as esp32test_1M8_partition - it works, and the compilation esp32dev does not work anymore. it looks like it was initialized with a new partition system before , and it is impossible to upload the version with the old partition now.

TD-er commented 6 years ago

You can flash an empty bin file to 'recover'. But I think we will be forced to change to a different partition layout later on.

flexiti commented 6 years ago

Flasher from "every night build" stop working on windows 10, I do not know why yet

TD-er commented 6 years ago

Did you already install the soon to be released Windows 10 update (probably next Tuesday) ? You could also try @Grovkillen flash tool.

flexiti commented 6 years ago

I tried, the same problem. Using platformio and Atom upload works correctly

2018-09-29

#######0.01.001#######

FLASH INFO

BIN file: ESP_Easy_mega-20180927_esp32test_1M8_partition.bin COM port: (COM3) Silicon Labs CP210x USB to UART Bridge Baud rate: 115200

POST FLASH

No post flash information entered...

FLASH LOG

[esptool.exe -vv -cd nodemcu -cb 115200 -cp COM3 -ca 0x00000 -cf "C:\Users\mariuszb\Desktop\ESP_Easy_Flasher-master\ESP_Easy_Flasher-master\BIN\ESP_Easy_mega-20180927_esp32test_1M8_partition.bin"] [29.09.2018 21:48:29] esptool v0.4.12 - (c) 2014 Ch. Klippel ck@atelier-klippel.de [29.09.2018 21:48:29] setting board to nodemcu [29.09.2018 21:48:29] setting baudrate from 115200 to 115200 [29.09.2018 21:48:29] setting port from to COM3 [29.09.2018 21:48:29] setting address from 0x00000000 to 0x00000000 [29.09.2018 21:48:29] espcomm_upload_file [29.09.2018 21:48:29] espcomm_upload_mem [29.09.2018 21:48:29] setting serial port timeouts to 1000 ms [29.09.2018 21:48:29] opening bootloader [29.09.2018 21:48:29] resetting board [29.09.2018 21:48:29] trying to connect [29.09.2018 21:48:29] flush start [29.09.2018 21:48:29] setting serial port timeouts to 1 ms [29.09.2018 21:48:29] setting serial port timeouts to 1000 ms [29.09.2018 21:48:29] flush complete [29.09.2018 21:48:29] espcomm_send_command: sending command header [29.09.2018 21:48:29] espcomm_send_command: sending command payload [29.09.2018 21:48:29] serialport_receive_C0: AA instead of C0 [29.09.2018 21:48:29] trying to connect [29.09.2018 21:48:29] flush start [29.09.2018 21:48:29] setting serial port timeouts to 1 ms [29.09.2018 21:48:29] setting serial port timeouts to 1000 ms [29.09.2018 21:48:29] flush complete [29.09.2018 21:48:29] espcomm_send_command: sending command header [29.09.2018 21:48:29] espcomm_send_command: sending command payload [29.09.2018 21:48:29] read 0, requested 1 [29.09.2018 21:48:29] trying to connect [29.09.2018 21:48:29] flush start [29.09.2018 21:48:29] setting serial port timeouts to 1 ms [29.09.2018 21:48:29] setting serial port timeouts to 1000 ms [29.09.2018 21:48:29] flush complete [29.09.2018 21:48:29] espcomm_send_command: sending command header [29.09.2018 21:48:29] espcomm_send_command: sending command payload [29.09.2018 21:48:29] serialport_receive_C0: 31 instead of C0 [29.09.2018 21:48:29] resetting board [29.09.2018 21:48:29] trying to connect [29.09.2018 21:48:29] flush start [29.09.2018 21:48:29] setting serial port timeouts to 1 ms [29.09.2018 21:48:29] setting serial port timeouts to 1000 ms [29.09.2018 21:48:29] flush complete [29.09.2018 21:48:29] espcomm_send_command: sending command header [29.09.2018 21:48:29] espcomm_send_command: sending command payload [29.09.2018 21:48:29] serialport_receive_C0: AA instead of C0 [29.09.2018 21:48:29] trying to connect [29.09.2018 21:48:29] flush start [29.09.2018 21:48:29] setting serial port timeouts to 1 ms [29.09.2018 21:48:29] setting serial port timeouts to 1000 ms [29.09.2018 21:48:29] flush complete [29.09.2018 21:48:29] espcomm_send_command: sending command header [29.09.2018 21:48:29] espcomm_send_command: sending command payload [29.09.2018 21:48:29] read 0, requested 1 [29.09.2018 21:48:29] trying to connect [29.09.2018 21:48:29] flush start [29.09.2018 21:48:29] setting serial port timeouts to 1 ms [29.09.2018 21:48:29] setting serial port timeouts to 1000 ms [29.09.2018 21:48:29] flush complete [29.09.2018 21:48:29] espcomm_send_command: sending command header [29.09.2018 21:48:29] espcomm_send_command: sending command payload [29.09.2018 21:48:29] serialport_receive_C0: 31 instead of C0 [29.09.2018 21:48:29] resetting board [29.09.2018 21:48:29] trying to connect [29.09.2018 21:48:29] flush start [29.09.2018 21:48:29] setting serial port timeouts to 1 ms [29.09.2018 21:48:29] setting serial port timeouts to 1000 ms [29.09.2018 21:48:29] flush complete [29.09.2018 21:48:29] espcomm_send_command: sending command header [29.09.2018 21:48:29] espcomm_send_command: sending command payload [29.09.2018 21:48:29] serialport_receive_C0: 65 instead of C0 [29.09.2018 21:48:29] trying to connect [29.09.2018 21:48:29] flush start [29.09.2018 21:48:29] setting serial port timeouts to 1 ms [29.09.2018 21:48:29] setting serial port timeouts to 1000 ms [29.09.2018 21:48:29] flush complete [29.09.2018 21:48:29] espcomm_send_command: sending command header [29.09.2018 21:48:29] espcomm_send_command: sending command payload [29.09.2018 21:48:29] serialport_receive_C0: AA instead of C0 [29.09.2018 21:48:29] trying to connect [29.09.2018 21:48:29] flush start [29.09.2018 21:48:29] setting serial port timeouts to 1 ms [29.09.2018 21:48:29] setting serial port timeouts to 1000 ms [29.09.2018 21:48:29] flush complete [29.09.2018 21:48:29] espcomm_send_command: sending command header [29.09.2018 21:48:29] espcomm_send_command: sending command payload [29.09.2018 21:48:29] read 0, requested 1 [29.09.2018 21:48:29] warning: espcomm_sync failed [29.09.2018 21:48:29] error: espcomm_open failed [29.09.2018 21:48:29] error: espcomm_upload_mem failed [2018-09-29 21:48:29] STOPPED due to 2 errors! (try reset on the unit, then start a new flash attempt)

Grovkillen commented 6 years ago

I need to look at that. I got the same myself on Windows 10

flexiti commented 6 years ago

@Grovkillen

I need to look at that. I got the same myself on Windows 10

Any conclusions?

uzi18 commented 6 years ago

I realy dont think about esp32 is goal for now, even not all devs has got esp32 boards, we realy dont know if all available hardware is compatible. For me first resolve stack/heap problems and unconditional reboots, so esp8266 will be more stable. Next try too move with esp32 to have equal stuff there.

beicnet commented 6 years ago

I think that you need to stop with all new implemetations and to fix all 484 opened issues first. And without any new fancy requests. It's got little bit out of hand, don't you think so?

Grovkillen commented 6 years ago

We haven't added much new implementation last few months I think? We're wrapping it up for the release of the first stable 🙂

TD-er commented 6 years ago

@beicnet image I am really trying to fix as many issues as I can.

And like I said before, the ESP32 is also important for the development of the ESP8266, since the WROVER-dev-kit allows to perform debugging, using breakpoints and stuff. Also it is some kind of test for some situations to get some idea of the root cause of a reported issue.

uzi18 commented 6 years ago

@TD-er with esp32 You will get more and more issues ... so it will be never ending story.

flexiti commented 6 years ago

the price of esp32 has dropped significantly - today it is about 3 usd, has more ports, is faster, bluetoth etc. In my humble opinion, ESP8266 should be frozen (it has a lot of functionality) and I would concentrate on ESP32. ... and here, unfortunately, only experiments and experiments with ESP32 ;)

flexiti commented 6 years ago

@Grovkillen Flasher from "every night build" stop working on windows 10, Any conclusions? or no one upgrade from windows 10 ? ;)

uzi18 commented 6 years ago

@flexiti did You tried to flash blank.bin and nightly build one more time?

flexiti commented 6 years ago

@uzi18 loader is not working, has connection problems, see log above

beicnet commented 6 years ago

@TD-er.

I am really trying to fix as many issues as I can.

I know that you are trying, but the issue here is that there is 484 opened issues and the half of them is almost "Feature Request" and related stuffs, you can't please everyone, so, you need to STOP. and as @uzi18 mentioned before:

You will get more and more issues ... so it will be never ending story.

It will all fall apart soon, both repos!

uzi18 commented 6 years ago

@TD-er it is a good idea to. mark issues as bug or feature, to. have more precise view :)

TD-er commented 6 years ago

Do you have a suggestion on splitting the labels? I also tried to move issues to a "project" to keep track of reports.

The information is just too wide spread.

uzi18 commented 6 years ago

Wow, found that You labeled some issues, basically filter: is:issue is:open label:"Type: Bug" -label:"Platform: ESP32" gives only 108 hits, so not bad!!! and this: is:issue is:open label:"Type: Bug" label:"Platform: ESP32" only 6 Now it must be choosed what is priority - Critical/Serious and try to investigate/fix/workaround one by one. It is not a problem if we add more plugins if they don't break something what was working before.

TD-er commented 6 years ago

I did not label all issues. At the moment I added the labels, I did some searches to get a list of issues and applied the labels. And all new issues will be labeled within the first few days. (before they leave the first page)

My highest priority at this moment is to get it to work stable again. The only deviation was yesterday when I added a start of Sphinx/ReadTheDocs documentation to get some versioning into the documentation. (my mind wasn't really into programming due to some issues here in the past weeks)

uzi18 commented 5 years ago

small update (20190327 git snap) - hang on boot:

Auto-detected: /dev/ttyUSB0
"/home/users/linaja/.platformio/penv/bin/python2.7" "/home/users/linaja/.platformio/packages/tool-esptoolpy/esptool.py" --chip esp32 --port "/dev/ttyUSB0" --baud 115200 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 40m --flash_size detect 0x1000 /home/users/linaja/.platformio/packages/framework-arduinoespressif32/tools/sdk/bin/bootloader_dio_40m.bin 0x8000 /home/users/linaja/ESPEasy-mega_test/.pioenvs/esp32test_1M8_partition/partitions.bin 0xe000 /home/users/linaja/.platformio/packages/framework-arduinoespressif32/tools/partitions/boot_app0.bin 0x10000 .pioenvs/esp32test_1M8_partition/firmware.bin
esptool.py v2.6
Serial port /dev/ttyUSB0
Connecting........__
Chip is ESP32D0WDQ6 (revision 0)
Features: WiFi, BT, Dual Core, Coding Scheme None
MAC: 24:0a:c4:02:cc:0c
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 4MB
Compressed 16176 bytes to 10658...
Wrote 16176 bytes (10658 compressed) at 0x00001000 in 0.9 seconds (effective 137.8 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 144...
Wrote 3072 bytes (144 compressed) at 0x00008000 in 0.0 seconds (effective 1466.2 kbit/s)...
Hash of data verified.
Compressed 8192 bytes to 47...
Wrote 8192 bytes (47 compressed) at 0x0000e000 in 0.0 seconds (effective 7984.4 kbit/s)...
Hash of data verified.
Compressed 1666848 bytes to 949843...
Wrote 1666848 bytes (949843 compressed) at 0x00010000 in 83.6 seconds (effective 159.5 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...
================================================================================================= [SUCCESS] Took 152.36 seconds =================================================================================================
--- Miniterm on /dev/ttyUSB0  115200,8,N,1 ---
--- Quit: Ctrl+C | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:928
ho 0 tail 12 room 4
load:0x40078000,len:9280
load:0x40080400,len:5860
entry 0x40080698
�U64 : 

INIT : Booting version:  (ESP32 SDK v3.3-beta1-179-ge931fe9f5-dirty)
65 : INIT : Free RAM:293716
66 : INIT : Cold Boot - Restart Reason: CPU0: RTC Watch dog reset digital core and rtc module CPU1: for APP CPU, reseted by PRO CPU
67 : FS   : Mounting...
114 : CRC  : No program memory checksum found. Check output of crc2.py
125 : 

after 125 hangs

module is ESP-WROOM-32

TD-er commented 5 years ago

Is it the same as this here? https://github.com/letscontrolit/ESPEasy/issues/2403

uzi18 commented 5 years ago

Yes, it is same.

Grovkillen commented 5 years ago

I will close this, open if its still a valid issue.