Killing microcontrollers: most common causes

[weetabixharry]

I have just killed 2 PIC16F88 microcontrollers and I cannot see how. I am wondering if anyone with experience in this area could suggest what the most common causes of MCU death are.

The only suspicion I have is that, since the last revision of the circuit design I'm working on, I have swapped my 7-segment displays from common cathode to common anode type. Therefore, my MCU pins are now having to sink the current, whereas before they were the source of current. I have checked that I am working within the absolute maximum ratings of the chip, but could pushing too much current into the input pins completely kill the chip (so it cannot be detected by the programmer)?

 

[bigdogguru]

It's possible, however without a schematic of your design, any advice would be pure conjecture.

Please post a detailed schematic of your design.

Also be aware, often the Absolute Maximum Ratings are not intended to be Operational Maximum Ratings.

BigDog

 

[weetabixharry]

Please post a detailed schematic of your design.

Thanks for your reply. Here is my schematic:

View attachment voltmeter.bmp

and some comments:

This is a very basic voltmeter with dual 7-segment display (D16 is the decimal point of the second digit and is not connected).

• Pin 1 is a fairly accurate 3.3V reference for A/D conversion of the input at pin 2.
• Pins 3 and 9 are only connected to ground due to space restrictions. These have been configured as inputs.
• Pin 8 selects between digit 1 and digit 2 of the dual-digit display.

 

[FvM]

I can't detect critical points in the schematic, but may be it's incomplete or the real circuit doesn't comply with the schematic.

I presume, you have also ICD pins connected.

 

[ADGAN]

You haven't given 5V to the MCLR pin (5th pin) can't that be a problem?

 

[weetabixharry]

I can't detect critical points in the schematic, but may be it's incomplete or the real circuit doesn't comply with the schematic.

I presume, you have also ICD pins connected.

I don't have ICD pins connected, as space is very limited (and I've never actually tried ICD). The PIC sits in a socket and is removed to program. The schematic is complete, unless there is an error I have not found (I have checked pretty carefully for mistakes or shorts).

To clarify, the circuit seemed to show some signs of life at first. With a 4.8V input, it would display 8.7V. Then, if I altered the input voltage, the display would change to weird values. Finally, it would get stuck displaying something that looks like upside-down "tt" (an invalid output) and I would have to power cycle. Eventually, it got stuck at upside-down "tt" permanently and the chip seems dead. Yes, I did the same thing with 2 chips because I'm an idiot.

You haven't given 5V to the MCLR pin (5th pin) can't that be a problem?

I have disabled the /MCLR function in software. The circuit was checked on breadboard with common cathode 7-segment displays and worked fine. I've now soldered it into veroboard with common anode displays and created a PIC-killer :???:

 

[bigdogguru]

A few possible issues:

Issue 1:

Reference: PIC16F87/88 Datasheet, Section: 18.0 ELECTRICAL CHARACTERISTICS - Absolute Maximum Ratings, Page 161

Maximum current sunk by PORTA ................................................................100 mA
Maximum current sourced by PORTA ...........................................................100 mA
Maximum current sunk by PORTB ................................................................100 mA
Maximum current sourced by PORTB ............................................................100 mA

Assuming a typical V_F of 1.7V per segment and the 220Ω current limiting resistors of the current design:

(5V - 1.7V)/220Ω = 15mA per segment

15mA x 7 segments = 105mA current sunk by PORTA

Therefore if all 7 segment are active, it is conceivable that the specified maximum current sunk by PORTA can be exceeded.

Of course, these calculations are made assuming typical values, the actual current sunk will vary depending on several factors including the particular characteristics of the 7-segment display as the exact V_F of the device can vary widely.

In any event it is generally not prudent to push a device close to its absolute maximum ratings.

Therefore, I would suggest raising the value of the current limiting resistors to 330Ω.

(5V - 1.7V)/330Ω = 10mA per segment

10mA x 7 segments = 70mA current sunk by PORTA

Hence, providing a larger safety margin.


P.S. The addition of an active D.P., an eighth segment, could cause PORTA to exceed its absolute maximum current sunk rating even if the V_F = 2V.

(5V - 2V)/220Ω ~ 14mA per segment

14mA x 8 segments = 112mA current sunk by PORTA




Issue 2:

Reference: PIC16F87/88 Datasheet, Section: 12.1 A/D Acquisition Requirements, Page 117

For the A/D converter to meet its specified accuracy, the
charge holding capacitor (CHOLD) must be allowed to
fully charge to the input channel voltage level. The analog
input model is shown in Figure 12-2. The source
impedance (RS) and the internal sampling switch (RSS)
impedance directly affect the time required to charge the
capacitor CHOLD. The sampling switch (RSS) impedance
varies over the device voltage (VDD), see Figure 12-2.
The maximum recommended impedance for analog
sources is 10 kΩ. As the impedance is decreased, the
acquisition time may be decreased. After the analog
input channel is selected (changed), this acquisition
must be done before the conversion can be started.

The voltage divider, R7 (10kΩ) and R8 (47kΩ), implemented in the current design exceeds the recommended source impedance (Rs) of the PIC16F88 ADC module.

Reference: PIC16F87/88 Datasheet, Section: TABLE 18-13: A/D CONVERTER CHARACTERISTICS, Page 190

Recommended Impedance of Analog Voltage Source 2.5kΩ
Note 4: Maximum allowed impedance for analog voltage source is 10 kΩ. This requires higher acquisition time.

The recommended source impedance is actually only 2.5kΩ.

The relatively high impedance of the implemented voltage divider maybe offset by the implementation of a unity gain buffer (voltage follower opamp) depending the level of accuracy required.




Issue 3:

There does not appear to be the proper implementation of bypass/decoupling capacitors across the V_DD and V_SS pins.

A bypass/decoupling capacitor of typically value 100nF should be connected across the V_DD and V_SS pins to ensure stable operation.




BigDog

 

[weetabixharry]

Thank you for these excellent points.

(5V - 1.7V)/220Ω = 15mA per segment

15mA x 7 segments = 105mA current sunk by PORTA

My measurements were perhaps a little less than this, but, as you very rightly say:

In any event it is generally not prudent to push a device close to its absolute maximum ratings.

... and I really have absolutely no reason to be pushing it so hard (I just need to invest in a better range of resistor values)! Given that I did see an "8.x" shortly before death (8 segments including decimal point), this is looking a bit ominous.

The voltage divider, R7 (10kΩ) and R8 (47kΩ), implemented in the current design exceeds the recommended source impedance (Rs) of the PIC16F88 ADC module.

Thank you -- I hadn't been able to find this information and didn't realise the requirement would be quite so low. I'll fix this.

A bypass/decoupling capacitor of typically value 100nF should be connected across the V_DD and V_SS pins to ensure stable operation.

I had just been shutting my eyes and crossing my fingers regarding the lack of decoupling caps. However, now that you mention it, I could squeeze a little 100nF SMT cap in there... so that ought to help matters.

Again, thank you for your excellent and detailed advice.

 

[bigdogguru]

Please note, I just added a postscript to Issue 1:

P.S. The addition of an active D.P., an eighth segment, could cause PORTA to exceed its absolute maximum current sunk rating even if the VF = 2V.

(5V - 2V)/220Ω ~ 14mA per segment

14mA x 8 segments = 112mA current sunk by PORTA

Proper use of bypass/decoupling capacitors is mandatory for any practical design, EMI is almost always present in the field.

Concerning the bypass/decoupling capacitor, they can be often connected under an IC socket. :wink:


Good Luck with your design,

BigDog

 

[weetabixharry]

Concerning the bypass/decoupling capacitor, they can be often connected under an IC socket. :wink:

Ah... now why didn't I think of that?! Great idea, cheers!

 

[pjmelect]

PIC's are quite tough little chips that are hard to kill, the most common way of killing a PIC is to apply a higher than 5V supply to one of the pins, which will destroy the port pin, but normally the rest of the PIC works fine.

 

[weetabixharry]

I have now killed 4 more chips and this is getting expensive! It seems that it is the PIC programmer itself that is killing the chips. Sometimes I just program the chip and at the end it reports an error along the lines that the config could not be confirmed. Then I try to communicate with the device and nothing is detected.

Having fixed the issues in my circuit discussed earlier in this thread, the programmed chip then actually works as expected, but I just can't communicate with it or reprogram it.

The programmer I'm using is a PICkit 2 clone made by C-U-S.

Does anyone have any ideas what is going on?

 

[bigdogguru]

Perhaps it's time to purchase a genuine Microchip programmer? :grin:

There is a possibility the Code Protection or Write Protection bits have been set.

If you know of someone with a Microchip programmer, PICkit or ICD, you might try entirely wiping the device and then attempt to reprogram it.

BigDog

 

[weetabixharry]

There is a possibility the Code Protection or Write Protection bits have been set.

I have always been confused by this. In my code, I ensure these are disabled. However, I now notice that the PICkit 2 software has its own settings. How can these be different from the values in my code? Which values are actually used?

 

[bigdogguru]

I always set the ALL device configuration registers in code and I've never had an issue.

I do not use the PICkit series of programmers/debuggers, typically use the ICD series, occasionally the PM3 or Real ICE, programmer/debuggers.

Therefore, I'm not very familiar with the PICkit programming application, so my recommendation would be to disable all code and write protection settings within your code and PICkit programming application.

If code or write protection is set, you should be able to erase the entire device and then reprogram it.


BigDog

 

[weetabixharry]

my recommendation would be to disable all code and write protection settings within your code and PICkit programming application.

If code or write protection is set, you should be able to erase the entire device and then reprogram it.

Aha - that has brought a couple of them back to life. At last some progress! Thanks again!

 

[bigdogguru]

I realize I'm repeating myself.

Once again, I would strongly recommend setting ALL configuration register settings in your code, do not rely on any default configuration settings.

By setting ALL the configuration register settings within your code, your device is always in a known state, no second guessing required.


BigDog