debug options change code behaviour on certain boards

[philbowles]

Basic Infos

• [ x] This issue complies with the issue POLICY doc.
• [ x] I have read the documentation at readthedocs and the issue is not addressed there.
• [ x] I have tested that the issue is present in current master branch (aka latest git).
• [ x] I have searched the issue tracker for a similar issue.
• [ x] If there is a stack dump, I have decoded it.
• [x ] I have filled out all fields below.

Platform

• Hardware: Various (see text)

• Core Version: SDK:2.2.1(cfd48f3)/Core:2.5.2=20502000/lwIP:STABLE-2_1_2_RELEASE/glue:1.1-7-g82abda3/BearSSL:a143020

• Development Env: Arduino IDE 1.8.9

• Operating System: Windoze10

Settings in IDE

Various (see text) but "working" example is:

Problem Description

I have come across some very "odd" behaviour which may be related to / shed light on e.g. #5784 and/or #5736

I have a body of code designed to run on a variety of boards. It is 4500+ lines and therefore impractical to include. However , I don't think it is all that relevant, since it runs fine on:

• Wemos D1 mini 4M/1M
• Wemos D1 mini lite (esp8285) 1M/128K
• nodeMCU 0.9 4M/1M
• SONOFF SV 1M/128K
• SONOFF S20 1M/128K
• ESP-01S 1M/128K

The code relies on a previous successful connect (goes into AP mode if none) and monitors WiFi events to "bring up" webserver, MQTT client on "got IP". It has various #defines to tailor various H/W differences, but the core wifi / webserver / mqtt functionality is(should be!) same for all devices.

Since upgrading to 2.5.0 (and through 2.5.2) I have had serious problems with the exact same code on SONOFF Basic(1M/128K).

If I compile it with options as show above, it runs, but incredibly slowly. The home webpage which takes about 1-2s max on all other devices can take 30-40 seconds to load, causing other
dependent and/or time critical functions to fail. One time out of three or four it will manage to load the webUI to the point where it is functional, but slower than drying paint...

If I compile it WITHOUT the debug options a few seconds later (i.e. everything including the ambient temperature is identical) it simply refuses to connect:
(In my debug printf, T=millis() FH=ESP.getFreeHeap())

 ets Jan  8 2013,rst cause:1, boot mode:(3,6)

load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
v8b899c12
~ld
T=332 SYNCHROSTART LaPique XXXXXXXX  192.168.1.4 1883   lwt 
SDK:2.2.1(cfd48f3)/Core:2.5.2=20502000/lwIP:STABLE-2_1_2_RELEASE/glue:1.1-7-g82abda3/BearSSL:a143020
Mode: STA
PHY mode: N
Channel: 1
AP id: 0
Status: 1
Auto connect: 1
SSID (7): LaPique
Passphrase (8): XXXXXXXX
BSSID set: 0
getAutoReconnect: 1
getListenInterval: 0
isSleepLevelMax: 0
getPersistent: 1
isConnected: 0
macAddress: 5C:CF:7F:F4:9D:4B
T=739 Esparto SONOFF Firmware example C:\Users\phil\Desktop\DEV\examples3zero\wifi_mqtt\SONOFF_BASIC_Firmware\SONOFF_BASIC_Firmware.ino
FH=29792 WIFI_EVENT_STAMODE_DISCONNECTED
FH=29792 WIFI_EVENT_STAMODE_DISCONNECTED
FH=29792 WIFI_EVENT_STAMODE_DISCONNECTED
FH=29792 WIFI_EVENT_STAMODE_DISCONNECTED
FH=29792 WIFI_EVENT_STAMODE_DISCONNECTED
FH=29792 WIFI_EVENT_STAMODE_DISCONNECTED
FH=29792 WIFI_EVENT_STAMODE_DISCONNECTED
FH=29792 WIFI_EVENT_STAMODE_DISCONNECTED

If I copy this compiled binary and manually upload it to the SONOFF SV, its runs flawlessly. If I compile it to the SV, an ESP-01S or any other device, it runs flawlessly.

It is only the Basic(old-style V1) that exhibits this problem. I have 3 and they all behave exactly the same way, having previously been installed with earlier versions of my software and working fine for well over a year.

Interestingly is is not always the WIFI_EVENT_STAMODE_DISCONNECTED loop that prevents connection. On other occasions is appears to not receive the ...GOT_IP event. On others it kept getting "no LaPique found reconnect after 1s" when the SSID was indeed present and functional
(thhe only half-decent explanation I could find for that was https://bbs.espressif.com/viewtopic.php?t=10173)

Other times it was:

bcn_timout,ap_probe_send_start
ap_probe_send over, rest wifi status to disassoc

I found #5083 and set WiFi.mode(WIFI_NONE_SLEEP) but it made no difference.

Thus although the exact behaviour is non-deterministic, the one thing it WILL NOT do is make a valid connection. This happens with both sdk 2.2.1, sdk 2.2.2
It also happens with all variations of lwip v2 (IPV4)

I have tried all permutations of flash erasing, I even found a blank_1M.bin and manually uploaded that to clear the flash...nothing makes any difference, the code simply will no run on SONOFF_BASIC without the debug messages in, and even then its unusable.

My experience tells me this has to be some kind of timing problem - what else can that debug code be changing? But why only apparent on the "basic" are its RF calibration bytes in a different place in RAM?

Needless to say I am at my wits' end..having spent weeks trying to track this down...

[d-a-v]

To summarize:

• this issue only happens with the sonoff basic V1, this sketch and core >= 2.5.x including core2.5.2+sdk2.2.1
  (without debug mode)
• other boards have no problem with this sketch (with 2.5.2)
• "erase flash" option has no effect
• it is an esp8266 not esp8285

Some questions:

• Do the sonoff basic V1 and this sketch work together with core 2.4.2 ?

• Have you tried to enable PUYA flash support in platform.local.txt:

compiler.c.extra_flags=-DPUYA_SUPPORT=1
compiler.cpp.extra_flags={compiler.c.extra_flags}

• Are you using the generic esp8266 board model ?

• Are you using DOUT flash mode ?

Comments:

But why only apparent on the "basic" are its RF calibration bytes in a different place in RAM?

The location is defined by flash size (tools/sdk/ld). What is apparent and where ?

[philbowles]

Q1 I have changed a lot of things since I used 2.4.2. I really don't want to have to revert to it if I can avoid it. I am unable to comment re 2.4.2.
Q2 I have no clue what PUYA support is nor what the platform.local.txt file does nor where it is located. I shall research them now

As per image included in OP:
board = Generic , Flash mode QIO(fast)

Your summary is broadly correct. (its still an issue WITH debug mode, just not terminal!)

[philbowles]

Still trying to understand PUYA . but if it helps. the flash chip on the Basics are XT BN25F08, same as on the SVs and on my S20s which I forgot to mention, which also work just fine.

[d-a-v]

XT BN25F08

So it is not a PUYA flash chip and this workaround is not needed (platform.local.txt is an arduino IDE file, PUYA_SUPPORT is a C define enabling the workaround).

Are you able to run WiFi examples on the faulty-with-your-sketch board ?

Can you try with DOUT instead of QIO ? (sorry I hadn't seen the image)

[philbowles]

Recompiled with DOUT, no change.

Ran a totally different minimal WiFi sketch on the Basic...runs perfectly...
Which unfortunately tends to suggest there's something in my code - but I can't understand how it works on every other board!

I'm going to revert to 2.4.2 and see what happens

[philbowles]

The 2.4.2 behaviour is different: We no longer get the STA_MODE_DISCONNECTED loop:

 ets Jan  8 2013,rst cause:1, boot mode:(3,6)

load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
vbb28d4a3
~ld
T=59 SYNCHROSTART LaPique XXXXXXXX  192.168.1.4 1883   lwt 
SDK:2.2.1(cfd48f3)/Core:2.4.2/lwIP:2.0.3(STABLE-2_0_3_RELEASE/glue:arduino-2.4.1-13-g163bb82)/BearSSL:6d1cefc
Mode: STA
PHY mode: N
Channel: 1
AP id: 0
Status: 1
Auto connect: 1
SSID (7): LaPique
Passphrase (8): XXXXXXXX
BSSID set: 0
getAutoReconnect: 1
getPersistent: 1
isConnected: 0
macAddress: 5C:CF:7F:F4:9D:4B
T=193 Esparto SONOFF Firmware example C:\Users\phil\Desktop\DEV\examples3zero\wifi_mqtt\SONOFF_BASIC_Firmware\SONOFF_BASIC_Firmware.ino
FH=25088 _wifiEvent 2 Qs=1
FH=23976 _wifiEvent 0 Qs=1
WIFI_EVENT_STAMODE_GOT_IP 3 192.168.1.103
T=9650 GOT IP LaPique [192.168.1.1] as 192.168.1.103 ESPARTO-F49D4B

But the behaviour is equally bizarre:
The WiFi is again so slow its like its running in glue, and took four or five attempts to load the web page. Once it HAD done so, the WiFi "sprang to life" and appeared to work normally, i.e webUi fully responsive.

After a couple of reboots to confirm all was well, it stopped responding. My own debug messages show connected with an IP but pings timed out and no webserver visible.

Then it went into a slower version of the 2.5.2 behaviour:

WIFI_EVENT_STAMODE_GOT_IP 3 192.168.1.103
T=133093 GOT IP LaPique [192.168.1.1] as 192.168.1.103 ESPARTO-F49D4B
FH=16992 WIFI_EVENT_STAMODE_DISCONNECTED
FH=15992 _wifiEvent 0 Qs=0
WIFI_EVENT_STAMODE_GOT_IP 3 192.168.1.103
T=209318 GOT IP LaPique [192.168.1.1] as 192.168.1.103 ESPARTO-F49D4B
FH=15064 WIFI_EVENT_STAMODE_DISCONNECTED
FH=14064 _wifiEvent 0 Qs=1
WIFI_EVENT_STAMODE_GOT_IP 3 192.168.1.103
T=245487 GOT IP LaPique [192.168.1.1] as 192.168.1.103 ESPARTO-F49D4B
FH=15088 WIFI_EVENT_STAMODE_DISCONNECTED
FH=14088 _wifiEvent 0 Qs=0

While actually getting an IP address in between each, unlike 2.5.2

But when compiled with debug + WiFi, we get

 ets Jan  8 2013,rst cause:1, boot mode:(3,6)

load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
vbb28d4a3
~ld

SDK:2.2.1(cfd48f3)/Core:2.4.2/lwIP:2.0.3(STABLE-2_0_3_RELEASE/glue:arduino-2.4.1-13-g163bb82)/BearSSL:6d1cefc
T=129 SYNCHROSTART LaPique XXXXXXXX  192.168.1.4 1883   lwt 
SDK:2.2.1(cfd48f3)/Core:2.4.2/lwIP:2.0.3(STABLE-2_0_3_RELEASE/glue:arduino-2.4.1-13-g163bb82)/BearSSL:6d1cefc
Mode: STA
PHY mode: N
Channel: 1
AP id: 0
Status: 1
Auto connect: 1
SSID (7): LaPique
Passphrase (8): XXXXXXXX
BSSID set: 0
getAutoReconnect: 1
getPersistent: 1
isConnected: 0
macAddress: 5C:CF:7F:F4:9D:4B

SDK:2.2.1(cfd48f3)/Core:2.4.2/lwIP:2.0.3(STABLE-2_0_3_RELEASE/glue:arduino-2.4.1-13-g163bb82)/BearSSL:6d1cefc
T=764 Esparto SONOFF Firmware example C:\Users\phil\Desktop\DEV\examples3zero\wifi_mqtt\SONOFF_BASIC_Firmware\SONOFF_BASIC_Firmware.ino
wifi evt: 2
FH=25568 _wifiEvent 2 Qs=1
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 3
cnt 

connected with LaPique, channel 6
dhcp client start...
wifi evt: 0
FH=24408 _wifiEvent 0 Qs=1
ip:192.168.1.103,mask:255.255.255.0,gw:192.168.1.1
wifi evt: 3
WIFI_EVENT_STAMODE_GOT_IP 3 192.168.1.103
T=3680 GOT IP LaPique [192.168.1.1] as 192.168.1.103 ESPARTO-F49D4B
pm open,type:2 0
T=21652 FH=18720 _server.onClient 3fff78dc 192.168.1.20
T=21913 FH=18320 _server.onClient 3fff7e64 192.168.1.20
T=22168 FH=18696 _server.onClient 3fff795c 192.168.1.20
T=44968 FH=18736 _server.onClient 3fff78dc 192.168.1.20
T=48570 FH=18096 _server.onClient 3fff7b54 192.168.1.20
T=49991 FH=18680 _server.onClient 3fff7b1c 192.168.1.20
T=51978 FH=13224 _server.onClient 3fff8f3c 192.168.1.20
sl
scandone
usl
T=57233 FH=17696 _server.onClient 3fff7b74 192.168.1.20
T=86608 FH=15752 _server.onClient 3fff8494 192.168.1.20
T=117088 FH=15928 _server.onClient 3fff8444 192.168.1.20
T=147678 FH=17720 _server.onClient 3fff76fc 192.168.1.20

And it works perfectly:

[philbowles]

For the record, still on 2.4.2. exact same code as above, debug + wifi options removed, recompiled onto ESP-01S webUI response is practically instantaneous, i.e. code working 100% as expected.

What is it about the basic that causes such wifi problems and is also different between 2.4.2 and 2.5.2?

[philbowles]

Further info: I compiled it for a generic esp8285 with all the rest of the settings the same and it works fine. If I compile it as a generic esp8266 it runs like a dog, fails, locks up, wdt resets etc etc.

I'm now going through the compiler options with a fine tooth comb to see what might be different

[d-a-v]

esp8285 is supposed to be an esp8266 with DOUT forced, only 1MB (no choice), default fw (2.2.1, no choice), flash frequency forced to 40.
It also sets gpio9 and 10 as inputs.

What is your esp01s flash size as shown by esptool.py ?

[mindstormsking]

I can confirm similar behaviour.
My (also quite large) sketch does GET requests. Normally, the website doesn't return data and everything works fine. If an exception occurs on the website, the sketch crashes during normal operation, while it shouldn't and there is no reason to crash in my code. (When the WiFiClient is out-of-scope and gets destroyed)

Exception 9: LoadStoreAlignmentCause: Load or store to an unaligned address
PC: 0x4021467e: tcp_output at core/tcp_out.c line 1262
EXCVADDR: 0x00000271

Decoding stack results
0x401001c0: millis() at \esp8266\hardware\esp8266\2.5.2\cores\esp8266\core_esp8266_wiring.cpp line 186
0x40202430: ClientContext::wait_until_sent(int) at \esp8266\hardware\esp8266\2.5.2\libraries\ESP8266WiFi\src/include/ClientContext.h line 328
0x40206c10: _umm_free(void*) at \esp8266\hardware\esp8266\2.5.2\cores\esp8266\umm_malloc\umm_malloc.cpp line 1304
0x40202961: WiFiClient::flush(unsigned int) at \esp8266\hardware\esp8266\2.5.2\libraries\ESP8266WiFi\src\WiFiClient.cpp line 318
0x4020299d: WiFiClient::stop(unsigned int) at \esp8266\hardware\esp8266\2.5.2\libraries\ESP8266WiFi\src\WiFiClient.cpp line 326
0x402029c4: WiFiClient::stop() at \esp8266\hardware\esp8266\2.5.2\libraries\ESP8266WiFi\src/WiFiClient.h line 76
0x40205ada: delay(unsigned long) at \esp8266\hardware\esp8266\2.5.2\cores\esp8266\core_esp8266_wiring.cpp line 57
0x40203491: HTTPClient::~HTTPClient() at \esp8266\hardware\esp8266\2.5.2\libraries\ESP8266HTTPClient\src\ESP8266HTTPClient.cpp line 131
0x402011e4: getURL(String&) at MySketch.ino line 62
0x40204424: String::invalidate() at \esp8266\hardware\esp8266\2.5.2\cores\esp8266/WString.h line 267
0x40201602: setup() at MySketch.ino line 236
0x402055a0: loop_wrapper() at \esp8266\hardware\esp8266\2.5.2\cores\esp8266\core_esp8266_main.cpp line 122

However, the sketch behaves normally (nicely catching the website exception without crashing the microcontroller) if I enable a debug option, even if it is one that I don't use (eg, OTA). Compiling for ESP8285 also solves my problem.

Hardware: ESP12F
Core Version: 2.5.2
Development Env: Arduino IDE 1.8.9
Operating System: Win 7

Settings when problem occurs:
Upload speed: 115200
CPU Frequency: 80MHz
Crystal Frequency: 26MHz
Flash Size: 512k (no SPIFFS)
Reset Method: ck
Debug port: Disabled
Debug level: none
lwIP Variant: v2 Lower Memory
VTables: flash
Exceptions: Disabled
Buildin led: 2
Erase flash: only sketch (but also tried full)
Espressif FW: nonos SDK 2.2.1 (legacy)
SSL Support: All SSL Ciphers
Port: COM4

[TD-er]

It sounds a bit like stuff has been optimized which may put a higher strain on the flash.
Can you switch the flash frequency to 40 MHz?

About the crash on failing GET requests.
Are those WDT reboots?
If so, you can also set a timeout on the WiFiClient object you use to make the connection.
For example a few-100 msec.
And do call delay(0) between attempts.

[mindstormsking]

I tried the timeout and the delay already, but they don't help, the exception is just delayed.
It's not the GET request that fails, the exception is thrown when the WiFiClient object gets destroyed, when it is no longer needed. But apparently only when it just received a few hundred bytes or so.

How can I change the flash frequency?

[TD-er]

I tried the timeout and the delay already, but they don't help, the exception is just delayed.
It's not the GET request that fails, the exception is thrown when the WiFiClient object gets destroyed, when it is no longer needed. But apparently only when it just received a few hundred bytes or so.

I guess that's probably a bug on its own.
Sounds a bit like writing to some memory that's already de-allocated, or a callback to a non existing function.

About the flash frequency.
In PlatformIO, you can use this: espressif8266.html#flash-frequency
I guess in Arduino IDE you can somehow edit it somewhere in a menu?

[mindstormsking]

Sounds a bit like writing to some memory that's already de-allocated, or a callback to a non existing function.
Yes, it does. But it doesn't show this behaviour when I enable any Debug level, which made me come across this issue.

I will try to find another flash frequency after my holidays.

[d-a-v]

@mindstormsking can you repeat the bug with master git version of the core ?
and also enable the OOM debug option ?
and possibly show the sketch ?

[earlephilhower]

Debug mode reduces the free heap somewhat, due to the memory manager adding poison blocks around each internal memory segment. So it's very possible for a sketch to run out of memory and crash if allocations aren't checked.

[mindstormsking]

@earlephilhower I understand, but the thing is that the debug mode actually solves the problem. Compiling for an ESP8285 also solves the problem...

@d-a-v I'll see what I can do, after my holidays.

[mindstormsking]

@TD-er: The problem occurs with a flash frequency of 40MHz as well as 80MHz.
The chip outputs "rst cause:2, boot mode:(3,2)", fatal exception...

@d-a-v: When I enable OOM, the problem does not occur anymore. The problem does occur when I use the Git Master branch, so that doesn't solve the problem.

I compared the verbose output of compiling for a 8266 and 8285 and noticed that different build options are used, although they are not changed in the Arduino GUI. Could the problem lay there?

C:\Program Files (x86)\Arduino\arduino-builder -dump-prefs -logger=machine -hardware C:\Program Files (x86)\Arduino\hardware -hardware C:\Users\User\AppData\Local\Arduino15\packages -tools C:\Program Files (x86)\Arduino\tools-builder -tools C:\Program Files (x86)\Arduino\hardware\tools\avr -tools C:\Users\User\AppData\Local\Arduino15\packages -built-in-libraries C:\Program Files (x86)\Arduino\libraries -libraries C:\Users\User\Documents\Arduino\libraries -fqbn=esp8266:esp8266:generic:xtal=80,vt=flash,exception=disabled,ssl=all,ResetMethod=ck,CrystalFreq=26,FlashFreq=40,FlashMode=dout,eesz=512K,led=2,sdk=nonosdk221,ip=lm2f,dbg=Disabled,lvl=None____,wipe=none,baud=115200 -ide-version=10809 -build-path C:\Users\User\AppData\Local\Temp\arduino_build_44452 -warnings=none -prefs=build.warn_data_percentage=75 -prefs=runtime.tools.mkspiffs.path=C:\Users\User\AppData\Local\Arduino15\packages\esp8266\tools\mkspiffs\2.5.0-3-20ed2b9 -prefs=runtime.tools.mkspiffs-2.5.0-3-20ed2b9.path=C:\Users\User\AppData\Local\Arduino15\packages\esp8266\tools\mkspiffs\2.5.0-3-20ed2b9 -prefs=runtime.tools.xtensa-lx106-elf-gcc.path=C:\Users\User\AppData\Local\Arduino15\packages\esp8266\tools\xtensa-lx106-elf-gcc\2.5.0-3-20ed2b9 -prefs=runtime.tools.xtensa-lx106-elf-gcc-2.5.0-3-20ed2b9.path=C:\Users\User\AppData\Local\Arduino15\packages\esp8266\tools\xtensa-lx106-elf-gcc\2.5.0-3-20ed2b9 -prefs=runtime.tools.python.path=C:\Users\User\AppData\Local\Arduino15\packages\esp8266\tools\python\3.7.2-post1 -prefs=runtime.tools.python-3.7.2-post1.path=C:\Users\User\AppData\Local\Arduino15\packages\esp8266\tools\python\3.7.2-post1 -verbose C:\Users\User\Documents\Arduino\Sketch\Sketch.ino
C:\Program Files (x86)\Arduino\arduino-builder -compile -logger=machine -hardware C:\Program Files (x86)\Arduino\hardware -hardware C:\Users\User\AppData\Local\Arduino15\packages -tools C:\Program Files (x86)\Arduino\tools-builder -tools C:\Program Files (x86)\Arduino\hardware\tools\avr -tools C:\Users\User\AppData\Local\Arduino15\packages -built-in-libraries C:\Program Files (x86)\Arduino\libraries -libraries C:\Users\User\Documents\Arduino\libraries -fqbn=esp8266:esp8266:generic:xtal=80,vt=flash,exception=disabled,ssl=all,ResetMethod=ck,CrystalFreq=26,FlashFreq=40,FlashMode=dout,eesz=512K,led=2,sdk=nonosdk221,ip=lm2f,dbg=Disabled,lvl=None____,wipe=none,baud=115200 -ide-version=10809 -build-path C:\Users\User\AppData\Local\Temp\arduino_build_44452 -warnings=none -prefs=build.warn_data_percentage=75 -prefs=runtime.tools.mkspiffs.path=C:\Users\User\AppData\Local\Arduino15\packages\esp8266\tools\mkspiffs\2.5.0-3-20ed2b9 -prefs=runtime.tools.mkspiffs-2.5.0-3-20ed2b9.path=C:\Users\User\AppData\Local\Arduino15\packages\esp8266\tools\mkspiffs\2.5.0-3-20ed2b9 -prefs=runtime.tools.xtensa-lx106-elf-gcc.path=C:\Users\User\AppData\Local\Arduino15\packages\esp8266\tools\xtensa-lx106-elf-gcc\2.5.0-3-20ed2b9 -prefs=runtime.tools.xtensa-lx106-elf-gcc-2.5.0-3-20ed2b9.path=C:\Users\User\AppData\Local\Arduino15\packages\esp8266\tools\xtensa-lx106-elf-gcc\2.5.0-3-20ed2b9 -prefs=runtime.tools.python.path=C:\Users\User\AppData\Local\Arduino15\packages\esp8266\tools\python\3.7.2-post1 -prefs=runtime.tools.python-3.7.2-post1.path=C:\Users\User\AppData\Local\Arduino15\packages\esp8266\tools\python\3.7.2-post1 -verbose C:\Users\User\Documents\Arduino\Sketch\Sketch.ino`

Versus:

C:\Program Files (x86)\Arduino\arduino-builder -dump-prefs -logger=machine -hardware C:\Program Files (x86)\Arduino\hardware -hardware C:\Users\User\AppData\Local\Arduino15\packages -tools C:\Program Files (x86)\Arduino\tools-builder -tools C:\Program Files (x86)\Arduino\hardware\tools\avr -tools C:\Users\User\AppData\Local\Arduino15\packages -built-in-libraries C:\Program Files (x86)\Arduino\libraries -libraries C:\Users\User\Documents\Arduino\libraries -fqbn=esp8266:esp8266:esp8285:xtal=80,vt=flash,exception=disabled,ssl=all,ResetMethod=ck,CrystalFreq=26,eesz=1M,led=2,ip=lm2f,dbg=Disabled,lvl=None____,wipe=none,baud=115200 -ide-version=10809 -build-path C:\Users\User\AppData\Local\Temp\arduino_build_44452 -warnings=none -prefs=build.warn_data_percentage=75 -prefs=runtime.tools.mkspiffs.path=C:\Users\User\AppData\Local\Arduino15\packages\esp8266\tools\mkspiffs\2.5.0-3-20ed2b9 -prefs=runtime.tools.mkspiffs-2.5.0-3-20ed2b9.path=C:\Users\User\AppData\Local\Arduino15\packages\esp8266\tools\mkspiffs\2.5.0-3-20ed2b9 -prefs=runtime.tools.xtensa-lx106-elf-gcc.path=C:\Users\User\AppData\Local\Arduino15\packages\esp8266\tools\xtensa-lx106-elf-gcc\2.5.0-3-20ed2b9 -prefs=runtime.tools.xtensa-lx106-elf-gcc-2.5.0-3-20ed2b9.path=C:\Users\User\AppData\Local\Arduino15\packages\esp8266\tools\xtensa-lx106-elf-gcc\2.5.0-3-20ed2b9 -prefs=runtime.tools.python.path=C:\Users\User\AppData\Local\Arduino15\packages\esp8266\tools\python\3.7.2-post1 -prefs=runtime.tools.python-3.7.2-post1.path=C:\Users\User\AppData\Local\Arduino15\packages\esp8266\tools\python\3.7.2-post1 -verbose C:\Users\User\Documents\Arduino\Sketch\Sketch.ino
C:\Program Files (x86)\Arduino\arduino-builder -compile -logger=machine -hardware C:\Program Files (x86)\Arduino\hardware -hardware C:\Users\User\AppData\Local\Arduino15\packages -tools C:\Program Files (x86)\Arduino\tools-builder -tools C:\Program Files (x86)\Arduino\hardware\tools\avr -tools C:\Users\User\AppData\Local\Arduino15\packages -built-in-libraries C:\Program Files (x86)\Arduino\libraries -libraries C:\Users\User\Documents\Arduino\libraries -fqbn=esp8266:esp8266:esp8285:xtal=80,vt=flash,exception=disabled,ssl=all,ResetMethod=ck,CrystalFreq=26,eesz=1M,led=2,ip=lm2f,dbg=Disabled,lvl=None____,wipe=none,baud=115200 -ide-version=10809 -build-path C:\Users\User\AppData\Local\Temp\arduino_build_44452 -warnings=none -prefs=build.warn_data_percentage=75 -prefs=runtime.tools.mkspiffs.path=C:\Users\User\AppData\Local\Arduino15\packages\esp8266\tools\mkspiffs\2.5.0-3-20ed2b9 -prefs=runtime.tools.mkspiffs-2.5.0-3-20ed2b9.path=C:\Users\User\AppData\Local\Arduino15\packages\esp8266\tools\mkspiffs\2.5.0-3-20ed2b9 -prefs=runtime.tools.xtensa-lx106-elf-gcc.path=C:\Users\User\AppData\Local\Arduino15\packages\esp8266\tools\xtensa-lx106-elf-gcc\2.5.0-3-20ed2b9 -prefs=runtime.tools.xtensa-lx106-elf-gcc-2.5.0-3-20ed2b9.path=C:\Users\User\AppData\Local\Arduino15\packages\esp8266\tools\xtensa-lx106-elf-gcc\2.5.0-3-20ed2b9 -prefs=runtime.tools.python.path=C:\Users\User\AppData\Local\Arduino15\packages\esp8266\tools\python\3.7.2-post1 -prefs=runtime.tools.python-3.7.2-post1.path=C:\Users\User\AppData\Local\Arduino15\packages\esp8266\tools\python\3.7.2-post1 -verbose C:\Users\User\Documents\Arduino\Sketch\Sketch.ino`

[franciscogimeno2000]

Hello I also the same problem in an ESP8285 if I compile the chip with 2.5.0 it works without problems. If I compile with a higher version it doesn't work.

I have returned to version 2.5.0,
I already had problems with the same project in an esp8266 but in another part of the code. Same code same chip with 2.5.0 works well you compile it with a superior one and strange errors jump.

[Techwolf12]

I was using 2.6.2 when I got this error as well with an ESP8622E. Switching back to 2.5.0 also fixed the restarting issue with this exception for me.

[fuenfundachtzig]

Still hoping that someone has a brillant idea to fix this issue. I am having the same problem as mentioned above, i.e. I get crashes with a stacktrace showing

Exception 9: LoadStoreAlignmentCause: Load or store to an unaligned address
PC: 0x4022686a: tcp_output at core/tcp_out.c line 1262

that happen on rare occasions and seem to happen mostly when the WiFi connection is disturbed and / or the server which I am trying to send data to (using HTTPClient) does not respons in time and / or correctly.

[devyte]

@philbowles is this problem still present in 2.6.3?

[philbowles]

Sorry for the delay, it came down eventually (I think) to using incompatible FLASH mode in the build options - either some of my boards are "fake"ish and use e.g. DOUT when the genuine article and standard definitions state DIQ or QIO or that irrelevant but they had dodgy flash chips. During that phase of my testing, I just set everything to DOUT and accepted the performance "hit" ( not that it was noticeable). Oddly it seemed to happen more often using lwIP v2 Lower Memory.

Either way it appears to be a "dodgy flash" issue - it was working but "randomly" (these things rarely are :) ) running really really really slowly then on next boot worked fine...for a while etc

I haven't seen anything like it for a long while (I'm on 2.6.3 since it was released) but I now always use lwIP v2 Higher bandwith no features...so who knows? If it reappears and I can pin it down...I'll come back

[devyte]

Thanks for the answer!
Closing.