ESP8266: core dumps after normal work

General
#1

Worked with MongooseOS on ESP8266, - reflashed with mos many times (active development/debugging of a product), then my board starts to throw Core Dumps even at demo-js project. :frowning:
Why could it happen?
I even tried to cleanup the flash memory before flashing with python esptool.py -p COM5 erase_flash - no luck.

BUT!
My board works perfectly well with Arduino IDE - Wifi samples compiles, uploads and works like a charm.
So, what’s wrong in my case? (with Mongoose?)

My core dump:

mos --port COM5 console
[Nov 22 11:05:03.566]
[Nov 22 11:05:03.568] HW WDT @ 0x40000502
[Nov 22 11:05:03.570]  A0: 0x4000050c  A1: 0x3ffff690  A2: 0x00000000  A3: 0x3ffee89d
[Nov 22 11:05:03.574]  A4: 0x00000017  A5: 0x0000001a  A6: 0x00000020  A7: 0x00000000
[Nov 22 11:05:03.578]  A8: 0x00000100  A9: 0x00000080 A10: 0x00000000 A11: 0x001a0021
[Nov 22 11:05:03.584] A12: 0x3fffc258 A13: 0xffffffe0 A14: 0x3fffc200 A15: 0x00000022
[Nov 22 11:05:03.590]
[Nov 22 11:05:03.592] (exc SP: 0x3ffff4d0)
[Nov 22 11:05:03.596]
[Nov 22 11:05:03.598] --- BEGIN CORE DUMP ---
[Nov 22 11:05:03.601] mos: catching core dump
[Nov 22 11:05:06.436] ....
[Nov 22 11:05:15.143] ---- END CORE DUMP ----
[Nov 22 11:05:15.154] mos: wrote to c:\Projects\esp-doc-test\aaa\core-aaa-esp8266-20191122-110515.873933651 (133107 bytes)
[Nov 22 11:05:15.157] mos: analyzing core dump
Core dump by aaa/esp8266 1.0 20191122-090357
Using ELF file at: c:\Projects\esp-doc-test\aaa\build\objs\aaa.elf
Using Docker image: docker.io/mgos/esp8266-build:2.2.1-1.5.0-r5
Running docker run --rm -v /c/Projects/esp-doc-test/aaa/build/objs/aaa.elf:/fw.elf -v /c/Projects/esp-doc-test/aaa/core-aaa-esp
8266-20191122-110515.873933651:/core -v c:\Projects\esp-doc-test\aaa:/c/Projects/esp-doc-test/aaa docker.io/mgos/esp8266-build:
2.2.1-1.5.0-r5 bash -c /usr/local/bin/serve_core.py --rom=/opt/Espressif/rom/rom.bin --rom_addr=0x40000000 /fw.elf /core & $MGO
S_TARGET_GDB /fw.elf -ex 'target remote 127.0.0.1:1234' -ex 'set confirm off' -ex bt -ex quit
[Nov 22 11:05:15.230] mos: exec: "docker": executable file not found in %PATH%
[Nov 22 11:05:15.232] rebooting
[Nov 22 11:05:15.237]  ets Jan  8 2013,rst cause:2, boot mode:(3,7)
[Nov 22 11:05:15.239]
[Nov 22 11:05:15.242] load 0x40100000, len 1540, room 16
[Nov 22 11:05:15.244] tail 4
[Nov 22 11:05:15.246] chksum 0x82
[Nov 22 11:05:15.248] load 0x3ffe8000, len 748, room 4
[Nov 22 11:05:15.251] tail 8
[Nov 22 11:05:15.254] chksum 0x65
[Nov 22 11:05:15.256] csum 0x65
[Nov 22 11:05:15.258] rBoot v1.2.1-cesanta1 - richardaburton@gmail.com
[Nov 22 11:05:15.261] Flash Size:   32 Mbit
[Nov 22 11:05:15.263] Flash Mode:   DIO
[Nov 22 11:05:15.265] Flash Speed:  80 MHz
[Nov 22 11:05:15.268] rBoot Option: Big flash
[Nov 22 11:05:15.270]
[Nov 22 11:05:15.273] Booting rom 0 (0x100000).
[Nov 22 11:05:15.276]     ← o  ;  g|  l ld$`  # ←   < {  $ '   n   $`   s l $← mode : sta(5c
[Nov 22 11:05:15.278] esp_main.c:172          aaa 1.0 (20191122-090357)
[Nov 22 11:05:15.282] esp_main.c:174          Mongoose OS 2.16.0 (20191122-090357/2.16.0-g9b779cd)
[Nov 22 11:05:15.285] esp_main.c:178          CPU: ESP8266EX, 160 MHz, RAM: 51392 total, 49020 free
[Nov 22 11:05:15.287] esp_main.c:180          SDK 2.2.1(1247cc5); flash: 4M
[Nov 22 11:05:15.289] esp_exc.c:211           Reset cause: 4 (soft reset)
[Nov 22 11:05:15.292] mg_lwip_ev_mgr.c:93     Mongoose 6.15, LwIP 1.4.1
[Nov 22 11:05:15.295] mg_ssl_if_mbedtls.c:57  mbed TLS 2.16.3-cesanta2
[Nov 22 11:05:15.297] mgos_vfs_dev.c:73       sfl0: sysflash (), size 4194304
[Nov 22 11:05:15.299] mgos_vfs_dev.c:73       root: part ({"dev": "sfl0", "offset": 32768, "size": 262144}), size 262144
[Nov 22 11:05:15.304] mgos_vfs.c:147          /: SPIFFS @ root, opts
[Nov 22 11:05:15.347] mgos_vfs.c:320          /: size 233681, used: 135540, free: 98141
[Nov 22 11:05:42.141]
[Nov 22 11:05:42.141] HW WDT @ 0x40106a9c
[Nov 22 11:05:42.141]  A0: 0x4000050c  A1: 0x3ffff910  A2: 0x00000000  A3: 0x3ffee89d
[Nov 22 11:05:42.146]  A4: 0x3fffc200  A5: 0x00000531  A6: 0xffffffff  A7: 0x00000020
[Nov 22 11:05:42.152]  A8: 0x4000dc3c  A9: 0x00000017 A10: 0x00000000 A11: 0x00000017
[Nov 22 11:05:42.157] A12: 0x0000000a A13: 0x00000400 A14: 0x00000001 A15: 0x00000008
[Nov 22 11:05:42.163]
[Nov 22 11:05:42.163] (exc SP: 0x3ffff750)
[Nov 22 11:05:42.166]
[Nov 22 11:05:42.166] --- BEGIN CORE DUMP ---
[Nov 22 11:05:42.169] mos: catching core dump
#2

Hi,

Try to set debug.level to 4 and paste here the output please.

I recently had also problems with mos freezing when it was accessing VFS and was using GPIO handler on pin 2. Last lines of log before WDT triggered was following:

[Nov 22 10:31:25.476] esp_vfs_dev_sysflash:83 write 1 @ 0xeb104 => 0
[Nov 22 10:31:25.480] mgos_vfs.c:350          open state 0x601 0x1b6 => 0x3fff178c state 1 => 257 (refs 1)
[Nov 22 10:31:25.488] esp_vfs_dev_sysflash:83 read 70 @ 0xeb300 => 0
[Nov 22 10:31:25.492] esp_vfs_dev_sysflash:83 read 2 @ 0xeb004 => 0
[Nov 22 10:31:25.496] mgos_vfs.c:509          fstat 257 => 0x3fff178c:1 => 0 (size 0)
[Nov 22 10:31:25.502] esp_vfs_dev_sysflash:83 read 256 @ 0xeb300 => 0
[Nov 22 10:31:25.506] esp_vfs_dev_sysflash:83 read 256 @ 0xeb000 => 0
[Nov 22 10:31:25.511] esp_vfs_dev_sysflash:83 write 2 @ 0xeb006 => 0
[Nov 22 10:31:25.515] esp_vfs_dev_sysflash:83 write 5 @ 0xeb400 => 0
[Nov 22 10:31:25.520] esp_vfs_dev_sysflash:83 write 48 @ 0xeb405 => 0
[Nov 22 10:31:25.525] esp_vfs_dev_sysflash:83 read 5 @ 0xeb300 => 0
#3

Here it is - https://pastebin.com/8LdfFsft

#4

With debug.level=4, demo-js issues a WDT exception.
debug.level=3 works for me on ESP8266.