Life expectancy with Micropython

[thalesmaoa]

Does anyone think that is possible that micropython reduces ESP32 life expectancy?

Ok, this an odd question...

Context:
I have 5 ESP8266 running C++ code with an total uptime of 3 years and a half. However, I have an application that uses an ESP32 - Micropython that has failed 2 times in the last year and a half. It starts with Wifi intermittence. After that, the period between reconnection starts to grow. Minutes trying to reconnect... After some time, it can't connect any more.

Does anyone have a Micropython ESP32 - Wifi 24/7 uptime for more than a year?

My theory: depending on memory technology, it has a limited amount of writing cycles. Is it possible that micropython loops between writing cycles? I constantly use gc.collect.

[pythoncoder]

gc affects only RAM which has no limit on write cycles. Flash does have a limit which could be reached if your application repeatedly writes to the filesystem - typically on the order of 10K sector erases. Flash read cycles are unlimited, so unless your application performs explicit file writes there should be no limit to ESP32 life.

When your boards fail, can you still access the REPL?

[thalesmaoa]

Yes. I can. Wifi starts to fail, apparently, that's all.

I'm sure that my code doesn't write into the flash.

Bellow are the imports that I'm using, but I'm not sure if they use flash.

Code: Select all

from machine import UART
from machine import Pin
from machine import PWM
from machine import WDT
import esp32
import machine
import time
from time import sleep
import ubinascii
import micropython
import network
import esp
esp.osdebug(None)
import gc
gc.collect()
from mqtt_as import MQTTClient
from config import config
import uasyncio as asyncio

wdt = WDT(timeout=15000)  # enable it with a timeout of 15s

The main piece of code:

Code: Select all

async def main(client):
    asyncio.create_task( verifica_rfid() )
    await client.connect()
    asyncio.create_task( door_check() )
    while True:
        await client.publish("portao/social/led", "idle")
        await client.publish("portao/social/temp", str( (esp32.raw_temperature()-32)*5/9 ) )
        await asyncio.sleep(15)

config['subs_cb'] = callback
config['connect_coro'] = conn_han
config['server'] = SERVER

# Attach Interrupt
rfid_in_interrup.irq(trigger=Pin.IRQ_FALLING, handler=read_rfid_in)
rfid_out_interrup.irq(trigger=Pin.IRQ_FALLING, handler=read_rfid_out)

MQTTClient.DEBUG = False  # Optional: print diagnostic messages
client = MQTTClient(config)
try:
    asyncio.run(main(client))
finally:
    client.close()  # Prevent LmacRxBlk:1 errors

[pythoncoder]

One of the advantages of the ESP32 is that it doesn't write to flash when it initialises WiFi (the ESP8266 stores credentials with an effect on Flash lifetime). Aside from highly specialised register level coding MicroPython only writes to Flash with explicit filesystem writes. There should be no flash wear. In any event, if Flash did wear, I'd struggle to see why only WiFi performance would be affected.

I can't explain this dropoff in WiFi performance at all.

[thalesmaoa]

Thanks, at least I know that it can't be flash.

[pythoncoder]

If you find out what is going on, please report it here so others can benefit.

[scruss]

How are you powering the ESP32?

I've got an inexpensive ESP32 board that will flash and work fine with the REPL, but its wifi performance is terrible when powered via USB. It's now in an application where it's powered by a decent regulator via the pins, and wifi is fine. Perhaps the power circuit you're using is not quite providing the power the ESP32 needs to run wifi reliably?

[pythoncoder]

Good point. I've had problems with voltage drop on long USB leads. Current goes up substantially when WiFi is active.