Tasmota: Issue with 6.4.1.x dev builds and Core 2.3.0

[DavidFW1960]

IMPORTANT NOTICE
If you do not complete the template below it is likely that your issue will not be addressed. When providing information about your issue please be as extensive as possible so that it can be solved by as little as possible responses.

FAILURE TO COMPLETE THE REQUESTED INFORMATION WILL RESULT IN YOUR ISSUE BEING CLOSED

Describe the bug
_A clear and concise description of what the bug is._

I have been building my own firmware using core 2.3.0 prior to the 6.4.1 dev builds.
Compiling 6.4.1.x with core 2.3.0 has resulted in boot loops for me with a Sonoff SV and S22 switch. I have seen hardware watchdog and exception with various releases.

Yesterday with 6.4.1.19 I saw there was a pre-compiled dev build with core 2.3.0 so I downloaded that rather than using my own but the same result.

I can compile and flash based on core 2.5.0 but it has a lot of dropouts in a day. Ideally I'd go back to 6.3.0 but I like the hass status with 6.4.1.x dev builds and I use MQTT discovery in Tasmota and Home Assistant so it's not trivial to revert.

I did have a previous issue (https://github.com/arendst/Sonoff-Tasmota/issues/5172) that you guys closed down right away but it's not my dev environment. I used a different computer and had the same issue. There are also other reports of this exact same thing on the Home Assistant forum. If I didn't see the same issue with the precompiled binaries on the tasmota site I could believe that it is my environment but when they don't work either and cause a reboot every 7 seconds......

_Also, make sure these boxes are checked [x] before submitting your issue - Thank you!_

• [x ] _Searched the problem in issues and in the wiki_
• [ x] _Hardware used_ :
• [ x] _Development/Compiler/Upload tools used_ :
• [ x] _If a pre-compiled release or development binary was used, which one?_ :
• [ x] _You have tried latest release or development binaries?_ :
• [ x] _Provide the output of command_status 0 :

STATUS 0 OUTPUT HERE - DO NOT DELETE THE MARKERS ABOVE AND BELOW THIS LINE

11:48:34 CMD: status 0
11:48:34 MQT: sonoff1/stat/STATUS = {"Status":{"Module":1,"FriendlyName":["sonoff1-2914"],"Topic":"sonoff1","ButtonTopic":"0","Power":1,"PowerOnState":3,"LedState":1,"SaveData":1,"SaveState":1,"SwitchTopic":"0","SwitchMode":[0,0,0,0,0,0,0,0],"ButtonRetain":0,"SwitchRetain":0,"SensorRetain":0,"PowerRetain":1}}
11:48:34 MQT: sonoff1/stat/STATUS1 = {"StatusPRM":{"Baudrate":115200,"GroupTopic":"sonoffs","OtaUrl":"http://10.90.11.100:9541/data/firmwares/sonoff.bin","RestartReason":"Software/System restart","Uptime":"1T03:07:54","StartupUTC":"2019-02-25T21:40:40","Sleep":50,"CfgHolder":4617,"BootCount":21,"SaveCount":363,"SaveAddress":"F6000"}}
11:48:34 MQT: sonoff1/stat/STATUS2 = {"StatusFWR":{"Version":"6.4.1.19(sonoff)","BuildDateTime":"2019-02-26T08:35:36","Boot":31,"Core":"2_5_0","SDK":"3.0.0-dev(c0f7b44)"}}
11:48:34 MQT: sonoff1/stat/STATUS3 = {"StatusLOG":{"SerialLog":2,"WebLog":2,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["WILLIAMS",""],"TelePeriod":300,"Resolution":"558180C0","SetOption":["000A8029","280500000100000000000000000000000000","00000200"]}}
11:48:34 MQT: sonoff1/stat/STATUS4 = {"StatusMEM":{"ProgramSize":493,"Free":508,"Heap":24,"ProgramFlashSize":1024,"FlashSize":1024,"FlashChipId":"14405E","FlashMode":3,"Features":["00000809","0F402790","04000000","00000096","000000C0"]}}
11:48:34 MQT: sonoff1/stat/STATUS5 = {"StatusNET":{"Hostname":"sonoff1-2914","IPAddress":"10.90.11.24","Gateway":"10.90.11.1","Subnetmask":"255.255.255.0","DNSServer":"10.90.11.1","Mac":"2C:3A:E8:4E:6B:62","Webserver":2,"WifiConfig":2}}
11:48:34 MQT: sonoff1/stat/STATUS6 = {"StatusMQT":{"MqttHost":"10.90.11.100","MqttPort":1883,"MqttClientMask":"DVES_%06X","MqttClient":"DVES_4E6B6262","MqttUser":"mqttuser","MqttType":1,"MqttCount":2,"MAX_PACKET_SIZE":1000,"KEEPALIVE":15}}
11:48:34 MQT: sonoff1/stat/STATUS7 = {"StatusTIM":{"UTC":"Wed Feb 27 00:48:34 2019","Local":"Wed Feb 27 11:48:34 2019","StartDST":"Sun Oct 06 02:00:00 2019","EndDST":"Sun Apr 07 02:00:00 2019","Timezone":99,"Sunrise":"06:40","Sunset":"19:33"}}
11:48:34 MQT: sonoff1/stat/STATUS10 = {"StatusSNS":{"Time":"2019-02-27T11:48:34"}}
11:48:34 MQT: sonoff1/stat/STATUS11 = {"StatusSTS":{"Time":"2019-02-27T11:48:34","Uptime":"1T03:07:54","Vcc":3.447,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"POWER":"ON","Wifi":{"AP":1,"SSId":"WILLIAMS","BSSId":"E0:28:6D:76:2B:AE","Channel":6,"RSSI":98,"LinkCount":1,"Downtime":"0T00:00:04"}}}

This is of course with 6.4.1.19 with core 2.5.0

To Reproduce
_Steps to reproduce the behavior:_

Load any dev version of 2.3.0 core into S2 or Sonoff SV

Expected behavior
_A clear and concise description of what you expected to happen._

Stable system...

Screenshots
_If applicable, add screenshots to help explain your problem._

Additional context
_Add any other context about the problem here._

(Please, remember to close the issue when the problem has been addressed)

[Jason2866]

Your status 0 is from a build with core 2.5.0 ?

[ascillato2]

Hi,

Compiling 6.4.1.x with core 2.3.0 has resulted in boot loops for me with a Sonoff SV and S22 switch

Please, can you post the status 0 of your problematic device with core 2.3.0?

There are also other reports of this exact same thing on the Home Assistant forum.

Can you post the link?

Before flashing, have you done a full flash erase with esptool.py as explained in the wiki?

[DavidFW1960]

I can’t get a status 0 with core 2.3.0 because it doesn’t stay up long enough - it reboots every 7 seconds. Is there another way I can do that?

Yesterday I did a full flash erase via a FTDI/USB and flashed the pre-compiled binary 6.4.1.19 for 2.3.0 core. It didn’t help.

I also tried a reset 5 and OTA flashing. Only core 2.5.0 is giving me any kind of stability.

I’ll get the forum links and post here.

[DavidFW1960]

https://community.home-assistant.io/t/sonoff-tasmota-started-regularly-showing-unavailable-on-home-assistant/90157/2
Also here but not specific to this
https://community.home-assistant.io/t/how-reliable-are-the-tasmotaed-sonoffs-in-the-long-run-share-your-experience-and-or-configuration-please/92345/9

[Naqua]

Could it be that you have a mesh wifi network at home with multiple accesspoints wich have the same SSID? Just spend a awful lot of time with other firmware with core 2.3.0 crashing evey 6-7 secs because of that. Try switching of the mesh and create a single ap. Somehow core 2.3.0 cant handle mesh well.

[DavidFW1960]

I do have mesh but have had for months with core 2.3.0.... It’s worth trying though... I can try that as I have another router here..

[GreyMarvel]

I think your error is related if not identical to our error
https://github.com/arendst/Sonoff-Tasmota/issues/5335

I updated to v6.4.1 because I wanted the discovery in home assistant and ideally I would go back to 6.3.0 but it's unsupported in the latest build of home assistant however 6.3.17 would work with the later build and manual inserting in the config .yaml file (according to the wiki ) .

I too just tried the 2.3 core on 6.4.1 and the same problem occured boot loops every several seconds I had to flash manually to break it .

[DavidFW1960]

I too just tried the 2.3 core on 6.4.1 and the same problem occured boot loops every several seconds I had to flash manually to break it .

I can still do an OTA back to 2.5.0 core even though it does this boot looping. I think if you initiate the firmware 'upgrade' OTA as long as it starts... eventually after a few boot loops it actually does it and it's reasonably stable again. I haven't been forced to flash via wire because of this yet although I did use it to clear flashram and espytool to upload firmware with latest pre-compiled bin 2.3.0 core..

[DavidFW1960]

Another HA thread about core issues...

https://community.home-assistant.io/t/advice-on-what-esp8266-firmware-to-use-on-the-sonoffs-espurna-or-esphome-or-espeasy-migrating-from-tasmota/103103/11

[Jason2866]

Try latest prebuild dev versions with core 2.3.0. Before erase flash with esptool.py erase_flash
Flash http://thehackbox.org/tasmota/020300/sonoff.bin with esptool.py
Dont use other flash tools. We tested different flasher tools other can sometimes fail which results in weired issues.
Latest dev versions i have tested with a Sonoff S20 and ALL core versions do work without a WDT or a exception
16:37:09 MQT: tele/sonoff-53CF5F/STATE = {"Time":"2019-03-08T16:37:09","Uptime":"0T05:36:27","Vcc":2.718,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"Wifi":{"AP":1,"SSId":"Jason_Home_WLAN","BSSId":"00:A0:57:2A:BD:19","Channel":13,"RSSI":98,"LinkCount":1,"Downtime":"0T00:00:05"}}

[thxthx0]

Hi, the Problem still exists and is related to
Core 2.3.0 and "Setoption19 on", as result 'Exceptions'

It was mentioned at discord #issues days ago too,
by user sunnybam 02/23/2019

[DavidFW1960]

Thanks for the confirmation. His issue is identical to mine and he also tried the precompiled binary with the same result.... and he had success with 6.4.1.15.... last one I had success with was 6.4.1.12 and core 2.3.0. I also am using 2.5.0 core now but it's unstable compared to core 2.3.0 and it seems the further the distance from the AP, the more wifi/HA dropouts. Ones real close to the AP don't drop out at all. But I didn't get any dropouts with core 2.3.0.

[Jason2866]

So it seems it is Setoption 19 related. Could be Free Ram is for this command not enough with core 2.3.0
If this is the fact the command isnt possible with this core and has to be removed
Maybe latest optimizations which frees a little Ram Theo did today helps.
Just try latest .21 build

[DavidFW1960]

I don't know about RAM being the issue. I have almost all options turned off and my binaries are around 480kb and 24kb RAM free..

[Jason2866]

Have you tried latest dev .21 (precompiled) build?
Some HA users gave us feedback (in Discord) SetOption 19 with Core 2.3.0 does work (again).

[arendst]

On core 2.3.0 and latest dev it fails with SetOption19 1 probably caused by a string assigned to a %d or the other way round.

15:03:32 MQT: wemos2/tele/INFO1 = {"Module":"Generic","Version":"6.4.1.21(sonoff)","FallbackTopic":"cmnd/DVES_15568C_fb/","GroupTopic":"sonoffs"}
15:03:32 MQT: wemos2/tele/INFO2 = {"WebServerMode":"Admin","Hostname":"wemos2","IPAddress":"192.168.2.191"}
15:03:32 MQT: wemos2/tele/INFO3 = {"RestartReason":"Fatal exception:29 flag:2 (EXCEPTION) epc1:0x402415e3 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000"}
15:03:32 MQT: wemos2/stat/RESULT = {"POWER":"OFF"}
15:03:32 MQT: wemos2/stat/POWER = OFF
15:03:34 MQT: homeassistant/light/15568C_LI_1/config =  (retained)

Exception (29):
epc1=0x402415e3 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000000 depc=0x00000000

ctx: cont 
sp: 3fff47b0 end: 3fff4f00 offset: 01a0

The problem is in xdrv_12_home_assistant.ino, my favourite part of Tasmota usually managed by @emontnemery. I'll have a look...

[emontnemery]

@arendst I can have a look today if you want?

[arendst]

@emontnemery hold on. I'm looking into it now. Let you know If I fail.

[arendst]

@emontnemery what seems to solve the problem is changing this:

int try_snprintf_P(char *s, size_t n, const char *format, ... )
{
  va_list args;
  va_start(args, format);
  int len = vsnprintf_P(NULL, 0, format, args);
  if (len >= n) {

into this

int try_snprintf_P(char *s, size_t n, const char *format, ... )
{
  va_list args;
  va_start(args, format);
  char dummy[2];
  int len = vsnprintf_P(dummy, 1, format, args);
  if (len >= n) {

[arendst]

@DavidFW1960 give it a try.

[emontnemery]

@arendst Oh, that's a bug in vsnprintf_P then; passing a null pointer is allowed according to spec when size is 0..
Anyhow, is there a nice tool these days to map ESP exception data to function (and ideally file line)?

[arendst]

There has always been this optional EspExceptionDecoder tool with Arduino IDE to help in analyzing exception data.

In the tasmota platformio.ini config file is a default enabled option to make a map file during compilation which I used to figure out where the exception happened. No straight forward action though and you'll need background knowledge but it's better than nothing.

[emontnemery]

Apparently there is a tool xtensa-lx106-elf-addr2line for mapping address to file and line, here's a java wrapper for it: https://github.com/littleyoda/EspStackTraceDecoder
(This is probably what the Arduino IDE plugin uses as well)

[thxthx0]

Thanks a lot. From my side I can confirm that it works perfect again. 👍👍👍

[DavidFW1960]

I'm going to grab the latest dev and compile 2.3.0 now and I'll let you know..... Thanks everyone for tracking this down....

[DavidFW1960]

OK!!!
Compiled with core 2.3.0 and no more boot loops. I'm putting it on my most troublesome switches with core 2.5.0.... lets see how that performs now. I assume this fix does not affect 2.5.0 at all?

Thanks everyone for fixing this!