Before the first ESP32 ships to a customer

On your desk every problem is a serial cable away. At a customer it is a support ticket, a phone call and maybe a trip. These are the things to have in the firmware before the first unit leaves, because most of them cannot be added over the air later.

1. A partition table with two app slots

Without a second slot there are no updates over the air, and the partition table cannot be changed over the air either. Decide it before production: if the application is larger than half the flash, there is no room for a second copy. More on OTA and partitions.

2. Updates with a rollback that you have tried

CONFIG_BOOTLOADER_APP_ROLLBACK_ENABLE on, and the new image confirmed only once it has proved it works, ideally once it has reached your server.
Images built for another chip refused before they are sent.
Tested: send an update with a wrong WiFi password on purpose and watch the device come back.

3. A way to reach the device

Assume no public address, no port forwarding and a firewall that only lets HTTPS out. The device has to connect out and keep the connection, so that you can open its page, its API or its settings from your office. The options, and what each needs.

4. Logs you can read without a cable

The serial log is where every answer is, and in the field nobody is reading it. Send it somewhere, with a buffer so that lines written while the connection is down are not lost, and keep enough of it to look back at the hour before a complaint. Remote logging.

5. Crash reports

A device that panics and restarts looks to the customer like a device that "sometimes hangs". Keep the reason and the backtrace across the restart, send them on the next connection, and keep the ELF of every build you ship so the addresses can be turned into function names and lines. Decoding crashes from the field.

6. Health numbers

Free heap and its lowest point, the least free stack of any task, WiFi signal and disconnects, uptime. A slow leak shows in the heap a week before it shows as a crash. Heap and stack monitoring.

7. Knowing what runs where

A version in every build, and the device reporting it, so that a ticket starts with the firmware it runs, not with a question to the customer.
A name for each device that support can use, not only a MAC address.
Alerts when a device stays offline or crashes, so that you hear before the customer calls.

8. Memory left for all of it

Each of the above costs RAM, and a TLS connection alone is often 25 to 40 KB on an ESP32. Measure the free heap with everything running, under traffic, before the hardware is fixed. TLS memory and how to reduce it.

One component for the list

Pinscope covers 2 to 7 in one component: remote access to the device's own web server, logs, crash reports with decoding, health metrics, OTA with a rollback that waits for the device to reach the server, versions and alerts, over one outbound connection that needs 9.4 KB of RAM in total. The partition table is still yours to get right.

Try it

Three devices are free, and no card is needed. Create an account, or read the five-minute guide first.