coredump with lora communication and file writing

[crc16]

Hello,
I use a lopy module with current version : (sysname='LoPy', nodename='LoPy', release='1.15.0.b1', version='v1.8.6-849-baa8c33 on 2018-01-29', machine='LoPy with ESP32', lorawan='1.0.0')
I'm testing a small application that writes files and sends data to ttn in the ABP mode

1. no problem with the version (sysname='LoPy', nodename='LoPy', release='1.10.2.b1', version='v1.8.6-849-g0af003a4 on 2017-11-24', machine='LoPy with ESP32', lorawan='1.0.0')
2. update to 1.15.0.b1 with with no error message
3. after update and reset, cyclic reset with display of coredump :

Guru Meditation Error: Core  1 panic'ed (Cache disabled but cached memory region accessed)
Register dump:
PC      : 0x400844b5  PS      : 0x00060434  A0      : 0x80084e48  A1      : 0x3ffc1370  
A2      : 0x3ffc6880  A3      : 0x00000005  A4      : 0xbad00bad  A5      : 0x00060021  
A6      : 0x3ffc6aec  A7      : 0x00000001  A8      : 0x800844a6  A9      : 0x3ffc1350  
A10     : 0x00000005  A11     : 0x3ffc1361  A12     : 0x3ffc1361  A13     : 0x3ffc6b48  
A14     : 0x3ffc6b38  A15     : 0x3ffae270  SAR     : 0x0000000f  EXCCAUSE: 0x00000007  
EXCVADDR: 0x00000000  LBEG    : 0x4009a890  LEND    : 0x4009a8be  LCOUNT  : 0x00000000  

Backtrace: 0x400844b5:0x3ffc1370 0x40084e45:0x3ffc1390 0x40084f51:0x3ffc13c0 0x40083f57:0x3ffc13f0 0x400835e5:0x3ffc1410 0x40062232:0x00000000

4. I'm removing all the writings from files : it's works .

[crc16]

coredump2.txt

[crc16]

main.py.zip

[amotl]

Dear @crc16,

if you feel lucky, you might want to try our custom build just released on [1]. More background 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 just don't paste it into the comment itself but put it into a file which you will be able to upload by dragging it into the text area.

Please be aware that when upgrading to the current 1.20.1 development release these builds are based upon, 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].

Please also be aware that this procedure will also erase the LoRa MAC stored on the device. @robert-hh thankfully outlined the procedure to restore it appropriately:

• If you still know the value the LoraMac had before, then you can follow the procedure explained at https://forum.pycom.io/topic/1272/lora-mac-ffffffffffffffff/21.
• If you do not know it, you will have to use the Pycom updater to restore it:
  • First, use the Pycom updater (GUI version) to install a recent image (like pybytes 1.20.1) from the Internet. You do not have to use it, the installation process itself already restores both the LoRa MAC and the Sigfox ID.
  • Then, use the Pycom updater to flash the custom image. Do not erase the flash in between.

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/LoPy-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 @crc16,

Exact steps to cause this issue

I'm testing a small application that writes files and sends data to TTN in the ABP mode. When I'm removing all the writings from files, it works flawlessly.

Several people have been able to mitigate similar issues (not even related to LoRa) 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.

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

When upgrading from earlier releases like 1.15.0.b1, please read both the installation instructions and the notes for LoPy, LoPy4, SiPy and FiPy devices carefully, a) regarding the erase_all procedure and b) for restoring the Lora MAC after the erase_all procedure.

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