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

Question

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.

Awaiting your reply,

best regards...

Answer 1

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.

Answer 2

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.

Answer 3

As far as I remember there are some standard test procedures for microcontrollers in the IEC 60730 Class B standard. The best thing that I could find in a quick search was a Freescale Application Note. OTOH I cannot tell if these things improve reliability at all (standards sometimes are stupid).