1
\$\begingroup\$

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.

\$\endgroup\$
4
\$\begingroup\$

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.

\$\endgroup\$
4
  • \$\begingroup\$ lock-step core and ECC memory => RMxx series by TI types?? \$\endgroup\$
    – AlphaGoku
    Oct 20 '16 at 11:43
  • \$\begingroup\$ Yes, that kind of MCU. But you wouldn't want to bother using that for "non safety project", as you mentioned. Because it gets complicated very fast. Just take a step back and check what is the worst that can happen if your system fails. If it's not "somebody gets hurt", make it simple. \$\endgroup\$
    – dim
    Oct 20 '16 at 12:12
  • \$\begingroup\$ Ya thanks. So doing the things above is sufficient right? \$\endgroup\$
    – AlphaGoku
    Oct 20 '16 at 12:52
  • 2
    \$\begingroup\$ I don't know what is your application, you didn't explained that. So I can't guess what checks are appropriate in your case. If you're building an MP3 player, don't do any check at all, not even a CRC, it's fine. If you're making an access controlled doorlock, you might want to put a CRC on the tags serial numbers you allow, otherwise, if something gets corrupted, you may allow an unothorized person to enter. If you're building a flight recorder that will go in a Boeing, use RMxxx. You should be able to tell by yourself (especially since you didn't tell us what you're designing). \$\endgroup\$
    – dim
    Oct 20 '16 at 13:02
2
\$\begingroup\$

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.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.