13

I have a several chips (microcontroller, PIC16F1939) some of which have weird behavior (random resets, some pins pulled high some of the time). All of them are running the same software. I suspect that those chips have ESD damage (or some other internal damage). How can I be sure? X-ray? Any other method available?

W5VO
  • 18,738
  • 7
  • 64
  • 96
c0m4
  • 293
  • 3
  • 7
  • 4
    @com4, This is not a real answer, but the number of times I have heard someone be sure it was ESD damage and then found for sure that it was something else has been all of them. I used to act as a teaching assistant in a senior design class where almost every group blamed ESD at some point. My last company did the same and implemented strict ESD, we found firmware or case faults as the source for every single thing. – Kortuk Jan 12 '12 at 15:21
  • @Kortuk, I agree, ESD dammage is the boogeyman of electronics. The chips are damaged without a doubt, I just wonder if there is a way to find out if it ESD damage. – c0m4 Jan 13 '12 at 06:56

3 Answers3

7

The only reliable method I am aware of is decapping the IC (i.e. etching away the plastic housing) and using a microscope. It comes down to looking for visual clues and typical patterns: Overcurrent burns look different than ESD zaps on the integrated structures.

The trouble with ESD damage is that it can be very subtle. You can get anything between a slightly unusual behaviour (e.g. a small change in a MOSFET's gate threshold voltage) and a complete failure of the entire device.

zebonaut
  • 18,320
  • 4
  • 61
  • 107
7

I don't know of an "easy" way to confirm ESD damage - there appear to be quite a few methods used to detect failure in ICs, all of them pretty expensive. They include X-ray, Microscopy, IR Thermal Analysis, Curve tracer, TDR, etc.

This sample report of failure analysis is quite informative, detailing several different methods used to (eventually) find a fault.

However, I would check the code carefully to make sure there isn't an intermittent bug responsible for what you are seeing, or a problem with your circuit (e.g. EMI, power supply problems, etc)
Maybe try a few simple test programs which replicates various parts of the full firmware and see if the problem is specific to one part (or is present all the time)
Also check on Microchips site for any known silicon issues, I have been caught by this a couple of times in the past.

Oli Glaser
  • 55,140
  • 3
  • 76
  • 148
5

If you are 100% sure you run the chips in the same circuit and conditions then the chip is the most likely culprit. Does not need to be ESD damage, could for instance be mechanical or caused by a >> 5V power. Sometimes damage might be easy to prove (like a pin refuses to driver high), but in general it is very very difficult to prove or disprove the correct function of a complex chip. If your time is worth anything: throw away any suspect chips (or at least mark them and set them aside for very low priority work).

PS are you very sure you are not bitten by the read-modify-write bug/feature/pitfall?

Wouter van Ooijen
  • 48,572
  • 1
  • 63
  • 136
  • Not sure what you mean by "read-modify-write bug/feature/pitfall" – c0m4 Jan 13 '12 at 07:00
  • 1
    If you are not sure what it means and you are using 12 or 14 bit core chips you must surely read up on it! Basically, when you write one bit in an output port, the other bits will latch the momentary value of those bits as read by the input buffer. In some situations (glitch, heavy load) this can be different from the level the output buffer is trying to achieve. Check for instance http://www.cornerstonerobotics.org/curriculum/lessons_year2/erii_rmw_problem.pdf – Wouter van Ooijen Jan 13 '12 at 07:24
  • Thanks for the tip! I was not aware that the read stage read the actual state of the pin. Luckily the 16f193x range has a latch register just like the 16 bit chips. Not that I use it but it exists. However, I'm sure that this is not a problem for me as I don't have any real loads on the outputs. – c0m4 Jan 13 '12 at 10:00