Built-in test: A computerized self-diagnostic that verifies the integrity of a ROM image most commonly uses which method?

Introduction / Context:
Embedded systems frequently verify their program memory at boot or during maintenance to detect corruption. A lightweight, robust mechanism is needed to detect bit errors without requiring extensive resources. Checksums are widely used for this purpose.

Given Data / Assumptions:

• ROM contents are considered read-only during normal operation.
• Goal is integrity checking, not exhaustive functional testing.
• Computation must be feasible in constrained environments.

Concept / Approach:
A checksum condenses a block of data into a small numeric signature. The device computes the checksum over ROM contents and compares it with a stored reference value. If they match, the ROM is presumed intact. While CRCs offer stronger error detection, the term “checksum” broadly captures the standard self-test method. Other options like “checkerboard” apply to RAM tests, and “ROM listing” is a documentation artifact, not a test algorithm.

Step-by-Step Solution:

Verification / Alternative check:
Systems may use CRC-16/CRC-32 for stronger detection; these are specialized forms of check algorithms serving the same self-diagnostic goal.

Why Other Options Are Wrong:

• ROM listing: Merely a printout or dump, not a runtime diagnostic.
• ROM comparisons: Requires a second known-good ROM image in hardware; impractical for self-test.
• Checkerboard test: Pattern-sensitive test used for RAM, not ROM.

Common Pitfalls:
Storing the expected checksum inside the computed range without proper exclusion, or failing to initialize the checksum engine identically across firmware revisions.

Final Answer:
the check-sum method