Killing microcontrollers: most common causes

Status
Not open for further replies.
W

weetabixharry

Full Member level 4
Joined
Oct 9, 2013
Messages
232
Helped
69
Reputation
142
Reaction score
73
Trophy points
1,318
Location
Sweden
Activity points
3,463
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)?
 

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
 
bigdogguru said:
Please post a detailed schematic of your design.
Click to expand...
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.
 
Last edited:

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.
 

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

FvM said:
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.
Click to expand...
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.

ADGAN said:
You haven't given 5V to the MCLR pin (5th pin) can't that be a problem?
Click to expand...

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 :???:
 
Last edited:

A few possible issues:

Issue 1:

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

Assuming a typical VF 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 VF 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 VF = 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

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.
Click to expand...

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 VDD and VSS pins.

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




BigDog
 
Thank you for these excellent points.

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

15mA x 7 segments = 105mA current sunk by PORTA
Click to expand...
My measurements were perhaps a little less than this, but, as you very rightly say:

bigdogguru said:
In any event it is generally not prudent to push a device close to its absolute maximum ratings.
Click to expand...
... 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.

bigdogguru said:
The voltage divider, R7 (10kΩ) and R8 (47kΩ), implemented in the current design exceeds the recommended source impedance (Rs) of the PIC16F88 ADC module.
Click to expand...
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.

bigdogguru said:
A bypass/decoupling capacitor of typically value 100nF should be connected across the VDD and VSS pins to ensure stable operation.
Click to expand...
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.
 

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
Click to expand...


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

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?
 

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
 

bigdogguru said:
There is a possibility the Code Protection or Write Protection bits have been set.
Click to expand...
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?
 

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
 

bigdogguru said:
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.
Click to expand...

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

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
 

Status
Not open for further replies.

Similar threads

Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…