1.20.2.r4 GPy Core Panic Uploading FTP
-
I'm running v1.20.2.r4 and am consistently getting a Guru meditation error while trying to upload a file over FTP.
Does anyone have any insight, or anything I should try? I have tried performing a full erase and reprogramming, but get the same results.
>>> import network >>> wlan = network.WLAN(mode=network.WLAN.STA) >>> wlan.connect('MyNetwork', auth=(network.WLAN.WPA2, 'MyNetworkPassword')) >>> wlan.ifconfig() ('192.168.1.39', '255.255.255.0', '192.168.1.1', '192.168.1.1') ###Begin Uploading a file. >>> Guru Meditation Error: Core 0 panic'ed (LoadProhibited). Exception was unhandled. Core 0 register dump: PC : 0x4017e1eb PS : 0x00060a30 A0 : 0x8018269c A1 : 0x3ffbaee0 A2 : 0x3fbc11d4 A3 : 0x3ffdfc7c A4 : 0x00000011 A5 : 0x000005c4 A6 : 0x3fbc1802 A7 : 0x00000014 A8 : 0x8017e1c9 A9 : 0x3ffbaec0 A10 : 0x000005c4 A11 : 0x000105c4 A12 : 0x00000000 A13 : 0x00000000 A14 : 0x3ffb9f44 A15 : 0x00000001 SAR : 0x00000010 EXCCAUSE: 0x0000001c EXCVADDR: 0x00000022 LBEG : 0x40092860 LEND : 0x4009288e LCOUNT : 0xffffffff ELF file SHA256: 0000000000000000000000000000000000000000000000000000000000000000 Backtrace: 0x4017e1eb:0x3ffbaee0 0x40182699:0x3ffbaf10 0x40172be5:0x3ffbaf30
Here is what I get when I run the backtrace lines through xtensa-esp32-elf-addr2line:
ip4_input /home/peter/docs/pycom-esp-idf/components/lwip/lwip/src/core/ipv4/ip4.c:522 (discriminator 1)
-
Perhaps the flash on your device is already full (1.9MB is quite a large file, two of those will probably not fit). Note that we also place the firmware in the 4MB flash. I think the issue is with flash space running out for this GPy. You could try to do an erase-all in the CLI updater, or
os.fsformat("/flash")
to empty the flash.
-
The file size I've been using to reproduce this reliably (on this GPy) is 1,904KB. I have 50 other GPy not having this problem.
I updated to 1.20.3.r3 and gave it a shot again. I got this core dump:
>>> Guru Meditation Error: Core 0 panic'ed (StoreProhibited). Exception was unh andled. Core 0 register dump: PC : 0x4014f8da PS : 0x00060c30 A0 : 0x80154615 A1 : 0x3f fdf5f0 A2 : 0x3fbc9838 A3 : 0x3ffb5278 A4 : 0x1f8042a4 A5 : 0x3f bcab7a A6 : 0x2501a8c0 A7 : 0x00000014 A8 : 0x00000000 A9 : 0x3f fdf5d0 A10 : 0x000005c4 A11 : 0x00000000 A12 : 0x3ffdf6d8 A13 : 0x00 000001 A14 : 0x000000fe A15 : 0x00000001 SAR : 0x00000010 EXCCAUSE: 0x00 00001d EXCVADDR: 0x1f8042d0 LBEG : 0x4008f22c LEND : 0x4008f248 LCOUNT : 0xff ffffff ELF file SHA256: 0000000000000000 Backtrace: 0x4014f8d7:0x3ffdf5f0 0x40154612:0x3ffdf620 0x40141ae1:0x3ffdf640
md4_finish /home/gezahusi/Work/Repositories/pycom-esp-idf/components/lwip/lwip/src/netif/ppp/polarssl/md4.c:264 (discriminator 4)
-
Could you let me know of the filesize?
The piece of code returned by the backtrace is part of the ESP-IDF, something we have no control over unfortunately, though if you can try the beta release (1.20.3.b3) which is built upon a new ESP-IDF version and see if the issue persists?
Let me know!