Chen Xiao Fan wrote:
>ICD2 has this kind of problem with chips like 12F629/675 and ICD2 is
>not behaving correctly when Internal MCLR and Internal Oscillator
>configuration settings are selected. The work-around is not a 
>work-around after all since for a 8-pin device normally one will
>use internal MCLR and internal oscillator to have 6 I/O pins (5 I/O
>plus 1 input only to be precise).

OK.  That's important to me because I was planning on using RA3/MCLR as
a digital input (internal MCLR) and I also need the internal oscillator.

>>From MPLAB ICD2 help file:
>
>When Internal MCLR is used with MPLAB ICD 2 for programming, both Vpp
>and Vdd are powered together, and then Vpp is pulled high to Vihh to 
>enter programming mode. This means that your code will be running 
>before Vpp goes to Vihh.

Is this just a shortcoming of the ICD2 firmware?  I can see that there's
no point in the programmer holding the Vpp pin low to keep the PIC reset
if this pin is configured as a digital input (i.e. not /MCLR).  However,
as I understand it, the code wouldn't run at all if Vpp were driven to
Vihh by the ICD2 before Vdd was applied.

Chen Xiao Fan wrote:
>This is precisely I dump ICD2 for 12F629 programming and use PICkit 1.
>This is one of the limitation of ICD2.

Does the PICkit 1 implement "Vpp before Vdd" correctly, then?  If so,
then I'll take the same route, at least for prototype work.

>>From MPLAB ICD2 help file:
>
>If that code makes use of port pins that correspond to Clock and Data
>pins in programming mode, there is a chance their values may not be 0,
>as necessary to enter programming mode. Therefore, the device could
>not be reprogrammed.

OK -- so I think the issue is that, if the code sets up the Clock or
Data pins as outputs, then it won't be possible for the programmer to
drive them if the code has been allowed to start running before Vpp is
taken to Vihh.  This shouldn't be an issue for first-time programming,
as the PIC will only execute "andlw 0xff" instructions and won't touch
the TRIS registers.  However, it affects re-programming and also means
that the original problem that I raised with the connected 3.3V part
still applies if the ICSP programmer allows this to happen.

I think I'm going to take a brute-force approach and route the output
lines from the PIC to the 3.3V chip via a row of test points, which my
programming jig will connect to a set of 3.3V zener diodes to ground.
If the PIC starts executing its code for any reason while it is being
programmed and sets these pins to outputs, the zeners will clamp the
lines within the safe voltage range.  I'll do out some tests to see if
the output current from each PIC pin under these conditions exceeds 20mA
-- if not then I think this should be safe for the PIC as well.

I'll also see if there's a straightforward way for the code to detect
the presence of the programming jig and put itself in a shutdown state.

Most of all, I'll try to get hold of an ICSP programmer which carries
out the "Vpp before Vdd" procedure correctly.

Many thanks to all for your help.
-- 
Ian Chapman
Chapmip Technology, UK
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist