C51 data memory test

Many reasons.

1) Capacitive coupling. I can write 0x15 to the data bus but have an address decoding failure so I never manage to activate any RAM memory at the address. The next operation can read back the value 0x15 from the bus, since there are nothing that actively drives the lines high or low.

2) You seldom have broken bits in a RAM memory. But when doing factory tests, you often (in relation to bit errors in the memory) have solder problems that may result in:
- aliasing, where multiple addresses actually maps to same address in the RAM
- open data lines, where some bits always reads as zero or one (or suffers from capacitive coupling)
- connected data lines, where bit x always reads the same as bit x-1 or bit x+1.
- ...

So a memory test program must specifically test that all data lines are operating individually. And that all address lines are operating individually. And if address and/or data lines are multiplexed, then the code must perform the tests in a way that the multiplexing doesn't fool the tests into false acceptance.

Testing data lines is often done with walking patterns. 00001 -> 00010 -> 00100 -> 01000 -> 10000 and the inverted variants 11110 -> 11101 -> 11011 -> 10111 -> 01111.

But testing the address lines can be really interesting in a multiplexed scenario where an address line can falsely affect a data line or the reverse and where not only a0 and a1 may be neighbours but a0 and a8 may also be neighbours or even same line.

In the end, a generic test is quite large - too large to be funny to describe in a forum post here. Many simplications are allowed when there is knowledge about the hardware. But it still requires a lot of thought. And if you don't trust the internal RAM, you have to figure out how to perform at least the internal RAM test while making best possible use of the processor registers - remember that the stack and auto variables would assume working RAM ;)

Many reasons.

1) Capacitive coupling. I can write 0x15 to the data bus but have an address decoding failure so I never manage to activate any RAM memory at the address. The next operation can read back the value 0x15 from the bus, since there are nothing that actively drives the lines high or low.

2) You seldom have broken bits in a RAM memory. But when doing factory tests, you often (in relation to bit errors in the memory) have solder problems that may result in:
- aliasing, where multiple addresses actually maps to same address in the RAM
- open data lines, where some bits always reads as zero or one (or suffers from capacitive coupling)
- connected data lines, where bit x always reads the same as bit x-1 or bit x+1.
- ...

So a memory test program must specifically test that all data lines are operating individually. And that all address lines are operating individually. And if address and/or data lines are multiplexed, then the code must perform the tests in a way that the multiplexing doesn't fool the tests into false acceptance.

Testing data lines is often done with walking patterns. 00001 -> 00010 -> 00100 -> 01000 -> 10000 and the inverted variants 11110 -> 11101 -> 11011 -> 10111 -> 01111.

But testing the address lines can be really interesting in a multiplexed scenario where an address line can falsely affect a data line or the reverse and where not only a0 and a1 may be neighbours but a0 and a8 may also be neighbours or even same line.

In the end, a generic test is quite large - too large to be funny to describe in a forum post here. Many simplications are allowed when there is knowledge about the hardware. But it still requires a lot of thought. And if you don't trust the internal RAM, you have to figure out how to perform at least the internal RAM test while making best possible use of the processor registers - remember that the stack and auto variables would assume working RAM ;)