[SOLVED] Upip problem ESP32 WiFi Kit

Can’t use MicroPython’s upip with ESP32 WiFi Kit. Problem is that WiFi disconnects with a beacon interval timeout. Here’s the detailed log:

import upip
Installing to: /lib/
I (54352687) wifi: bcn_timout,ap_probe_send_start
I (54355187) wifi: ap_probe_send over, resett wifi status to disassoc
I (54355187) wifi: state: run -> init (c800)
I (54355187) wifi: pm stop, total sleep time: 49780126008 us / 54353492785 us
I (54355197) wifi: new:<1,0>, old:<1,0>, ap:<255,255>, sta:<1,0>, prof:1
mbedtls_ssl_handshake error: -71
I (54355207) wifi: STA_DISCONNECTED, reason:200
beacon timeout
Error installing ‘micropython-umqtt.robust’: [Errno 5] EIO, packages may be partially installed

I (54355337) wifi: new:<1,0>, old:<1,0>, ap:<255,255>, sta:<1,0>, prof:1
I (54355337) wifi: state: init -> auth (b0)
I (54355337) wifi: state: auth -> assoc (0)
I (54355347) wifi: state: assoc -> run (10)
I (54355357) wifi: security type: 3, phy: bgn, rssi: -51
I (54355367) wifi: pm start, type: 1
I (54355367) network: CONNECTED
I (54355387) wifi: AP’s beacon interval = 102400 us, DTIM period = 1
e[0;32mI (54358587) event: sta ip:, mask:, gw:
I (54358587) network: GOT_IP

I Googled this issue and the most plausible explanation is in this discussion:


ESP_Sprite says:

The issue is that most of the ESP32 is ‘locked up’ while doing flash writes; the architecture is somewhat dependent on being able to read code from the flash chip on the fly, and while doing a write it cannot do this, so it will suspend most tasks until the write is over. If you do a lot of large writes back-to-back, this means a bunch of tasks won’t run for a long time, and the task watchdog kicks in. Suggest doing a vTaskDelay(10) or something between flash writes, to give other tasks the chance to run.

This makes sense because large writes is exactly what upip would be doing. So the suggested solution is to modify upip, or is there something on the ESP32 board that can be done?

I’ll also be posting this question on the MicroPython forum. It’s surprising that upip doesn’t work on all ESP32 boards, and no one noticed it so far.

The problem appears to be in the MicroPython firmware. I was using this firmware: esp32-idf3-20200122-v1.12-68-g3032ae115.bin and upip failed with wifi beacon timeout. I then loaded this firmware: esp32-idf4-20200122-v1.12-68-g3032ae115.bin and upip works fine.

Maybe I do have a similar issue with the HELTEC Wifi board:
I’m running multiple WIFI networks (MESH, internal, external, 2.4/5GHz).
My program should transmit sensor data every 10 minutes to a server … in between it goes to deepsleep. OS is micropython, the data transfer is performed via HTTP GET.
An Espressif ESP32 is able to connect and re-connect to the designated network without any trouble.
But when using a HELTEC wifi board, the connect/re-connect will fail in min. 40% of all tries. No failure, simply no connection “host unreachable” … IP-address assigned by ifconfig.
And it seems, that the failure rate increases during operation time (after reset/reboot everything seems to wokr fine, after approx. one hour one can see the first re-connect after deepsleeep failed, after 4 hour, more re-connects after deepsleep has failed)
In parallel several other devices are able to communicate with the server (Apache server in local network), so it is not an issue of the network or the server.
Before updating to micropython esp32-idf4-20200122-v1.12… (as mentioned in the post before), the failing rate was much higher (at ~80%) or sometimes simply impossible.

Any suggestions ?
I like to continue with the HELTEC board because of its integrated power (accu) connector and the integrated display. Furthermore I like to switch to the HELTEC WIFI/LORA board to collect data from LORA substations and transfer them to the server.
In parallel I will replace the WIFI board by a LORA board … maybe it is more stable … we will see

So I will answer my own post: The LORA V2 board runs much better, but still some failing connections.
An Espressif board, same program, some sensors, rans in parallel without any issues