Another file corruption issue

[stanleypa]

Please include the following information when submitting a bug report:

• The Pycom board you are using (e.g. WiPy 2.0, LoPy).
  G01
• The firmware version you are using. You can get it by executing the following Python code at the
  Initializing filesystem as FatFS!
  Pycom MicroPython 1.20.0.rc4 [v1.9.4-1444e48] on 2019-01-07; GPy with ESP32
• Exact steps to cause this issue
  Copying files to flash via FileZilla. This normally works but every so often I get a crash and the file system is corrupt.
• What you expected
  files copied/overwritten to flash FS
• What happened instead

Guru Meditation Error: Core 0 panic'ed (Cache disabled but cached memory region accessed)
Core 0 register dump:
PC : 0x401d5b04 PS : 0x00060834 A0 : 0x80091760 A1 : 0x3ffc0970
A2 : 0x00000002 A3 : 0x00000001 A4 : 0x80081a25 A5 : 0x3ffd6220
A6 : 0x00000000 A7 : 0x00060920 A8 : 0x8008c3a2 A9 : 0x01000000
A10 : 0x0e040000 A11 : 0x00000002 A12 : 0x00000013 A13 : 0x00000000
A14 : 0x00000003 A15 : 0x00060523 SAR : 0x0000000e EXCCAUSE: 0x00000007
EXCVADDR: 0x00000000 LBEG : 0x00000000 LEND : 0x00000000 LCOUNT : 0x00000000
Core 0 was running in ISR context:
EPC1 : 0x400933f7 EPC2 : 0x00000000 EPC3 : 0x00000000 EPC4 : 0x401d5b04

Backtrace: 0x401d5b04:0x3ffc0970 0x4009175d:0x3ffc0990 0x40091f3f:0x3ffc09b0 0x40091c96:0x3ffc09d0 0x400925a7:0x3ffc09f0 0x400837c9:0x3ffc0a10 0x4008a03b:0x00000000

================= CORE DUMP START =================

================= CORE DUMP END =================
E (10510) esp_core_dump: Skipped 1 tasks with bad TCB!
E (10514) esp_core_dump: Crashed task has been skipped!
Rebooting...

Flash file system is either completely reset (basic boot.py and main.py) or contains junk

I don't remember seeing this before I move to 1.20

[iwahdan88]

Hello @stanleypa, This issue is related to #265 , it is fixed in version v1.20.0.rc7.1

[stanleypa]

Hello @stanleypa, This issue is related to #265 , it is fixed in version v1.20.0.rc7.1

I'm still seeing this issue on Pycom MicroPython 1.20.0.rc10 [v1.9.4-350eac8] (same hardware)

Guru Meditation Error: Core 0 panic'ed (Cache disabled but cached memory region
accessed)
Core 0 register dump:
PC : 0x401d7864 PS : 0x00060e34 A0 : 0x800920f8 A1 : 0x3f
fc0970
A2 : 0x00000001 A3 : 0x00000001 A4 : 0x3ffc0998 A5 : 0x00
000000
A6 : 0x3ffbc200 A7 : 0x3ffbc24c A8 : 0x8008c88e A9 : 0x00
100000
A10 : 0xd4b40000 A11 : 0x00000001 A12 : 0x00000013 A13 : 0x00000000
A14 : 0x000000fe A15 : 0x7fffffff SAR : 0x0000000e EXCCAUSE: 0x00000007
EXCVADDR: 0x00000000 LBEG : 0x00000000 LEND : 0x00000000 LCOUNT : 0x00000000
Core 0 was running in ISR context:
EPC1 : 0x40093df7 EPC2 : 0x00000000 EPC3 : 0x00000000 EPC4 : 0x401d7864

Backtrace: 0x401d7864:0x3ffc0970 0x400920f5:0x3ffc0990 0x400928e7:0x3ffc09b0 0x4009262e:0x3ffc09d0 0x40092f5f:0x3ffc09f0 0x40083931:0x3ffc0a10 0x4008a429:0x3ffd46b0 0x40081edf:0x3ffd46d0

================= CORE DUMP START =================

[stanleypa]

I have also seen a similar issue using LittleFS using ftp - same hardware same firmware:

Guru Meditation Error: Core 0 panic'ed (Cache disabled but cached memory region accessed)
Core 0 register dump:
PC : 0x401d7864 PS : 0x00060434 A0 : 0x800920f8 A1 : 0x3ffc0970
A2 : 0x00000001 A3 : 0x00000001 A4 : 0x80081a4d A5 : 0x3ffd68d0
A6 : 0x00000000 A7 : 0x00060323 A8 : 0x8008c88e A9 : 0x00100000
A10 : 0xe8340000 A11 : 0x00000001 A12 : 0x00000013 A13 : 0x00000000
A14 : 0x3ffc3278 A15 : 0x3ffc3384 SAR : 0x0000000e EXCCAUSE: 0x00000007
EXCVADDR: 0x00000000 LBEG : 0x00000000 LEND : 0x00000000 LCOUNT : 0x00000000
Core 0 was running in ISR context:
EPC1 : 0x40093df7 EPC2 : 0x00000000 EPC3 : 0x00000000 EPC4 : 0x401d7864

Backtrace: 0x401d7864:0x3ffc0970 0x400920f5:0x3ffc0990 0x400928e7:0x3ffc09b0 0x4009262e:0x3ffc09d0 0x40092f5f:0x3ffc09f0 0x40083931:0x3ffc0a10 0x4008a437:0x3ffd46b0 0x40081edf:0x3ffd46d0

================= CORE DUMP START =================
WEgAABMAAABsAQAA

[amotl]

Dear @stanleypa,

we also have been annoyed by different random core panics people from our community have been observing very similar to what you are describing here.

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.

cc @alexodus

[1] https://packages.hiveeyes.org/hiveeyes/foss/pycom/vanilla/GPy-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] #361 (comment)

[amotl]

Dear @stanleypa,

Exact steps to cause this issue

Copying files to flash via FileZilla. This normally works but every so often I get a crash and the file system is corrupt.

Several people have been able to mitigate similar issues with one of our custom/unofficial Dragonfly builds based on Pycom’s 1.20.1.r1 [1] as mentioned above. We've refreshed this the other day and published corresponding Squirrel builds based on Pycom’s most recent 1.20.2.rc3 [2].

If you are lucky to try this build, we will be happy to hear about the outcome for you.

• GPy-1.20.2.rc3-0.8.0-vanilla-squirrel.tar.gz

With kind regards,
Andreas.

[1] https://community.hiveeyes.org/t/dragonfly-firmware-for-pycom-esp32/2746
[2] https://community.hiveeyes.org/t/squirrel-firmware-for-pycom-esp32/2960