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

Seems like this is related to WIFI in some way. When turning off WIFI (pycom.wifi_on_boot(False)) problem goes away. I am not using WIFI in any way, but maybe powerlines or WIFI accesspoint makes my W01 panic? This is the application I have been running during the test: from machine import Pin import utime LED.append(Pin('P3', mode=Pin.OUT)) while True: LED.value(1) utime.sleep_ms(100) LED.value(0) utime.sleep_ms(100) I havent been able to decode the core dumps, can I send them to someone for investigation? This forum didn´t allow me to post it here.

Update: It seems I am getting the crashes only when I have my pysense/wipy connected via USB. I have around 12-15 units running in various setups; those running standalone (battery connection only) seem to do fine, those with USB fail regularly.

@danielm Not yet, but I will do it during this week.

@jmarcelino do you already searching for a solution or have found it ???? I have the same problem

Dear @asergio, @Stefano-Tondini and @gman, back in the time you have been recognizing this issue, it looks like connecting to WPA2-Enterprise was not supported by the ESP-IDF at all. Since October 2018, appropriate support has been merged [1,2] and we can confirm we are seeing these bits within the current Pycom fork [3]. So, we would encourage you to try again with one of the more recent releases of the Pycom firmware. With kind regards, Andreas. [1] https://github.com/espressif/esp-idf/issues/2181 [2] https://github.com/espressif/esp-idf/pull/2354 [3] https://github.com/pycom/pycom-esp-idf

Hi, Im sorry if I accidentally ignored your coredump post. You notice that this post is from 2018 and that there is no added value in solving this issue anymore right? Now, let me start by mentioning it is never okay for the controller to present a coredump and they should be avoided at all costs. The issue with these coredumps is that they can have a variety of reasons, and that debugging them takes a lot of effort, as I need to know the exact firmware version used (incl development board version), the coredump parameters (top section) and it is very useful to see the python code and learn about its workings and when it breaks (if it breaks at the same location every time). Even then, it is still a wild goose chase. There can be many reasons for a coredump (including inadequate power supply, incorrect use of threading, firmware errors etc.) What we can do, is provide you with better tools to research the coredump and I will be working on that. Note that I have already started a documentation page here: https://docs.pycom.io/advance/coredump/, but I want to do better. Please let me know how we can improve the situation! Best, Gijs

@shiva-shankar Are you sure that you are using V1.17.3.b1 on your device, together with the lastesrt copy of the nanogateway.py script? What are the responses to : import uos uos.uname() uos.listdir() uos.stat("nanogateway.py")

@seb Yep! That fixed it. Thanks! Cheers, Thomas

@Thosch42 This tip from Robert should fix your red light: https://forum.pycom.io/topic/1343/solved-lopy-bricked-red-led/3