Have you ever written a RAM test from scratch? What are some issues you need to test?

The key is that a RAM test must detect real physical fault classes while not relying on the very RAM it is testing. Fault classes and what to test for:

• Stuck-at faults (SA0/SA1): a cell (or data line) permanently reads 0 or 1 regardless of what's written. Detected by writing and reading back both 0 and 1 to every bit.
• Address-decode faults / aliasing: a faulty address decoder causes two different addresses to map to the same physical cell, or an address to access no cell. Detected by address-in-address (write each location's own address into it, then read back) and by patterns that distinguish every address.
• Coupling / bridging faults: writing one cell disturbs a neighboring cell (idempotent coupling, inversion coupling, bridging shorts between cells/lines). Detected by March algorithms that write/read in specific orders so a disturbance in one cell is caught when its neighbor is later read.
• Data-retention faults: a cell loses its value over time (leaky storage). Detected by writing a pattern, waiting (a delay), then reading it back.
• Data-line / shorted-bit faults: detected by walking 1s / walking 0s within a word.

Common algorithms:

• Walking 1s / Walking 0s — good for data-line and some coupling faults.
• Checkerboard (0x55/0xAA) — catches some coupling and stuck-at, tests adjacent-cell patterns.
• March tests (MARCH C-, MARCH B, etc.) — the standard for thorough coverage: defined sequences of ascending/descending read-write operations that cover stuck-at, transition, coupling, and address faults efficiently (linear in N).
• Address-in-address — specifically targets address-decode/aliasing faults.

Critical practical issues when writing the test:

• Don't depend on the RAM under test. You cannot keep variables, the stack, or loop counters in memory you are testing. Use CPU registers, run from ROM/Flash, and carefully order operations so the test code/state never lives in the region being verified. Often you test scratch RAM in two halves, relocating the stack to the already-verified half.
• Beware caching and write buffers. A cached or buffered access may read/write the cache, not the actual RAM cell, hiding faults. Disable caching / use uncached or volatile accesses / flush write buffers, and mark pointers volatile so the compiler doesn't optimize the write-then-read away.
• Beware compiler optimization removing "dead" writes/reads — use volatile.
• Memory-mapped peripherals / aliases in the region must be avoided.
• Destructive vs. non-destructive: power-on tests are usually destructive; if testing RAM that holds live data, you must save/restore each location.
• Time budget: exhaustive tests are O(N²); March tests give strong coverage at O(N), important for large memories and boot-time limits.