ESD damage to MCLR pin of PIC18F26K20?

[Flyback]

Hello,
We have some offline, linear regulator based LED drivers which are dimmable with their PIC18F26K20. (we are using ICSP with Pickit3 to program it)
Some of the PCBs work, most don’t, and some work the first time they are powered up but never thereafter. By “non-working”, I mean they light up but don’t respond to DALI dimming commands sent to the PIC18F26K20.
We have had 1000 of the PCBs made and assembled, and then realised that we forgot to add a 10k pullup resistor from the MCLR pin to Vdd. (MCLR reset is disabled, so its an input pin).
We then had an external modification applied to the PCBs which involves wiring a 10k resistor from MCLR pin to Vdd, and a 10n capacitor from MCLR pin to Vss. I undid this modification on one of the few working boards and then found that stopped it working. –But when I re-did this modification the PCB still did not work.
I am assuming that we have violated the dreaded MCLR pin here… The MCLR pin has no ESD protection diodes due to its use in ICSP, and so am I right in saying that the MCLR pin is supersensitive to ESD, and dies very easily?
(To make matters worse our supply capacitor next to the micro is just a 4n7, 0402 capacitor. However, there are two 10u, 0805 ceramic capacitors about 8mm away from the PIC.)
Do you think we are wasting our time trying to modify these boards? Is the MCLR pin so ultra-sensitive to ESD that everywhere from the PCB assembly house to our factory it is going to get its MCLR pin killed because we forgot to add the 10k resistor from MCLR to Vdd?

PIC18F26K20 datasheet...
**broken link removed**

 

[cowboybob]

From page 53 of the Data Sheet:

Did you include R1 on the PCB? Without it, sure looks like bad things can happen...

 

[Pommie]

If MCLR is disabled in config then no resistor or capacitor are needed. Sounds more like a software bug - an uninitialised variable - a badly timed interrupt - even some SFRs are in a random state at powerup. Double check your code.

Mike.

 

[be80be]

Like Mike said there more then likely something wrong in the code. If you set mclr as input it shouldn't be a problem. I've used this chip it's a pain in the butt to set but after I got it right it worked fine.

FOSC(FOSC) = [LP, XT, HS, RC, EC, ECIO6, HSPLL, RCIO6, INTIO67, INTIO7],
   FCMEN(FCMEN) = [OFF, ON],
   IESO(IESO) = [OFF, ON],
   PWRT(PWRT) = [ON, OFF],
   BOREN(BOREN) = [OFF, ON, NOSLP, SBORDIS],
   BORV(BORV) = [30, 27, 22, 18],
   WDTEN(WDTEN) = [OFF, ON],
   WDTPS(WDTPS) = [1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384, 32768],
   CCP2MX(CCP2MX) = [PORTBE, PORTC],
   PBADEN(PBADEN) = [OFF, ON],
   LPT1OSC(LPT1OSC) = [OFF, ON],
   HFOFST(HFOFST) = [OFF, ON],
   MCLRE(MCLRE) = [OFF, ON], /first place to look
   STVREN(STVREN) = [OFF, ON],
   LVP(LVP) = [OFF, ON],
   XINST(XINST) = [OFF, ON],
   DEBUG(DEBUG) = [ON, OFF],
   CP0(CP0) = [ON, OFF],
   CP1(CP1) = [ON, OFF],
   CP2(CP2) = [ON, OFF],
   CP3(CP3) = [ON, OFF],
   CPB(CPB) = [ON, OFF],
   CPD(CPD) = [ON, OFF],
   WRT0(WRT0) = [ON, OFF],
   WRT1(WRT1) = [ON, OFF],
   WRT2(WRT2) = [ON, OFF],
   WRT3(WRT3) = [ON, OFF],
   WRTC(WRTC) = [ON, OFF],
   WRTB(WRTB) = [ON, OFF],
   WRTD(WRTD) = [ON, OFF],
   EBTR0(EBTR0) = [ON, OFF],
   EBTR1(EBTR1) = [ON, OFF],
   EBTR2(EBTR2) = [ON, OFF],
   EBTR3(EBTR3) = [ON, OFF],
   EBTRB(EBTRB) = [ON, OFF]

 

[Flyback]

Thanks, it seems a coincidence that i undid the RC mod on the MCLR pin of the working unit, then re-did it, and it then stopped working. -Kind of made me think that my fiddling with the MCLR pin killed it.
BTW we dont have resistor R1 in Cowboybobs kindly given post. We'd have to add it in manually because as discussed we have nothing connected to the MCLR piin on the PCB.....other than a blind track going off to a via used in ISCP which we do with "spring pins" into the five programming vias.

 

[Pommie]

If your using it for ICSP then you shouldn't have a capacitor. Use a resistor in series with a diode to stop Vpp (12V) from getting to Vdd(5V). Or once debugged turn it off and leave it floating. As I said earlier, triple check your code.

Mike.

 

[be80be]

I had these on a pcb that jon made call the tap I thought it was the chip is bad it was configure setting. It worked one time and then wouldn't power on. When powered.
If you hook it to your programmer and it tells you there a 18f26k20 hooked to it mclr is still good.

 

[JonSea]

You may want to review Commandments For Using PICs. This is a collection of problems seen in various forums that may cause weird or intermittent operation. If /MCLR actually is disabled in the code, it may be a red herring and some of tbese common problems the fault.

I'll put my bet on insufficient bypass caps (since we've seen that you've worked hard to save a penny no matter what the cost) or that you've failed to tie all of the micro's ground connetions together.

The linked paper is by yours truly.

 

[MrDEB]

1000 pcboards made and failed to add a crucial connection??
This is a lesson to be learned, build a breadboard and get it working properly THEN order ONLY the minimum of 10 boards.
Get them working to verify Everything IS CORRECT, THEN order the quantity needed.
Sorry to hear that you may have to scrap 1000 boards.
I as well as most every member here has never had boards made without some issue. I have 10 boards that are now used as drink coasters.

 

[be80be]

From reading the post. Is probably not that bad check the post part of the board that shows the program pads and mlcr. I had one it's took me a week ot figure out it would run one time if you had the pickit3 hooked up and dead as door nail under it's own power it was the config that was wrong
I think it ran with the pickit3 cause it was pulling the mlcr pin up to vdd

 

[JonSea]

It is ironic that MrDEB was one of the inspirations in writing Commandments For Using PICs.

One thing MrDEB has never grasped - before you start changing things (or in this case, throw out a batch of boards), understand the cause of the fault. It's extremely premature to condemn a batch of boards to the scrap heap. The /MCLR connection (or lack thereof) will not cause the problems seen unless there is a software error. A hardware fix should not be required as described for the /MCLR pin.

Likely are other hardware issues i described in the document above that have resulted in intermitent behavior.

 

[MrDEB]

if you read the first post, Flyback mentioned that the pcboards wee made without the 10K resistor.

We have had 1000 of the PCBs made and assembled, and then realised that we forgot to add a 10k pullup resistor from the MCLR pin to Vdd. (MCLR reset is disabled, so its an input pin).

Jonseas Commandments For Using PICs is great reading.
As for condemning the batch of boards Flyback stated that the 10k resistor is lacking but maybe I missed something but never heard of using a 10n cap between MCLR and VCC.
If he had built one board using a minimum of 10 boards and discovered the issue weather it is code or ?? he could save lots of $$ before having 1000 boards made.
It could still be the code. My suggestion, using Commandments For Using PICs, get an led to blink and take it one step at a time. This has helped me when testing out different code sections.

 

[JonSea]

MrDEB,

/MCLR is disabled. Therefore, a pullup resistor is not required. You have done this in your past "designs" despite it creating complications.

When /MCLR is enabled (probably the more normal case), a 10k pullup resistor is required to keep the chip out of reset.

 

[JonSea]

MrDEB,

Flytrap is also in a totally different situation than you. These boards are not hobby boards for some party trick. These are part of a commercial product. Furthermore, he didn't design the boards or create the code. He is trying to troubleshoot someone else's work in order to move the product along.

In a production environment, you don't get the take a guess at what the proper board might be, change the board randomly as you try to form a proper IF/THAN statement and try to stumble on a solution that sort of does what you want for Lord knows why and pat yourself on the back for being so smart.

 

[be80be]

If your using mplab X Post the this file if you can. If your guy did it like this the file is mcc.c
That's made by mcc it show's the configure setting. And the pin_manager.c
They just show how the configure bit's are set and the chip pins are set.