Memory tests. - Does anyone bother?

[APL]

Hi folks,

I have just taken my 65c02 project off the top shelf again and I'd like to hear peoples opinion of testing onboard memory.

I've just tried a routine that tests zero page using the 55 & AA bit patterns and I put that as the first step of my board initialisation. Straight away I come across a couple of issues.

1. Nothing has been initialised yet, so how do you report the result of the test.

2. If I leave it later then by that time I'm using zero page & the stack. It probably isn't a good idea to stamp all over the stack with a memory test after initialisation.

I have free space in the memory map. I always know there should be 32K, but I could add another 16K if I needed, so I can see a use for the memory test to identify the top of memory as well - assuming contigious RAM.

Any thoughts?

[Aslak3]

My 6809 board tests it's memory immediately at reset. No stack is used. Error reporting is via an onboard sounder which requires a single byte on a port to generate a tone of given frequency. I think this works quite well on my fafairly simple SBC.

In terms of signalling error you could signal the other way, on success, of course.

I believe memory tests are very useful...

[BigEd]

A non-destructive test will save the value in each byte before writing and testing the two patterns - should be feasible, using X or Y to keep the value.

(Edit: but http://www.ganssle.com/testingram.htm doesn't think much of that idea. Worth a read. See also http://stackoverflow.com/a/20679170)

Outputting the result for a failure is more of a challenge, without making some minimal assumption, but going into a tight loop with no exit is one possibility. Better a machine which doesn't boot, than one which is unreliable.

Cheers
Ed

[BitWise]

I don't usually bother. The only time I had a problem with RAM it was due to someone putting a chip in the wrong way round.

[BigDumbDinosaur]

APL wrote:

I have just taken my 65c02 project off the top shelf again and I'd like to hear peoples opinion of testing onboard memory.

POC's firmware does several memory tests. The first test destructively checks direct page, page 1 (hardware vectors and SCSI work area),the MPU stack $00CD00-$00CDFF), and the TIA-232 buffers ($00CE00-$00CFFF). Following those tests, I/O is initialized, a POST screen is displayed and then all RAM from $000200-$00CCFF is non-destructively tested. During this second test, a count is displayed as testing progresses. In the event of an error, the system is halted and the last address that was tested is displayed. If the first stage test fails, there is no notification, as no hardware would be available to alert the user.

Incidentally, I use the alternating bit patterns %01011010 and %10100101 for checkerboard testing. A really detailed test would also do a single bit "walking" check on each location as well, but one might not have the patience to wait for such a test to complete.

[BigDumbDinosaur]

BigEd wrote:

(Edit: but http://www.ganssle.com/testingram.htm doesn't think much of that idea.

His comments seem more applicable to DRAM than the SRAM most of us use. At least with SRAM we don't have to worry about background radiation randomly flipping bits.

The traditional test using $55 and $AA seems to have been around since the dawn of the microprocessor and use of TTL memory. I use $5A and $A5 just to be perverse. One system I worked on years ago also used the single-bit "walking" test, which basically amounts writing $00 to the location being tested, setting carry and then rotating the test location nine times. If carry was set after the ninth rotation, then it was implied that all bits at the test location were good. It's a slow, but pretty thorough test. I don't know that I'd want to sit there and wait for a 65C816 to cycle bits through 16MB of RAM.

[BigEd]

It seems worthwhile to me to have a test which would detect addressing problems, though.
Cheers
Ed

[PaulF]

My bench computer includes a memory test - it runs after the LCD has been initialised so it can display the address of a memory failure. The LCD can be initalised without needing to use RAM at all.

The memory test itself generates a random sequence of bytes using a LFSR generator to fill the memory. It then resets the LFSR seed and confirms the values in memory match those generated by a re-run of the random sequence. Thiis will fail if the address lines are shorted or open and so tests more than just the RAM device itself. Indead, given the reliability of RAM chips, it was my wiring I was more interested in testing!

The test uses the first 4 bytes of zero page as temporary storage. Of course, this means these bytes can't be tested but if these are faulty, the test will fail at byte 0004 or 0005, indicating a problem with the RAM device.

So far, the only time the test has failed was when I replaced the 32K RAM with an 8K device as a test of the RAM test!

[APL]

Interesting replies, thanks.

BigEd wrote:

is more of a challenge, without making some minimal assumption,

So. I guess I am being a bit paranoid. I could initialise the VIA port and then I have four LEDs and the LCD avaliable.

PaulF wrote:

So far, the only time the test has failed was when I replaced the 32K RAM with an 8K device as a test of the RAM test!

Then what would the best means of differentating between a memory error and the end of memory, it seems either condition would throw an error. Is it just a matter of testing against expected bounds?

[GARTHWILSON]

In my first big project (1987 or so), I had it test every RAM location and also get a checksum on the ROM. The test was never failed. I can see testing for RAM quantity, but ICs have to be put in by hand, so jumpers could be too; and the wrong type of IC, or one put in backwards, will make things fail immediately, so you'll definitely catch it. I have never, ever, seen RAM fail once in service, so I don't test anymore.

[BigDumbDinosaur]

BigEd wrote:

It seems worthwhile to me to have a test which would detect addressing problems, though.
Cheers
Ed

I agree to an extent. However, a memory bus fault would not be detected, since the MPU wouldn't actually know what the RAM hardware is seeing on its address inputs. You'd have to devise a test that checks all addresses, and then rechecks for single bit address bus failures. In practice, once a design is working and as Garth noted, faults rarely occur.

[BigEd]

The idea in the stackoverflow answer I linked was pretty direct and efficient, and apparently helped with a production problem. So it needn't been terribly expensive.

I would think a hobby machine might well fail a test after a long time idle, depending on construction, treatment and environment.

Cheers
Ed

[BigEd]

Just came across yet another thread on Stardot forums about memory trouble - clearly it does happen, so here's a pointer to some code from Mike Willegal:
http://www.willegal.net/appleii/6502mem.htm

Cheers
Ed

[PaulF]

APL wrote:

PaulF wrote:

So far, the only time the test has failed was when I replaced the 32K RAM with an 8K device as a test of the RAM test!

Then what would the best means of differentating between a memory error and the end of memory, it seems either condition would throw an error. Is it just a matter of testing against expected bounds?

The only real way to tell the end of memory from a memory fault is to check the address the test fails at. If it fails at an expected location (e.g. $2000 for an 8k RAM, $8000 for a 32k RAM) then this is likely to be the end of memory. If it fails at some random address, this is probably a fault. Of course, once you have a failure, you know how much memory is available to use - just don't use the address the test fails at or anything above it!

[BigEd]

PaulF wrote:

Of course, once you have a failure, you know how much memory is available to use - just don't use the address the test fails at or anything above it!

Here's a thing, from well before my time:

Quote:

There were 32 bit locations per drum word, but only 31 were used, permitting a "restoration of magnetic flux in the head" at the 32nd bit time. (I never understood why the 32nd bit was not used for parity checking - there was no drum validity checking.) A utility could be run to map defective locations on the drum, and advise users and loaders of the defective tracks, but marginal and failing drums caused interesting problems.

From http://ed-thelen.org/comp-hist/lgp-30.html
and see also my post over at http://anycpu.org/forum/viewtopic.php?f=22&t=136
(Bear in mind that the drum was the RAM of this machine, and also stored the register data.)