AVR Freaks

RAM tests can be written in such a way as to not use any RAM (I expect, I've done this on 6809 in the past, so it's almost certainly possible on AVR). As far as Flash goes, I'd tend to agree with you, but I have encountered clients who insist on ROM or Flash checks.

FWIW,

One time I was asked to add memory testing to a design where, upon power up the code first wrote to the RAM 0x55 and 0xAA, then read it back, then wrote the reverse(0xAA, then 0X55) to the ram and read it back to see that the RAM was OK. This was done to EXTERNAL RAM. We tested this with some ram chips that were confirmed faulty with a tester and the micro picked up on it and showed FAILED on the screen.

The point to this is, that I agree with Cliff that testing internal RAM is kinda pointless, Code can check external RAM though.

Testing ROM is a waste of code space.

Jim

In an AVR true, but I was testing an 8051 design at the time. BUT, if you read the datasheets on the AVR's with external access you can actually use the lower area with a little bit of work.

Jim

Chances are if the ROM is corrupt in the CRC routine itself, the CRC routine stil wouldn't return a valid result, but yes it is possible. So your chances of catching a fault are very high, but not 100%. Redundant checks using different algorithms will increase the reliability of the test, as it is unlikely for a fault to result in a pass on both.

As for the RAM test, it is very possible to start a RAM test without relying on any RAM before hand.

One usually does not call into POST routines, they are typically jumped into, only after POST routines pass, is the stack initialized and allowed to be used. If RAM is needed during testing, a small area is tested & verified first, allowing the stack, or any other data to be placed there. Then the remaining RAM is tested using the larger, more complete routines.

One can consider the microcontrollers used in Magneti Marelli ECUs - they do an absolutely paranoid security test.

- CRC on the prom contents
- ram check (inlined, no stack) with read-write test on every byte
- stack check for push-pull at every position on the stack
- integrity test for eeprom (two copies of each data block; any discrepancies and the eeprom is wiped clean)
- eeprom confirmation after every write

Though you should bear in mind that a lot of the prom is tables which can have a devastating effect on an expensive (several thousand pounds, often) engine if their values are corrupted.

Neil

As an old bit-pusher I was interested in the "March B" "walking" test, as I wrote a few of those for 80186 a few ;) years ago. While our "quick" test was quite similar, the "long" test did a check not mentioned there: After each bit was set/cleared, the entire SRAM space was checked to see that not only did >>that<< bit respond correctly, but that no other bit was following the value of the bit being changed. While it was most common to see a series of bits change (e.g., a short in an address line) there were a few traps of a rouge single-bit elsewhere in those early SRAMs. On a production AVR I'd guess that would be even less likely than any SRAM failure. But with modest internal memory sizes on, say, a Mega88 it shouldn't take that long to do the exhaustive test.

IIRC it took about 20 minutes for the "long" test on 384KB of SRAM, which included other passes with random (well, really "non-sequenctial") vs. sequential testing.

Well, there are certain places in the world where such "insane bureaucracy" seems to be very important. Unfortunately, those places are big enough to have significant effect with their "neighbors" and effectively limit imports over a wide area.

If you live in that area or hope to export to that area, there is NOT much you can do.

For example, you have probably heard (mostly bad stuff) about RoHS. Well, there is a replacement coming into effect at the end of this year called REACh. If you liked RoHS, you will LOVE this one. And it WILL effect us, here. It is otherwise known as (EC 1907/2006). It deals with the Registration, Evaluation, Authorisation and Restriction of Chemical substances.

Jim