Over-the-air updates are easy on a bench with Wi-Fi. They get much harder when the device sits in a borehole, a pump station or a roadside cabinet, on a cellular link that can slip from LTE down to 2G halfway through a download. A truck roll to recover one bad firmware build can cost more than the device itself. This post covers the design rules that matter when ESP32-class devices update over cellular, using NORVI's open reference code as the worked example.
Start with a known-good reference flow
NORVI documents a straightforward pattern for ESP32 OTA over a cellular modem. The device fetches a small version.txt file from a GitHub release branch and compares it with the version it is running. If they differ, it downloads firmware_vX.X.X.bin over HTTPS, writes it with the ESP32 Update library and restarts. The sample uses TinyGSM for the modem, ArduinoHttpClient for requests and SSLClient for TLS, and it ships the root CA certificate for raw.githubusercontent.com in a cert.h file.
The full sketches, including variants for the Quectel EC25 and for OTA triggered by SMS, are in the NORVI OTA-on-ESP repository, and there is a matching guide for the EC25 modem. Remember to replace the sample APN with the one for your SIM and data plan.
Why 2G fallback changes the maths
Modern modems fall back to older networks when coverage weakens. The NORVI X3 uses a Quectel EC25 for 4G LTE, the NORVI X2 pairs a SIMCom A7672 with 2G/4G connectivity, and the NORVI GSM family is offered in 2G GSM/GPRS and 4G LTE variants. Battery loggers such as the EC-M12 use a SIM7070 modem covering 2G, LTE-M and NB-IoT.
That flexibility keeps devices online, but GPRS throughput is typically measured in tens of kilobits per second. As a rough illustration, a 1 MB image at 40 kbit/s needs more than three minutes of uninterrupted transfer, and every extra minute is another chance for the session to drop.
Check how your modem prioritises networks, too. Most modems let you lock to one technology or allow automatic fallback, and a device that flaps between LTE and 2G at the edge of coverage can waste more airtime than one pinned to the stable network.
Design rules that survive the field
Poll on a schedule, not in a loop. The NORVI sample calls its version check from loop() with a one-second delay, which is fine for a demo. A fleet should check every few hours or on a command, because each poll costs airtime and data allowance.
Treat image size as a budget. OTA needs two application slots. On a 4 MB ESP32-WROOM-32 the default partition layout leaves roughly 1.25 MB per slot, so the size cap is physical, and smaller images also finish faster on 2G.
Never touch the running image. The Update library writes to the inactive slot, and the NORVI sample keeps running the current version if the download fails. Preserve that behaviour and test it by cutting power mid-download.
Verify before you reboot. Compare the written byte count with the Content-Length, set an expected MD5 on the Update library before calling end(), and consider signed images. The NORVI X lists firmware signature verification among its security features.
Enable rollback. The ESP-IDF OTA API can mark a new image as pending verification and revert to the previous one unless the application confirms it is healthy. A firmware that boots but cannot reach the network is the failure that hurts most in the field.
Stage the rollout. Update a small group first, report the running version in every telemetry message, and widen only after that group has checked in.
Gate on conditions. Skip updates when battery or signal is poor, and defer large images while the modem is on 2G. A multi-minute download is a major energy event for a logger built around a sleep, wake and transmit cycle.
Do not forget the certificates
Embedding a root CA in firmware is convenient until the certificate chain changes. If the stored root expires or the server moves to a different issuer, every device that cannot validate TLS also cannot download the fix. Plan a way to refresh the certificate while the old one still works, and keep a tested path for updating it before you need it.
What changes at fleet scale
Below a dozen units, a manual fix is annoying. Above a hundred, it becomes a budget line, and verification, rollback and staged rollout stop being optional. None of these rules need exotic hardware, only discipline in the update path. Log the outcome of every attempt, whether success, abort or rollback, so the first sign of a bad build is a dashboard rather than a phone call.
Where to go next
If you are choosing hardware for a cellular-connected deployment, start with NORVI's page on ESP32 OTA update over cellular, then run the reference sketches on a bench unit and rehearse the failure cases deliberately: weak signal, dropped sessions, truncated downloads and power loss. An update path you have broken on purpose is one you can trust in the field.
Top comments (0)