Frame buffer rows repeating: a 1 M×16 SRAM with one address line open
A display tester uses an STM32 FMC to drive a 1 M×16 asynchronous SRAM (A0–A19, 2 MB) as a 1024×768 16-bit frame buffer starting at 0x6000_0000. The image is written linearly, word address = y·1024 + x. Rows 512–767 display correctly and rows 256–511 are correct, but rows 0–255 show a copy of rows 512–767, so the top third of the screen repeats the bottom third. A production memory test that writes and reads back 0xAA55 at every word address passes. Raising the FMC wait states from 2 to 6 changed nothing. The SRAM's A19 pin is connected through a flying lead because the original connector was damaged. With a 512-row test image the board looks perfect, which is why the fault reached the customer. Bus timing was verified with a logic analyser and shows clean, well-margined writes.
1. Use the address arithmetic to identify the faulty signal and explain why exactly rows 0–255 are affected.
Read the worked answer
Address size. 1024 × 768 = 786,432 words, which needs 20 address bits (A0–A19). Row y starts at word y × 1024 = y × 2^10, so row 512 starts at word 512 × 1024 = 524,288 = 0x8_0000 = 2^19 - exactly the A19 boundary.
The fault. If A19 is open (stuck low at the SRAM), every access at or above 0x8_0000 is physically performed at address − 0x8_0000. Rows 512–767 occupy 0x8_0000–0xB_FFFF and alias onto rows 0–255 at 0x0_0000–0x3_FFFF. Because the image is written top-to-bottom, the writes for rows 512–767 arrive last and overwrite rows 0–255. Rows 256–511 (0x4_0000–0x7_FFFF) have A19 = 0 already and are unaffected.
Why the picture is self-consistent. Reads alias the same way, so rows 512–767 read back the data written for rows 512–767 and still look right; rows 0–255 read the same physical cells and show the repeated content.
Why the 512-row image passes. 512 rows = 0x0_0000–0x7_FFFF, all below 2^19, so A19 is never exercised. Wait states cannot matter: this is a wiring fault, not a timing fault, which is why raising them changed nothing.
2. Explain why the 0xAA55 test cannot detect this fault and design a test that does, stating exactly what it will report.
Read the worked answer
Why it passes. The test writes the same value to every address. Wherever the write lands, including the aliased location, a read of that address returns 0xAA55 because that is what was written last. Aliasing is invisible to any test whose data does not depend on the address. The same weakness hides stuck address bits, address-line shorts and mirroring caused by partial decoding.
Test that catches it. Make the data a function of the address, for example write the 16-bit value (address XOR 0xA5A5) to every word, then read back and compare. A read of 0x8_0000 returns the value written for 0x0_0000, so the comparison fails and reports the address pair (0x8_0000 read, expected value for 0x8_0000, got value for 0x0_0000), which immediately points at A19. A walking-1 across the address bus gives the same diagnosis with a clearer signature: with bit 19 stuck, the 1 written at 0x8_0000 appears at 0x0_0000.
Combine with data patterns. Address-dependent data finds address faults; walking-0/1 and checkerboard patterns find data-line and cell faults. A march C− element sequence with an address-dependent background covers both and is cheap enough to run at boot on a 2 MB device. Also test the top and bottom of each decoded region explicitly, and log the failing address rather than a pass/fail bit - the address pair is what identifies the bit.
3. The flying lead is suspected. Describe the repair verification, and give a firmware-only workaround with its cost.
Read the worked answer
Repair and verification. Re-terminate A19 at the SRAM pin. Then: (1) continuity and resistance from the MCU FMC ball to the SRAM pin (a few tenths of an ohm; an open or a high-resistance joint is the failure), plus a check for a short to an adjacent address line; (2) rerun the address-dependent test with no failures at both ends of the 1 M range; (3) scope A19 at the SRAM pin during a write to 0x8_0000 and confirm a clean 0–3.3 V transition with the FMC's setup/hold respected; (4) check that the flying lead has not degraded other signals - a long unreturned wire adds inductance and crosstalk, so rerun the full memory test at temperature extremes.
Firmware workaround. Keep the frame buffer entirely below 0x8_0000, i.e. use at most 512K words. At 16 bpp, 1024 × 480 = 491,520 words fits, so a 1024×480 panel or a reduced vertical resolution works, or use 8 bpp palette mode for 1024×768 (786,432 bytes = 393,216 words) with a colour lookup in the LCD controller. The cost is either lost vertical resolution or reduced colour depth and extra DMA work. Deliberately exploiting the alias (writing rows 0–255 only once) is not a workaround: it cannot store 768 distinct rows in 512K words.