32-bit uC failures and catching the failure as an user

I am working with 32 bit ifx uc.

i have seen bit field errors in registers, ram errors, pflash errors as very common..

can you please tell me some more issue where a high end 32-bit uC coulld have errors?

Or resources to find such info?

I have to create test programs to catch it.

best regards...

-
What is a "32bit ifx uc"? You've know these errors are common or do you want to determine if they are? –  jpc Apr 8 '11 at 21:29

This sort of error is very hard to catch using software. Essentially you're taking something that is unstable when running software and running software on it to catch the error. And if you do catch the error, then what? If a register is getting corrupted then you'll have a hard time probing the signals inside the CPU. This could be a futile effort. Instead, I would focus on the basics of electrical engineering.

Here's what I'd be looking at:

1. Power. If power is questionable then you could have issues. Other than the average DC level, you have to look at noise. This can be hard to probe, because you need to look at the noise directly at the CPU's power pins using a good scope with careful o-scope probe considerations so you don't pick up other noise. Check external memories too.

2. Power pins. I have actually seen chips work with some or all power pins unconnected. In one case the PLL power pins for a chip were not powered, but the chip operated mostly fine except in one or two specific cases. Check external memories too.

3. Clocks. Make sure the clocks have good signal integrity. Like power, this needs to be probed at the CPU's pins with a good probe setup.

4. Reset. Make sure there are no glitches or noise on the reset line(s). A momentary glitch could cause only part of the CPU to reset, causing no end of issues.

5. JTAG/Debug connectors. Are the pins pulled high or low, or are they left floating. Noise on these pins can cause really strange behavior.

6. Floating "unused" pins. In some cases, CPU's can have large numbers of unused I/O pins that need to be pulled, driven, or tied to a valid logic level. Even if the pin is not used, a floating pin can cause lots of noise inside the part.

7. Bad signal integrity on the PCB can cause noise places that you don't want. One board I saw had long traces on a memory bus, and nothing was terminated properly. There was 2 volts of overshoot/undershoot on those signals that would occasionally cause something "unrelated" to fail. On not-rare-enough occasions it would cause latchup and some chips would literally blow up.

-

I've written some code for applications that required extreme resistance to failing in an unsafe manner. The code was written entirely in assembly language, and kept two copies of many important variables, with a fixed delta between them. Rather than computing and storing the value for the second variable based upon the first one, the code would be something like:

' Code to add reg1a to reg2a and maintain delta invariants
if reg1b  reg1a + REG1_DELTA then error
if reg2b  reg2a + REG2_DELTA then error
reg2b += reg1b - REG1_DELTA
reg2a += reg1a
if reg2b  reg2a + REG2_DELTA then error


Any register that got corrupted would immediately get flagged as an error. It would be unlikely for multiple registers to get corrupted in such a way as to coincidentally avoid causing an error. Because the 'b' registers aren't computed based upon the 'a' registers, a glitch which hits an 'a' register won't cause the proper corresponding change in a 'b' register, no matter when it occurs.

-
This is one of the more useful techniques of immunity aware programming. –  davidcary May 2 '11 at 1:56
@davidcary: Nice article, though the 'token passing' scheme could be made safer by using +=, ^=, or other such techniques to manipulate the 'token' rather than direct assignment. Otherwise a program-counter glitch that lands on the token assignment could cause things to appear normal even when they are not. –  supercat May 2 '11 at 14:16