What to log on a device so you can debug it from the office

A field report usually reads “it stopped sending data on Tuesday”. Without logs on the device, the next step is a site visit. With a small, well chosen set of data, you can often say from your desk whether it was power, the network, the sensor or the firmware.

The constraint is that a device has little flash, little RAM and a thin uplink. So the question is what to keep, not how to keep everything.

Always record the reset reason

Every MCU tells you why it last restarted. STM32 parts expose flags in the reset and clock control register: power-on, brown-out, independent watchdog, window watchdog, software reset and pin reset. ESP32 returns a reset reason through the IDF, including brown-out, task watchdog and panic. Read it at boot, store it, and send it with the first message after every restart.

A fleet where most resets are brown-out points at the supply. A fleet where they are watchdog points at the code. You cannot tell them apart without this one field.

Counters beat text

Plain counters survive a thin link and cost almost nothing:

• Boot count, and the reset reason of the last few boots.
• Uptime since the last boot, and the longest uptime seen.
• Failed Wi-Fi or cellular connects, failed publishes, broker disconnects.
• Failed sensor or Modbus reads, and CRC errors.
• Minimum free heap since boot, and minimum free stack for each task.

Send them as a periodic health message. A rising count of Modbus timeouts on one device, next to flat counts on its neighbours, tells you a cable or a node is at fault.

A ring buffer in RAM

Keep the last few dozen log lines in a circular buffer in RAM, a few kilobytes at most. On a fault, a panic handler or the watchdog path can copy it to a small flash or retained-memory area, so the lines leading up to the crash are available after the restart. Send them with the next health message, or on request.

Writing every log line to flash wears it out, since flash typically survives on the order of 10,000 to 100,000 erase cycles per sector. Write on faults, not on every message.

What not to log

Do not log credentials, tokens, Wi-Fi passwords or full payloads that include personal data. Do not log at high rate in a tight loop, because the logging itself changes timing and can cause the fault you are chasing. And do not rely on a UART console that nobody will ever plug into.

What this does not replace

Remote logs tell you what happened, not always why. A bad power supply leaves little trace in firmware, and some faults need a scope on site. Still, good counters narrow the search from “anything” to “probably power”.

---

If your devices fail in ways you cannot reproduce on the bench, book a discovery call and we can review your telemetry design, as part of our embedded firmware work.