PCBA Burn-In Testing: What to Log When an Embedded Board Runs Overnight

Consider a hypothetical embedded terminal left running overnight. In the morning, the display is on and the application responds. That looks encouraging, until the logs show that the application restarted during the run. Did the board remain stable, or did automatic recovery hide a failure? For developers, PCBA reliability testing includes deciding what evidence the software should produce while the hardware is under test. A printed circuit board assembly can remain powered without completing the operations its application depends on. The test needs a way to distinguish those states. Burn-in is a screening activity in which hardware operates for an extended period, often at elevated temperature, to expose latent defects. The electrical and environmental conditions need their own engineering justification; an overnight run at room temperature does not reproduce an elevated-temperature profile. The software has a narrower job: run the planned workload and preserve evidence of interruptions. Define what one completed test cycle means For the terminal, suppose normal operation includes updating a display, storing a local record, and exchanging data over Ethernet. These are proposed test activities for this example, not results from a particular board. A CPU workload alone leaves some of that path untested. Give the test application a repeatable cycle with observable results. It might generate a record, write it to a dedicated test area, read it back, compare the contents, and send a sequence-numbered message to a test server. Specify whether the storage check must include durable persistence; a read served from cache tests a different path. Keep storage activity bounded by the test plan. Writing continuously at the maximum possible rate changes both the workload and the wear imposed on flash. Also distinguish a rendering operation reported as complete from an image verified at the panel. Software counters cannot prove that the physical display remained correct. Count completed cycles and record the first failed operation. A rising counter is useful only if it advances after the required checks succeed. A timer that increments independently of the work can keep reporting progress after the worker has stalled. Observe the board from another machine An external collector can preserve evidence when the board loses power or its application stops. Have it record incoming progress messages, missed-message intervals, reconnects, and test-session identifiers. Use a monotonic clock to measure elapsed intervals within each running system. Add wall-clock timestamps for correlation with instruments, and document clock synchronization where timing matters. After a board restart, begin a new timing segment instead of assuming its local elapsed time continues across boots. A heartbeat should carry more than an indication that a process exists. Include the last completed cycle, current phase, and recent error counts. This lets the collector distinguish an active test from a responsive application whose storage worker has stopped progressing. Loss of communication is still ambiguous. It could involve the board, cable, switch, server, or collector. Record it as an observation until other evidence supports a cause. External collection also cannot guarantee delivery of the final message before a sudden failure. Keep recovery visible A watchdog or service supervisor can return a failed system to operation. That is useful product behavior, but the recovery must remain visible in the test record. Record application startup separately from system boot. Use a per-launch identifier for the test process and a boot identifier where the platform provides one. Correlate them with serial-console output or other independent observations. A changed process identifier alone does not establish that the whole board rebooted. If the platform exposes a reset cause, capture it early and verify how that field behaves on the selected hardware and firmware. Do not assume every watchdog driver reports the same information. Define what happens after recovery. The collector might retain the failed session and open another session for diagnostic continuation. Whether that continuation satisfies acceptance requirements is a separate decision. Automatic restart should never silently turn an interrupted run into an uninterrupted pass. Put electrical and thermal context beside software events When a timeout occurs, the surrounding conditions matter. Preserve the workload phase, connected peripherals, cooling arrangement, software build, and available instrument readings with the event. Measure supply voltage at the board input when checking for lead-related voltage drop. A bench supply's output reading may not represent the voltage reaching the connector under load. Similarly, label temperature readings by their source: chamber air, package surface, board location, or an internal sensor. Those readings are not interchangeable. Sampling also limits the conclusion. A slow current log can show a sustained change while missing a brief disturbance. Choose instruments and acquisition settings for the event being investigated; an uneventful low-rate trace cannot rule out every transient. Make each failure record useful for the next investigation The collector should retain enough context to guide the next measurement. For the example terminal, these are useful starting points: Observation Evidence to preserve Question to investigate Progress counter stops Last completed cycle, active phase, application messages Which operation stopped completing? Application relaunches Launch identifier, boot identifier, exit information Did the process restart or the board reboot? Received data differs Expected payload, actual payload, sequence number Where did the mismatch first appear? Board disconnects Link events, collector status, console output, supply trace Is the interruption local to the board? Avoid assigning a root cause from a single symptom. For example, a network timeout during a storage operation establishes timing, not that storage caused the timeout. Preserve the original run, then change one relevant condition for the diagnostic rerun. Check the observer before trusting the result Before starting a batch, deliberately stop the test worker and confirm that the collector detects stalled progress. Restart the application and verify that the new session is visible. Disconnect the communication path and check that the missing interval remains in the record after reconnection. At the end, reconcile requested exposure, observed runtime, completed work, and interruptions. A passing software workload is evidence for the functions and conditions exercised. It does not replace environmental qualification or establish service life. Its practical value is that a board can no longer appear stable simply because the application recovered before anyone looked.