Searching \ for '[PIC]: ICSP of PIC16F688 in 3.3V circuit' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devprogs.htm?key=icsp
Search entire site for: 'ICSP of PIC16F688 in 3.3V circuit'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: ICSP of PIC16F688 in 3.3V circuit'
2005\07\14@145446 by Ian Chapman

flavicon
picon face
I'm planning to use a PIC16F688 in conjunction with a device which can
only operate from a 3.3V +/- 10% supply.  The obvious approach is to run
the PIC from the same supply and connect logic lines directly between
the two parts.  However, there appears to be a problem with In-Circuit
Serial Programming (ICSP) of the PIC16F688 in this configuration.

Table 14.7 (page 143) of the PIC16F688 Rev B data sheet states that "Vdd
for Erase/Write" for the program memory must be 4.5V to 5.5V.  This is
different from many other PICs which seem to be happy with anything from
Vmin to 5.5V (i.e. including 3.3V) for programming.  As I see it, this
make it essential to isolate the PIC Vdd supply so it can be raised to
5V during programming without damaging the other device.  I'm thinking
of using a two-way link to connect the PIC Vdd pin either to the 3.3V
supply (normal) or the Vdd pin from the ICSP interface (programming).

I can see a possible consequential problem.  If the PIC is allowed to
start operating in normal (non-programming) mode while the 5V supply is
attached, then the outputs from the PIC may drive inputs of the other
device to +5V, which will exceed the maximum input voltage ratings of
the other device.  Obviously, I don't want this to happen.

As I understand it, ICSP programmers can operate in one of two modes:
"Vpp first" which appears to guarantee that the PIC never enters normal
operation while the Vdd supply from the programmer is energised; and
"Vdd first" mode which doesn't.  However, I don't know whether real-life
programmers support "Vpp first" strictly enough to ensure that the above
problem scenario never occurs.

Unfortunately, my circuit board needs to be very small (one reason why I
want to use the space-saving 14-pin package of the PIC16F688) and so I
don't have a lot of room to add protective components on the logic lines
such as series resistors and zener diodes.  In any case, I'm not keen to
add this extra cost just to cover an occasional re-programming scenario.

I'd appreciate any thoughts on how best to tackle this.

Many thanks in advance.
--
Ian Chapman
Chapmip Technology, UK

2005\07\14@151516 by Mike Hord

picon face
> I can see a possible consequential problem.  If the PIC is allowed to
> start operating in normal (non-programming) mode while the 5V supply is
> attached, then the outputs from the PIC may drive inputs of the other
> device to +5V, which will exceed the maximum input voltage ratings of
> the other device.

Will it, really?  Many devices which can't operate above, say, 3.5V,
will tolerate 5V+ on their I/O pins.  Check your device's Absolute
Maximum ratings.

I've always understood PICs to powerup with their I/O lines set to
input; i.e., high impedance.  If you write your code to respect this,
to not make the lines outputs and drive them high until after you
KNOW the device isn't being reprogrammed, then no worries.

Furthermore, you should check the spec again.  Usually, the only
time a voltage above Vmin is required is for a block erase, which
may not be a problem, because not all programmers perform a
block erase of the program memory before programming.

Mike H.

2005\07\14@153346 by olin piclist

face picon face
Mike Hord wrote:
> I've always understood PICs to powerup with their I/O lines set to
> input; i.e., high impedance.  If you write your code to respect this,
> to not make the lines outputs and drive them high until after you
> KNOW the device isn't being reprogrammed, then no worries.

The code has nothing to do with this, since it won't be running during
external high voltage programming.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\07\14@154358 by Ian Chapman

flavicon
picon face
Mike Hord <spam_OUTmike.hordTakeThisOuTspamgmail.com> wrote:
>Will it, really?  Many devices which can't operate above, say, 3.5V,
>will tolerate 5V+ on their I/O pins.  Check your device's Absolute
>Maximum ratings.

Unfortunately, the inputs of the device in question aren't 5V tolerant.
They are rated from -0.3V to Vdd+0.3V (in other words, they have input
protection diodes up to Vdd) and the absolute maximum Vdd-Gnd is +3.9V.

>I've always understood PICs to powerup with their I/O lines set to
>input; i.e., high impedance.  If you write your code to respect this,
>to not make the lines outputs and drive them high until after you
>KNOW the device isn't being reprogrammed, then no worries.

It occurred to me that I could use a spare input (which I don't have at
the moment :-) to allow my code to sense that a programmer is connected
and therefore keep the output lines at a high-impedance state.  I don't
think there's an automatic way of doing this, though -- as far as the
PIC is concerned, if the code is running then it isn't in programming
mode (although Vdd may be raised to +5V, which is the issue here).

>Furthermore, you should check the spec again.  Usually, the only
>time a voltage above Vmin is required is for a block erase, which
>may not be a problem, because not all programmers perform a
>block erase of the program memory before programming.

I've checked the data sheet and errata of the PIC16F688 against those of
the PIC16F684, PIC16F818 and PIC16F628A/648A, and it's a mixed picture.
Apparently, the '688 and '684 both require 4.5V to 5.5V for erase *and*
write, whereas the '818 can read, erase and write anywhere between Vmin
and 5.5V.  The '628A/'648A require 4.5V to 5.5V for block erase, and
some early silicon revisions also place the same constraint on writes.

I imagine that the design intention was to have a wide Vdd range for
programming, but that testing of the silicon revealed that this wasn't
realised, at least in the early silicon.
--
Ian Chapman
Chapmip Technology, UK

2005\07\14@154552 by Mike Hord

picon face
> > I've always understood PICs to powerup with their I/O lines set to
> > input; i.e., high impedance.  If you write your code to respect this,
> > to not make the lines outputs and drive them high until after you
> > KNOW the device isn't being reprogrammed, then no worries.
>
> The code has nothing to do with this, since it won't be running during
> external high voltage programming.

In the case of Vdd-before-Vpp programming, it is possible that some
code could begin executing before application of Vpp puts the chip
into programming mode.

In that case, it becomes the programmer's responsibility to ensure
that if the PIC is powered up to 5V by a programmer, it doesn't do
anything to cause its I/O lines to exceed the acceptable voltage
for devices attached to them.  That could be as simple as using
the powerup timer to delay code execution until the programmer
can assert Vpp, or as complex as the PIC checking its own
voltage and not proceeding with code execution if Vdd > 3.3V
(or whatever).

Mike H.

2005\07\14@161655 by olin piclist

face picon face
Ian Chapman wrote:
> It occurred to me that I could use a spare input (which I don't have at
> the moment :-) to allow my code to sense that a programmer is connected
> and therefore keep the output lines at a high-impedance state.  I don't
> think there's an automatic way of doing this, though -- as far as the
> PIC is concerned, if the code is running then it isn't in programming
> mode (although Vdd may be raised to +5V, which is the issue here).

No, programming doesn't work that way.  The programmer should never allow
the code to execute.  This means Vpp will always be 0V or 13V (or whatever
the programming voltage) whenever Vdd is on.  For this very reason, PICs
that require Vdd before Vpp have a maximum rise time spec on Vpp.  This
guarantees that Vpp is not in the normal operating transition region long
enough for any code to execute.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\07\14@161808 by olin piclist

face picon face
Mike Hord wrote:
> In the case of Vdd-before-Vpp programming, it is possible that some
> code could begin executing before application of Vpp puts the chip
> into programming mode.

No, not if done right.  The maximum rise time spec on Vpp guarantees that no
code will execute.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\07\14@171910 by Ian Chapman

flavicon
picon face
Olin Lathrop <.....olin_piclistKILLspamspam@spam@embedinc.com> wrote:
>The programmer should never allow the code to execute.  This means Vpp
>will always be 0V or 13V (or whatever the programming voltage) whenever
>Vdd is on.  For this very reason, PICs that require Vdd before Vpp have
>a maximum rise time spec on Vpp.  This guarantees that Vpp is not in the
>normal operating transition region long enough for any code to execute.

Ah.. thanks!  You may have answered my question there.  I think you're
saying that, if a programmer is connected properly to the ICSP pins and
is behaving correctly, then there should be no circumstances in which the
PIC gets the opportunity to execute any code which changes the I/O pins
from their high-impedance states at reset.  If that's true, then I don't
need to take any special precautions to protect the other chip which can
only run off 3.3V (apart from isolating it from the +5V Vdd to the PIC).

I'm wondering how an ICD2 (for example) behaves when it is connected to
the target system but allows code to run by releasing /MCLR so that it
can be pulled high by a resistor to Vdd.  I'll have to try some tests.
If the programmer always disconnects its own Vdd supply to the target as
/MCLR is released, then I think this is safe behaviour in my situation.
If my two-way link is set for "programming" (Vdd from programmer) then
the PIC will be unpowered, and if it's in the "normal" position (Vdd is
3.3v) then the PIC will run off the 3.3V supply. Either way, the 3.3V-
only chip shouldn't see +5V on any of its inputs.

I've just read section 3.0 of the PIC12F6XX/PIC16F6XX Memory Programming
Specification and it seems to be consistent with this interpretation.  Is
my reasoning sound?

Thanks.
--
Ian Chapman
Chapmip Technology, UK

2005\07\14@174145 by Jan-Erik Soderholm

face picon face
Ian Chapman wrote :

> Ah.. thanks!  You may have answered my question
there.  I think you're
> saying that, if a programmer is connected
properly to the
> ICSP pins and
> is behaving correctly, then there
should be no circumstances
> in which the
> PIC gets the opportunity
to execute any code which changes
> the I/O pins
> from their high-
impedance states at reset.


Note that some ICSP programmers (Wisp628
comes to mind)
*by default* releases the PIC *after* programming.
All
I/O goes high-Z and MCLR is raised.

This is made so you can easily
edit/build/flash/test
in a very short cycle without disconnecting
anything.

That is the default if you just give the host software
a "GO
myfile.hex" command. There might be some
switch to prevent the
automatic "run" of the target,
I have not checked right now...

Regards,
Jan-Erik



2005\07\14@175821 by Wouter van Ooijen

face picon face
> Note that some ICSP programmers (Wisp628
> comes to mind)
> *by default* releases the PIC *after* programming.
> All
> I/O goes high-Z and MCLR is raised.
>
> This is made so you can easily
> edit/build/flash/test
> in a very short cycle without disconnecting
> anything.
>
> That is the default if you just give the host software
> a "GO
> myfile.hex" command. There might be some
> switch to prevent the
> automatic "run" of the target,
> I have not checked right now...

With Wisp628 you can specify separate WRITE, VERIFY etc commands instead
of the GO. But a Wisp628 is not designed to operate a 3.3V target, IHMO
it would not be a good choice for what the OP wants. Maybe the OP should
not use an ICSP progger at all: use a bootloader? But I don't know
whether any 14-pin PIC supports self-programming.

Side note: for proggers there is the prototype/production distinction,
which boils down to verification. What about self-programming. Should it
be classified in the protytype league as far as reliability is
concerned?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\07\14@180703 by Jan-Erik Soderholm

face picon face
Wouter van Ooijen wrote :

> But a Wisp628 is not designed to operate a
3.3V
> target, IHMO
> it would not be a good choice for what the OP
wants.

Sorry, I should have just said "some programmers"...

I never
thought the OP either was or
or should be using the Wisp628...

:-)

It
was just ment as something to look out for.

Maybe not an issue at
all...

Jan-Erik



2005\07\14@184044 by olin piclist

face picon face
Ian Chapman wrote:
> I think you're
> saying that, if a programmer is connected properly to the ICSP pins
> and is behaving correctly, then there should be no circumstances in
> which the PIC gets the opportunity to execute any code which changes
> the I/O pins from their high-impedance states at reset.

Yes.

*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\07\15@015701 by Chen Xiao Fan

face
flavicon
face

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). There is a trick to get around but
it is not so elegant (to add external circuit to delay Vdd)
and may not always work. This is precisely I dump ICD2 for
12F629 programming and use PICkit 1. This is one of the limitation
of ICD2.

For 16F688 probably one can forgo one input only pin and not
use the internal MCLR option.

>From MPLAB ICD2 help file:
"
ICDWarn0033: You have selected Internal MCLR and Internal Oscillator in
your configuration settings. If your code makes use of port pins that
correspond to Clock and Data pins in programming mode, you may not be
able to reprogram your device. See on-line help for this warning for
more information. (OK/Cancel)

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

Click OK to continue programming or click Cancel to cancel the
programming operation.

Work-Around

When External MCLR is used, this is not a problem, as Vpp can go directly
to Vihh. Also, if External Oscillator is used, the external oscillator
can be kept from running, thus keeping the code from running, until Vpp
is at Vihh."

{Original Message removed}

2005\07\15@015844 by Chen Xiao Fan

face
flavicon
face
None of the 8/14/20 pin and the new PIC16F91x support
self-programming since they are all standard flash,
not enhanced flash.

-----Original Message-----
From: Wouter van Ooijen [wouterspamKILLspamvoti.nl]
Sent: Friday, July 15, 2005 5:56 AM
...
But I don't know whether any 14-pin PIC supports
self-programming.
...
Wouter van Ooijen

2005\07\15@054050 by Ian Chapman

flavicon
picon face
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

2005\07\15@080806 by Howard Winter

face
flavicon
picon face
Wouter,

On Thu, 14 Jul 2005 23:56:18 +0200, Wouter van Ooijen wrote:

> Side note: for proggers there is the prototype/production distinction,
> which boils down to verification. What about self-programming. Should it
> be classified in the protytype league as far as reliability is
> concerned?

Since Microchip's definition of a production programmer is one that verifies at the specified voltage limits,
and since it's very unlikely that a target circuit would include voltage change under program control, it must
me that self-programming is "prototype" by MChip's definition!

However, since one of the uses of self-programming is to change code in place in the target, it will be used
in a "maintenance" situation in installed equipment, if not actually in "production".

So, choose your definition and go from there  :-)

Cheers,



Howard Winter
St.Albans, England


2005\07\19@203826 by Chen Xiao Fan

face
flavicon
face
I think it is a limitation (or bug?) of ICD2 firmware. I
searched through Microchip Forum when I encountered this
ICD2 problem and the explanation of Microchip is not really
satisfactory.

PICKit 1 is correct. If you read the PICkit 1 firmware source
code, you will note that there are two subroutines named
EnterProgramMode and EnterProgramModeVdd1st. I think only ICD2
has some problems in this respect. Wisp628 is working as well.
I think higher end programmer will of course do it right.

Regards,
Xiaofan

{Original Message removed}

2005\07\25@152538 by Wouter van Ooijen

face picon face
> However, since one of the uses of self-programming is to
> change code in place in the target, it will be used
> in a "maintenance" situation in installed equipment, if not
> actually in "production".
>
> So, choose your definition and go from there  :-)

"prototype-programmer" used to mean "don't use this for production". But
there is no such reservation about using self-programming (or did I miss
it?). So my conclusion is that the prototype/production disctinction is
a historic relict. Now just wait for uChip to confirm this :)

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...