I tried the legacy firmware without the pybytes stuff. It is works all right with that fw.

Yes, as @robert-hh suggested, I'm very much looking for a reproduction, or a series of things I can do that make this coredump happen (like running this micropython code in combination with pressing button x). The functions calls listed in this coredump decode happen quite a lot all over the firmware, making me think it could be related to running out of memory, or a memory leak somewhere, but again, it depends on the location and order of your function calls. Also, quick side note, you mention in your previous post you're using a Gpy, but have the firmware.elf path going through WIPY, is that intentional? It is possible to run Wipy firmware on a Gpy, (disabling the usage of the LTE modem). If its not intentional. it might show us the wrong function calls here. Let me know

Dear @Milan and @Martinnn, if you feel lucky, you might want to try our custom build just released on [1]. More background about this is available through [2]. 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]. With kind regards, Andreas. [1] https://packages.hiveeyes.org/hiveeyes/foss/pycom/vanilla/WiPy-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

@glagnar Hey, Pretty sure I just responded to your rma a short while ago you can go ahead and ignore my request to confirm its running the latest firmware in that now I realise its linked to this thread :). Ill update the RMA shortly :) Paul

Dear @cblims, @leifarne and @aarpi3, if you feel lucky, you might want to try one of our custom builds just released at [1,2,3]. More background about this is available through [4]. 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 [5]. With kind regards, Andreas. [1] https://packages.hiveeyes.org/hiveeyes/foss/pycom/vanilla/WiPy-1.20.1.r1-0.6.0-vanilla-dragonfly.tar.gz [2] https://packages.hiveeyes.org/hiveeyes/foss/pycom/vanilla/GPy-1.20.1.r1-0.6.0-vanilla-dragonfly.tar.gz [3] https://packages.hiveeyes.org/hiveeyes/foss/pycom/vanilla/LoPy4-1.20.1.r1-0.6.0-vanilla-dragonfly.tar.gz [4] https://community.hiveeyes.org/t/investigating-random-core-panics-on-pycom-esp32-devices/2480 [5] https://community.hiveeyes.org/t/installing-the-recent-pycom-firmware-1-20-1-r1-requires-erasing-the-flash-memory-completely/2688

It seems that the FTDI chip I was using started to brown out. I switched to external power with a DC supply and everything is back to normal. I should've tried that first. I didn't even think of it since for the first couple of weeks the FTDI chip had no issues supplying sufficient power. Regardless, thank you very much for your help @robert-hh

@jmarcelino The only thing connected during update is PyTrack module which I use to connect USB.

The same thing is happening when I replace the MQTT with the requests library and try to post to an HTTPS API. I believe the problem is th ussl.wrap_socket.