Take the 2-minute tour ×
Electrical Engineering Stack Exchange is a question and answer site for electronics and electrical engineering professionals, students, and enthusiasts. It's 100% free, no registration required.

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...

share|improve this question
    
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
add comment

3 Answers 3

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.

share|improve this answer
add comment

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.

share|improve this answer
    
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
add comment

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).

share|improve this answer
    
Wow, that's a truly scary document! If done properly according to the spirit of the law, meeting that spec would add a huge amount to the cost of the unit (I'm talking a periodic in the field test, not a simple test at manufacturing time). It seems to me that some of what Freescale is suggesting in that doc is to meet the letter of the law, not the spirit. –  user3624 Apr 8 '11 at 21:47
    
@David probably all of this document is about how to meet the letter of the law especially since the standard is quite strict on what should be verified. The question remains if these tests have some practical uses. :) –  jpc Apr 8 '11 at 22:35
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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