ALU,RAM and ROM test for LPC 1778

Question

Im working on a non safety project and as part of the Initialization tests I wanted to check the internal memory of LPC1778 for proper functionality before beginning the application.

I dont intend to test all the addresses as its not feasible for the application. Im planning on implementing this 3 in 1(ALU,RAM and ROM) test the following way:

1.Store an array of 32 numbers in ROM(const array) whose member values are powers of 2. Example-> 1,2,4,8...upto 2 power 32(since LPC1778 has a 32 bit data bus)

2.Read these values from ROM(const array) and write them into an array of size 32 located in RAM(non-const array allocated on stack by calling a function that declares such an array locally).

3.Compare each value in the local array to a value calculated by the ALU(left shifting bit by bit).

Is this sufficient to test or must I also check for short of address bus(if they are shorted and i try to write to an invalid location wont the exception handler be triggered?)
Also, must i also check for other operations by the ALU like addition,subtraction,NOT,XOR etc.. I also have the Code Checksum stored in a external flash that will be compared against by calculating it in the code during runtime. (Checksum calculated in code==Checksum read from flash)

Any suggestions. Please help.

Im using Keil IDE.

Answer 1

What are you afraid of? That an internal route between gates within the chip be broken or shorted? If it was the case, it would certainly mean the chip was physically broken. I mean, broken as in "split in two halves because of some thermal stress". In which case it wouldn't work at all. What you are trying to test here isn't worth it, the probability that one internal trace is wrong is more than unlikely.

What would be more likely are single event upset, which you can't prevent by prior testing (and which is very difficult to handle anyway, you'd need probably some lock-step core and ECC memory).

Eventually, use some CRC for critical data in memory, to react in case it gets corrupted. That is the best you can do.

Answer 2

Memory check: Run a CRC over the entire memory contents except the place where you store the expected value, and determine the expected value during build time. Since the expected value is different for each build, this would also catch incompletely written firmware (which is far more likely than broken memory)

ALU check: no point, really. An exhaustive check would be an awful lot of code, and a quick check would likely miss something. Without knowledge of the internal wiring you wouldn't know which tests make sense (e.g. adding 0x55555555 to 0x55555555 to check for accidentally connected neighboring bits only works if the actual implementation isn't interleaved). The ALU is factory tested, both with an optical inspection before packaging and with a test appropriate for the physical layout it has.