Zephyr OS Coredumps: Separate Missing Memory from Broken Log Transport

A coredump can be incomplete because the build never selected the memory needed for diagnosis, or because the output path failed while exporting it. Those are different defects. Changing the decoder cannot recover bytes that were never captured or never reached the host.

For Zephyr OS, start with the selected memory policy and backend implementation. The following checks use v4.4.0 tagged source and focus on the logging backend. They are proposed diagnostic checks, not a guarantee that a particular board survives every fatal condition long enough to produce a dump.

Establish what the build intends to capture

The tagged coredump core selects a backend at build time. Memory capture is also configuration-dependent: minimum thread information, thread-oriented regions and linker-listed RAM are conditional paths. Stack-top selection and limits can reduce the captured stack range. Architecture data is emitted when an exception frame is supplied.

Therefore, “coredump enabled” is an inadequate description of diagnostic coverage. For the actual failing build, identify which memory policy is selected and which stack limits apply. Then map the debugger question to the required region. A request to inspect an unrelated worker's local state requires different coverage from examining the current thread's immediate failure context.

Make that mapping before a field incident. In a hypothetical multi-threaded controller, an investigator may need both the crashing parser's stack and a separate work queue's state. A minimal capture can be valid according to its configured purpose while still being insufficient for that investigation. That is a coverage mismatch, not necessarily a corrupt file.

Do not treat region bounds checks as a memory-health test

The core's memory-output routine rejects null endpoints and non-increasing ranges, then passes the selected bytes to the backend. Those basic checks do not establish that every selected address remains readable after a fault.

Review application-added regions and architecture assumptions accordingly. An external-memory area that is normally accessible may depend on hardware state affected by the incident. Whether it can safely be captured is a target-specific question. Avoid adding every possible address range merely to maximize dump size.

A practical coverage test uses known diagnostic values in the intended regions, triggers a controlled fault on a development target, and checks which values are actually recoverable. Such a test should include the real build configuration and must not be confused with proof of coverage for unrelated fault classes.

Trace the logging backend's own dependencies

The tagged logging backend processes pending logs, enters logging panic mode and emits a begin marker. It encodes output as hexadecimal log text and emits an end marker. Its local error reporting does not amount to an acknowledgement that an external host captured every byte.

This matters when the diagnostic transport shares resources with the failure. For example, a hypothetical fault involving the communications path used to collect logs can leave the application unable to export a useful dump even if memory selection was correct. Inspect the selected log backend, device and host capture arrangement rather than assuming panic mode makes the whole route independent.

Preserve the raw captured stream before manipulating it. Check whether the expected framing is present and whether the stream ends prematurely. A visible begin marker alone shows that export started; it does not demonstrate successful transfer of all selected memory.

Use two experiments instead of one large guess

First, validate coverage under a controlled fault where the output route is known to remain usable. Confirm that the required regions appear and that the retained build artifacts match the firmware under investigation. Then test the transport's relevant failure condition separately, using the board's safe development procedure.

Keep the resulting conclusions narrow. A successful logging-backend capture does not establish flash-backend behavior, and an intact current-thread dump does not prove that every thread or RAM region was included. The actionable result is a documented capture boundary: which memory the build selects, which dependencies export relies on, and which parts have actually been exercised.