CORE DUMP during vm.c exception handling locks up

[jldavis]

The board runs for anywhere from a few minutes to a few hours before the issue occurs. If the watchdog was effective I could live with the crash, but for whatever reason the WDOG does not fire, so the board needs to be power cycled.

Board: FIPY (sysname='FiPy', nodename='FiPy', release='1.18.2.r7', version='959ffd7-dirty on 2019-06-05', machine='FiPy with ESP32', lorawan='1.0.2', sigfox='1.0.1')

I have captured this backtrace: /mnt/c/pycom-micropython/esp32/../py/vm.c:1279 /mnt/c/pycom-micropython/esp32/hal/esp32_mphal.c:217 /mnt/c/pycom-micropython/esp32/hal/esp32_mphal.c:147 /mnt/c/pycom-micropython/esp32/../lib/mp-readline/readline.c:425 /mnt/c/pycom-micropython/esp32/../lib/utils/pyexec.c:421 /mnt/c/pycom-micropython/esp32/mptask.c:319

The code in vm.c is handling some error, but nothing is obvious as to what went wrong ahead of the crash dump.

[2019-06-05 21:30:24] 6284683 GPS [True:8 1.21, 0.88] @ 1559795423 Pos=(35.234718, -120.639193) vel: 0.00 dir: 185.60 Alt: 47.30 TOut: 5458 [2019-06-05 21:30:24] Guru Meditation Error: Core 1 panic'ed (LoadProhibited) [2019-06-05 21:30:24] . Exception was unhandled. [2019-06-05 21:30:24] Register dump: [2019-06-05 21:30:24] PC : 0x400fd408 PS : 0x00060230 A0 : 0x800dd938 A1 : 0x3ffdca40
[2019-06-05 21:30:24] A2 : 0x00000001 A3 : 0x00000001 A4 : 0x00000000 A5 : 0x00000001
[2019-06-05 21:30:24] A6 : 0x00000000 A7 : 0x00060023 A8 : 0x800fc1fa A9 : 0x3ffe89e0
[2019-06-05 21:30:24] A10 : 0x00000001 A11 : 0x00000001 A12 : 0x3f950c30 A13 : 0x3f950c30
[2019-06-05 21:30:24] A14 : 0x3ffe8b70 A15 : 0x3ffe8ad0 SAR : 0x0000001a EXCCAUSE: 0x0000001c
[2019-06-05 21:30:24] EXCVADDR: 0x00000001 LBEG : 0x400eb480 LEND : 0x400eb4ac LCOUNT : 0x0001964d
[2019-06-05 21:30:24] [2019-06-05 21:30:24] Backtrace: 0x400fd408:0x3ffdca40 0x400dd935:0x3ffdca60 0x400dd99f:0x3ffdca80 0x400dde71:0x3ffdcab0 0x400de0a3:0x3ffdcad0 0x400dce58:0x3ffdcb10 [2019-06-05 21:30:24] [2019-06-05 21:30:24] ================= CORE DUMP START ================= [2019-06-05 21:30:24] bAcBABMAAABsAQAA [2019-06-05 21:30:24] rHn+P4DJ/T8Yj/4/ [2019-06-05 21:30:24] IIn+P7CO/j9b4GAAeFP8P3hT/D+sef4/cFP8PwUAAABEY/w/RGP8P6x5/j8AAAAA

[jldavis]

If someone understands what is suppose to happen maybe a check of the pointers (nlr.ret_val)-> before the conditional would prevent the crash?

exception_handler: // exception occurred ...
if (mp_obj_is_subclass_fast(MP_OBJ_FROM_PTR(((mp_obj_base_t*)nlr.ret_val)->type), MP_OBJ_FROM_PTR(&mp_type_StopIteration))) { if (code_state->ip) {

[amotl]

Dear @jldavis,

if you feel lucky, you might want to try our custom build we've just released yesterday [1]. More details about this is available through [2].

If we are lucky together, this will improve the stability significantly. If you will be still receiving the core dumps, I will be happy if you would share its content with us.

Please be aware that you will have to erase your device completely before flashing in order to keep things straight. You will find respective references to this on the forum. Hint: Use pycom-fwtool-cli --port /dev/ttyUSB0 erase_all, see also [3].

As it turned out to gain more robustness for others already [4,5], we will be happy to learn if this happens to you as well.

With kind regards, Andreas.

[1] https://packages.hiveeyes.org/hiveeyes/foss/pycom/vanilla/FiPy-1.20.1.r1-0.6.0-vanilla-dragonfly.tar.gz [2] https://community.hiveeyes.org/t/investigating-random-core-panics-on-pycom-esp32-devices/2480 [3] https://community.hiveeyes.org/t/installing-the-recent-pycom-firmware-1-20-1-r1-requires-erasing-the-flash-memory-completely/2688 [4] https://community.hiveeyes.org/t/testing-the-custom-dragonfly-builds-on-pycom-devices/2746 [5] https://github.com/pycom/pycom-micropython-sigfox/issues/361#issuecomment-553399627