I don't really know unfortunately. The way the UART output looks I see three scenarios:do you get again a stack overflow in task LogWriterTask or was it an other?
- LogWriterTask on CPU1 still runs and throws new exceptions (thats why there is no "bootup" output
- The "bootup" output is suppressed by something and we don't know how often CPU0 rebooted
- The error output is repeated over and over for some reason until WiFi is able to connect again
The LogWriterTask only contains code for writing to MicroSD and posting HTTP messages with esp_http_client, I don't open my own sockets here, I would assume this is correct but need to check. Memory is constantly monitored and with external pSRAM (as in this case) minimum heap free was 3.9MByte and for the test without pSRAM minimum was 17kBytecan you check the "unconnect func" - what happens with the socket pointer ( free ? ) , and how you generate then a new ( enough MEM ? ) do you check before using socket handler ( pointer ) that the pointer is valid ?
pSRAM is still wired, I disable it in menuconfig and replace one macro from heap_caps_malloc(size, MALLOC_CAP_SPIRAM) to malloc(size)is the psram still wired in this modul or do you remove it too after you remove psram using in firmware and change to inside malloc?
I am constantly trying to narrow it down further. The electronic can be switched between AP and STA mode. In AP mode the whole application hangs, sometimes for multiple seconds if an STA connects to it with at least release/v4.2 head, but not with tags/v4.1 or tags/v4.2-beta1. I'm currently also trying to narrow down which versions are exposing this behavior
