Yeah, but the whole idea of having a special ICD version of the chip=20 is that the programming pins (clk, data, Vpp) are all brought out to=20 separate pins rather than being shared with RA0, RA1, MCLR. This=20 allows you to debug your circuit and code without losing those shared pins. And that's what's on the ICD header: its a PIC16f690-ICD. I know that the ICD header for the 12f675 & 16f676 had hardware=20 issues with MCLR and RA1. But those issues were adequately described=20 right within MPLAB whenever those parts were selected. There are no such warnings or limitations mentioned when selecting=20 the 16f677, so I *assumed* that those hardware goofs had been fixed=20 in these particular ICD headers. dwayne At 02:37 PM 11/25/2013, jim@jpes.com wrote: > If you're using normal high voltage rogramming mode, MCLR is the >programming voltage pin. > If it is held low, your programming voltage is shorted to ground, and >the part will not program. > >Regards, > >Jim > > > -------- Original Message -------- > > Subject: Re: [PIC] Problem programming ICD header > > From: Dwayne Reid > > Date: Mon, November 25, 2013 2:49 pm > > To: "Microcontroller discussion list - Public." > > > > > > I should have mentioned that I have tried doing a bulk-erase on the > > header (Debug -> Erase) and both the ICD-2 and the Real-ICE say=20 > "successful". > > > > I did discover something, though. I'm currently using the MCLR pin > > as a digital input. This pin is normally LOW and goes high only when > > a specific input signals one of the fault conditions. > > > > Allowing MCLR to go high allows the header to be programmed. I'm not > > sure why that is - I know that earlier ICD headers had problems with > > MCLR and pin RA1 but I didn't see any warnings or limitations to that > > effect when selecting both the chip and the debugger. > > > > However, I still can't get into debug mode. The build configuration > > is set for debug and, although I have configuration bits CP, WDT & > > PWRTE enabled in my code, MPLAB is nice to me and mentions that those > > bit settings are not compatible with the ICD header - and graciously > > sets those bits correctly when I go to program the header. I did > > check the configuration bits after MPLAB changed them and they do > > appear to be set correctly. > > > > I'll keep plugging along. But please keep those tips and suggestions > > coming - it really does help. > > > > Many thanks! > > > > dwayne > > > > > > At 12:27 PM 11/25/2013, Matt Bennett wrote: > > >On Mon, November 25, 2013 11:55 am, Dwayne Reid wrote: > > > > The error is that the first location is not programmed correctly > > > > (desired value (something), read-back value is 00). > > > > > >When it reads back all zeros- that's usually a sign it isn't getting i= nto > > >programming/debug mode. #1 tip (see more below)- check the that VPP is > > >getting through. Try a bulk erase on the part which would clear any > > >inadvertent copy protect and restore the part to as fresh as possible.= The > > >bulk erase is a separate action in the ICSP world- as close to a compl= ete > > >wipe as you can get on a PIC. > > > > > > -- > > Dwayne Reid > > Trinity Electronics Systems Ltd Edmonton, AB, CANADA > > (780) 489-3199 voice (780) 487-6397 fax > > www.trinity-electronics.com > > Custom Electronics Design and Manufacturing > > > > -- > > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive > > View/change your membership options at > > http://mailman.mit.edu/mailman/listinfo/piclist > >-- >http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive >View/change your membership options at >http://mailman.mit.edu/mailman/listinfo/piclist --=20 Dwayne Reid Trinity Electronics Systems Ltd Edmonton, AB, CANADA (780) 489-3199 voice (780) 487-6397 fax www.trinity-electronics.com Custom Electronics Design and Manufacturing --=20 http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .