Searching \ for '[EE] bulk erase of 18F parts when running at 3.3V?' 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/devices.htm?key=18F
Search entire site for: 'bulk erase of 18F parts when running at 3.3V?'.

Exact match. Not showing close matches.
PICList Thread
'[EE] bulk erase of 18F parts when running at 3.3V?'
2005\12\13@181555 by Jesse Lackey

flavicon
face
Hello all,

Newest can't-believe-microchip-did-that discovery: even when using
high-voltage in-circuit programming, one can't bulk-erase a chip unless
Vdd is 4.5V.  I'm using an ICD2 in mplab.  There is no warning about
this even though the ICD2 correctly reads the 3.3V I'm running
everything at.

So you can program and single-step, but for any kind of development you
can't work at 3.3V.

I just kludged in a way to switch the PIC Vdd to 5V without sending 5V
to all the other 3.3V parts.  Xacto scraping and soldering wire-wrap
jumper wires...

The programming spec data sheet for the part (PIC18F2320) clearly says
4.5V for bulk erase.
How does one do normal development in a 3.3V system?
Am I missing something?

Do atmel parts have this ridiculous problem?

Thanks
Jesse

2005\12\13@184655 by Mike Harrison

flavicon
face
On Tue, 13 Dec 2005 18:15:50 -0500, you wrote:

>Hello all,
>
>Newest can't-believe-microchip-did-that discovery: even when using
>high-voltage in-circuit programming, one can't bulk-erase a chip unless
>Vdd is 4.5V.  I'm using an ICD2 in mplab.  There is no warning about
>this even though the ICD2 correctly reads the 3.3V I'm running
>everything at.
>
>So you can program and single-step, but for any kind of development you
>can't work at 3.3V.
>
>I just kludged in a way to switch the PIC Vdd to 5V without sending 5V
>to all the other 3.3V parts.  Xacto scraping and soldering wire-wrap
>jumper wires...
>
>The programming spec data sheet for the part (PIC18F2320) clearly says
>4.5V for bulk erase.
>How does one do normal development in a 3.3V system?
>Am I missing something?

Not sure about the 18F but on the 16F, the trick is to NOT set the code-protect bits - then ICD can
use non-bulk erase and it works, albeit significantly more slowly, so boosting supply to 5V for
programming is a good idea for that reason alone.

It is totally dumb that ICD2 does not give a sensible warning about this issue - it stumped me for a
while



2005\12\13@184823 by olin piclist

face picon face
Jesse Lackey wrote:
> The programming spec data sheet for the part (PIC18F2320) clearly says
> 4.5V for bulk erase.

Right.  This is well known and hardly a new revelation.

> How does one do normal development in a 3.3V system?

You design this capability in up front.  ICSP can be very nice and useful
and usually not hard to design in, but it can be very difficult to retrofit
a design where it was not considered.

I remember hearing a military consultant say something like "amateurs start
by talking about strategy, but the professionals start with logistics".  I
think there is something similar in electronics: The professionals start
with the power supply.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2005\12\13@191346 by Jose Da Silva

flavicon
face
On December 13, 2005 03:15 pm, Jesse Lackey wrote:
> Hello all,
>
> Newest can't-believe-microchip-did-that discovery: even when using
> high-voltage in-circuit programming, one can't bulk-erase a chip
> unless Vdd is 4.5V.  I'm using an ICD2 in mplab.  There is no warning
> about this even though the ICD2 correctly reads the 3.3V I'm running
> everything at.

Out of curiosity, if the chip is code protected, will the attempt to
bulk erase unprotect the chip?
If yes, then it is definitely a grand goof-up of major concern!
If not, then, it's good to know that code remains protected.

2005\12\13@191407 by Jesse Lackey
flavicon
face
>> The programming spec data sheet for the part (PIC18F2320) clearly says
>> 4.5V for bulk erase.
>
> Right.  This is well known and hardly a new revelation.

To developers of PIC programming hardware, sure.  Everyone else?

I bought an ICD2 to not have to deal with the details of how they are
programmed.

{Quote hidden}

So a means of switching the PIC's Vdd (and only the PIC, not everything
else on the 3.3V bus) to 5V must be part of the design?  So this means
some pcb space must be used for any design that could ever need to be
erased and re-programmed?  At least easily cuttable traces.  Or .1"
header with a jumper to 5V or 3.3V.  This seems completely ridiculous.

I'm just real real suprised that in 2.5 years of PIC work I've never
seen this mentioned in any microchip literature or any ICSP-howto design.

I'm thinking back to other < 5V designs, there have been a couple, and
this has never come up.  But I was using a F452 and a F1320, not the
F2320.  Maybe the other ones can erased @ 3.3V; maybe sometimes it works
@ 3.3V and sometimes it doesn't and I've been lucky until now.

Another 3 hours wasted...
J

2005\12\13@203105 by Chen Xiao Fan

face
flavicon
face

> -----Original Message-----
> From: spam_OUTpiclist-bouncesTakeThisOuTspammit.edu
> Sent: Wednesday, December 14, 2005 7:16 AM
>
> The programming spec data sheet for the part (PIC18F2320)
> clearly says  4.5V for bulk erase.
> How does one do normal development in a 3.3V system?
> Am I missing something?
>
> Do atmel parts have this ridiculous problem?
>
> Thanks
> Jesse

An easy solution, forget ICSP in this case as Olin
mentioned that "it can be very difficult to retrofit
a design where it was not considered".

ICSP is anyway not a good solution for mass production.
We switched to off-line programming since last year.

And Atmel have more ridiculous problems...

Regards,
Xiaofan

2005\12\13@210100 by Lee Jones

flavicon
face
>> Newest can't-believe-microchip-did-that discovery: even when using
>> high-voltage in-circuit programming, one can't bulk-erase a chip
>> unless Vdd is 4.5V.  I'm using an ICD2 in mplab.  There is no warning
>> about this even though the ICD2 correctly reads the 3.3V I'm running
>> everything at.

Since the ICD2 knows the PIC model and the target circuit voltage,
it _really_ should warn you or refuse to do a bulk erase command.

> Out of curiosity, if the chip is code protected, will the attempt
> to bulk erase unprotect the chip?
> If yes, then it is definitely a grand goof-up of major concern!
> If not, then, it's good to know that code remains protected.

Out of experience, no.  Chip stays code protected.  It seems to
reprogram properly (at 3.3 volt) but the verify always fails.

Following paragraphs sum up a bunch of non-billable labor when I
had to figure this out for myself a while back.

I ran into the same situation with an 18LF6621 on a customer board,
entire board runs at 3.3V, using ICD2 for development.  I turned
on code protect and found I couldn't undo the code protect.  Erase
command does not warn you or fail or anything -- just appears to
succeed.  After every reprogram, verify fails.  Normally, given
3.3V circuitry, I use ICD2 in "Target Supplies Power" mode.

Board rev 2, which I was using, was designed to allow PIC Vdd to
go to +5V without damaging the remaining 3.3V only components (a
result of a less than optimum experience with board rev 1 <sigh>).

Using ICD2 running from USB power, I reverted to "ICD2 Supplies
Power" mode.  Still wouldn't bulk erase.  PIC Vdd wasn't going up
at all.  So power from ICD2 in USB mode to target PIC is very
low or nonexistant.  (I didn't have a external power supply handy
to plug into the ICD2's coaxial power jack, so I don't know if
that would have resolved the issue.)

I reconfigured back to "Target Supplies Power" mode, popped 3 AA
batteries in a battery holder, used a pair of clip leads to jump
battery pack to PIC Vdd & ground, and -- viola -- PIC bulk erase
worked fine.  3 fresh AA alkaline batteries gave me about 4.7V as
reported by ICD2 voltage monitor.

                                               Lee Jones

2005\12\13@214035 by Jesse Lackey

flavicon
face
Hello all,

Lee Jones wrote:

>>Out of curiosity, if the chip is code protected, will the attempt
>>to bulk erase unprotect the chip?
>>If yes, then it is definitely a grand goof-up of major concern!
>>If not, then, it's good to know that code remains protected.
>
>
> Out of experience, no.  Chip stays code protected.  It seems to
> reprogram properly (at 3.3 volt) but the verify always fails.
>

I just tried the same thing, and got some strange results.  Blank check
failed, reprogramming verified (!) but didn't work correctly (!).  Still
code protected.

The only way to successfully erase a code-protected chip is to run at 5V.

For my 3.3V development, I turned code protect off, and now it seems to
erase ok - at least the program space.  Sometimes EEPROM/config bits
fail.  But so far I can do normal development work without constantly
switching the PIC Vdd power.

Bottom line:

If code protect is on, the 18F parts are effectively
one-time-programmable in a 3.3V system.

If code protect is off, it seems that it can be erased at 3.3V, with
occasional flakyness.

> Following paragraphs sum up a bunch of non-billable labor when I
> had to figure this out for myself a while back.

This is *EXACTLY* the problem.  Microchip didn't spell out this weird
exception to their whole low-voltage in-circuit everything system, and
experienced engineers, on the clock (or working for zero, if freelance)
have gotten burned and customer money wasted and schedules missed.  Its
not like nobody at Microchip knows about this, they just want to keep it
under the rug.

J

2005\12\13@214646 by Lee Jones

flavicon
face
>>> The programming spec data sheet for the part (PIC18F2320) clearly says
>>> 4.5V for bulk erase.

>> Right.  This is well known and hardly a new revelation.

> To developers of PIC programming hardware, sure.  Everyone else?

It is obvious ... once you know about it.  PIC 18F2220/2320/4220/4320
data sheet, DS39599C, section 6.6 "Flash Program Operation During
Code Protection" has 1 sentence refering you to section 23.0 (with
a note to see 23.5 "Program Verification And Code Protection")."

No where in section 23.5 "Program Verification And Code Protection"
does it mention the 4.5V to 5.5V requirement to erase the chip.

You have to read to section 23.9 "Low Voltage ICSP Programming"!
The last sentence of that section finally mentions the restriction.
Tucked into the regular text, with no highlighting or emphasis, are
two sentences addressing this.  And the important one, stating the
PIC needs 4.5V to 5.5V to do a block erase, is almost misleading
because it qualifies it with "when using low voltage programming".
In fact, bulk erase ALWAYS needs 4.5V to 5.5V, no matter which
programming mode you are using.

18F2320 is actually an improvement over previous 18F data sheets.

If Microchip isn't going to fix the silicon, they should highlight
this tidbit or move it to a more prominent location.


>>> How does one do normal development in a 3.3V system?

>> You design this capability in up front.

> So a means of switching the PIC's Vdd (and only the PIC, not everything
> else on the 3.3V bus) to 5V must be part of the design?  So this means
> some pcb space must be used for any design that could ever need to be
> erased and re-programmed?  At least easily cuttable traces.  Or .1"
> header with a jumper to 5V or 3.3V.  This seems completely ridiculous.

Yes and yes (if you're going to use code protection).  We used 0.1"
header but it was too cumbersome, so we switched to a few diodes.


> I'm just real real suprised that in 2.5 years of PIC work I've never
> seen this mentioned in any microchip literature or any ICSP-howto design.

It has been mentioned here on the PIC list.

> I'm thinking back to other < 5V designs, there have been a couple, and
> this has never come up.  But I was using a F452 and a F1320, not the
> F2320.  Maybe the other ones can erased @ 3.3V; maybe sometimes it works
> @ 3.3V and sometimes it doesn't and I've been lucky until now.

4.5V to 5.5V is only needed to erase a code protected PIC.  So maybe
you just never ran into it before.

                                               Lee Jones

2005\12\14@070916 by olin piclist

face picon face
Jose Da Silva wrote:
> Out of curiosity, if the chip is code protected, will the attempt to
> bulk erase unprotect the chip?

Yes, right after erasing all the protected content.

> If yes, then it is definitely a grand goof-up of major concern!

No, it's quite reasonable unless you want a single-use chip.

******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2005\12\14@071917 by olin piclist

face picon face
Jesse Lackey wrote:
> So a means of switching the PIC's Vdd (and only the PIC, not everything
> else on the 3.3V bus) to 5V must be part of the design?

Your circuit doesn't have to create the 5V, just be tolerant of when the
programmer drives Vdd to 5V.

> So this means
> some pcb space must be used for any design that could ever need to be
> erased and re-programmed?  At least easily cuttable traces.  Or .1"
> header with a jumper to 5V or 3.3V.  This seems completely ridiculous.

Nothing is free, including ICSP, but you're making it sound harder than it
is.  It's part of what your circuit does, and needs to be considered as part
of the design.  This of course includes reading the specifications to
understand what voltages are required.  Often this can be addressed with
just a diode.

> I'm just real real suprised that in 2.5 years of PIC work I've never
> seen this mentioned in any microchip literature or any ICSP-howto
> design.

The required voltage levels are clearly spelled out in the programming
specs, which of course is something that should be consulted when designing
circuits for ICSP.  I also mention this in my ICSP writeup at
http://www.embedinc.com/picprg/icsp.htm.

> I'm thinking back to other < 5V designs, there have been a couple, and
> this has never come up.  But I was using a F452 and a F1320, not the
> F2320.  Maybe the other ones can erased @ 3.3V;

I don't think so.

> maybe sometimes it works
> @ 3.3V and sometimes it doesn't and I've been lucky until now.

That, or the programmer forced Vdd to 5V and you were lucky that the rest of
the circuit tolerated it.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2005\12\14@074017 by Alan B. Pearce

face picon face
>>>> How does one do normal development in a 3.3V system?

>>> You design this capability in up front.

>> So a means of switching the PIC's Vdd (and only the PIC, not everything
>> else on the 3.3V bus) to 5V must be part of the design?  So this means
>> some pcb space must be used for any design that could ever need to be
>> erased and re-programmed?  At least easily cuttable traces.  Or .1"
>> header with a jumper to 5V or 3.3V.  This seems completely ridiculous.

>Yes and yes (if you're going to use code protection).  We used 0.1"
>header but it was too cumbersome, so we switched to a few diodes.

It strikes me that this is where one needs a "0 ohm jumper" during
development, but has the two pads linked by a copper track for production. I
small quantity production the fitting of a 0 ohm resistor would probably
save another board turn.

2005\12\14@081303 by olin piclist

face picon face
Chen Xiao Fan wrote:
> ICSP is anyway not a good solution for mass production.
> We switched to off-line programming since last year.

I disagree with this blanket statement.  ICSP has a number of advantages for
production, although like any feature, it's not free.  A few years ago most
of my PIC designs used DIP packages.  The PICs were programmed separately,
sometimes outside, then installed on the boards during production.  Now
probably over 90% of new designs use surface mount PICs with virgin parts
installed when the boards are built.  The PICs are programmed as part of the
board test procedure.  Often the per-unit cost is as little as adding a few
pads for pogo pins on the bottom of the board (along with other test points
anyway), and the extra time to perform the programming.  This is usually
5-30 seconds for most PICs, although some PICs take longer.

All in all, ICSP as part of the production test process can be very cost
effective if the circuit is designed for that up front.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2005\12\14@081704 by olin piclist

face picon face
Lee Jones wrote:
> Using ICD2 running from USB power, I reverted to "ICD2 Supplies
> Power" mode.  Still wouldn't bulk erase.  PIC Vdd wasn't going up
> at all.  So power from ICD2 in USB mode to target PIC is very
> low or nonexistant.  (I didn't have a external power supply handy
> to plug into the ICD2's coaxial power jack, so I don't know if
> that would have resolved the issue.)

I thought the ICD2 was not specified to supply any target power when it is
powered from USB.  It's been a while since I looked over that part of the
docs, so I may be a little off, but my first reaction would be to assume it
can't without explicitly verifying that it can.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2005\12\14@082947 by olin piclist

face picon face
Jesse Lackey wrote:
> The only way to successfully erase a code-protected chip is to run at
> 5V.

Just like the documentation clearly states.

> If code protect is on, the 18F parts are effectively
> one-time-programmable in a 3.3V system.

Again, you seem to be "discovering" things that are clearly spelled out in
the documentation.

> If code protect is off, it seems that it can be erased at 3.3V, with
> occasional flakyness.

Some PICs allow various partial erase procudures at lower voltages than the
total bulk erase.  The ICD2 apparently implements some of these.

> This is *EXACTLY* the problem.  Microchip didn't spell out this weird
> exception to their whole low-voltage in-circuit everything system, and
> experienced engineers, on the clock (or working for zero, if freelance)
> have gotten burned and customer money wasted and schedules missed.  Its
> not like nobody at Microchip knows about this, they just want to keep it
> under the rug.

No, the real problem is that you didn't RTFM before designing the circuit.
Everything you mentioned is well documented.  It's nobody's fault but your
own if you didn't bother reading it.  Stop whining about it being
Microchip's fault.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2005\12\14@083422 by olin piclist

face picon face
Lee Jones wrote:
> It is obvious ... once you know about it.  PIC 18F2220/2320/4220/4320
> data sheet, DS39599C, section 6.6 "Flash Program Operation During
> Code Protection" has 1 sentence refering you to section 23.0 (with
> a note to see 23.5 "Program Verification And Code Protection")."
>
> No where in section 23.5 "Program Verification And Code Protection"
> does it mention the 4.5V to 5.5V requirement to erase the chip.
>
> You have to read to section 23.9 "Low Voltage ICSP Programming"!
> The last sentence of that section finally mentions the restriction.
> Tucked into the regular text, with no highlighting or emphasis, are
> two sentences addressing this.  And the important one, stating the
> PIC needs 4.5V to 5.5V to do a block erase, is almost misleading
> because it qualifies it with "when using low voltage programming".
> In fact, bulk erase ALWAYS needs 4.5V to 5.5V, no matter which
> programming mode you are using.

I don't remember if I've looked at that specific programming spec, but for
the ones I have seen they show the min/max Vdd levels for bulk erase in the
electrical specifications table near the end, which seems like a reasonable
place for voltage level issues.  Someone designing a circuit for ICSP might
not read most of the algorithm descriptions, but would certainly look thru
the electrical specifications.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2005\12\14@085134 by alan smith

picon face
I came across this last year.....or the year before...drove me NUTS for a while
 
 Found that, but not on all parts.....once you hit it with 5V, then you can program in circuit with 3.3V

                       
---------------------------------
Yahoo! Shopping
Find Great Deals on Holiday Gifts at Yahoo! Shopping

2005\12\14@091203 by Mike Harrison

flavicon
face
On Wed, 14 Dec 2005 08:31:02 -0500, you wrote:

{Quote hidden}

It is Microchip's fault that information on a relatively obscure issue is not as obvious as it
should be.
The original query was about debugging with ICD2. You should not need to read the details of the
programming spec to be able to use a debugger, and it is inexcusable that the ICD2 gives a
misleading 'programming failed' type message when it 'knows' that the supply is inadequate to do a
bulk erase and should be able to guide the user better as to what the problem is, i.e. that the
code-protect setting needs changing.



2005\12\14@092340 by Cristóvão Dalla Costa

picon face
On 12/14/05, Mike Harrison <.....mikeKILLspamspam@spam@whitewing.co.uk> wrote:
>
> It is Microchip's fault that information on a relatively obscure issue is not as obvious as it
> should be.
> The original query was about debugging with ICD2. You should not need to read the details of the
> programming spec to be able to use a debugger, and it is inexcusable that the ICD2 gives a
> misleading 'programming failed' type message when it 'knows' that the supply is inadequate to do a
> bulk erase and should be able to guide the user better as to what the problem is, i.e. that the
> code-protect setting needs changing.
>
>

I think the real question is: "Who debugs code protected chips?"

I can't think of a single reason to code protect chips going into
development boards. Of course, prototypes that might travel outside
the door are another issue, but on boards used for development it's
just a hindrance. And therefore it becomes a non-issue.

2005\12\14@092904 by Mike Hord

picon face
> > Using ICD2 running from USB power, I reverted to "ICD2 Supplies
> > Power" mode.  Still wouldn't bulk erase.  PIC Vdd wasn't going up
> > at all.  So power from ICD2 in USB mode to target PIC is very
> > low or nonexistant.  (I didn't have a external power supply handy
> > to plug into the ICD2's coaxial power jack, so I don't know if
> > that would have resolved the issue.)
>
> I thought the ICD2 was not specified to supply any target power when it is
> powered from USB.  It's been a while since I looked over that part of the
> docs, so I may be a little off, but my first reaction would be to assume it
> can't without explicitly verifying that it can.

You're right, of course, Olin, but I've long thought that it's kind of
ridiculous that the ICD2 can't power the target when it runs in
bus powered mode- after all, it could negotiate for up to 500 mA
from the PC, and that's enough to run a lot of my circuits.

Anything that drew more power than that I'd probably think about
self-powering anyway.  It'd be nice to do it for the tiny-power
designs, though.

Mike H.

2005\12\14@100119 by alan smith

picon face
ive got a board....just a PIC and ISP on it...nothing else.  I run it all the time from the ICD2, bccause its just a test target..
 
 But, any board that has LED's, other "stuff"....always power it from a supply.  
 
 FWIW, microchip FAE's don't recommend powering from the ICD2, probably because if you don't pay attention to the power draw, then it can act flaky and ya...we've all been there.

                       
---------------------------------
Yahoo! Shopping
Find Great Deals on Holiday Gifts at Yahoo! Shopping

2005\12\14@100123 by alan smith

picon face
ive got a board....just a PIC and ISP on it...nothing else.  I run it all the time from the ICD2, bccause its just a test target..
 
 But, any board that has LED's, other "stuff"....always power it from a supply.  
 
 FWIW, microchip FAE's don't recommend powering from the ICD2, probably because if you don't pay attention to the power draw, then it can act flaky and ya...we've all been there.

                       
---------------------------------
Yahoo! Shopping
Find Great Deals on Holiday Gifts at Yahoo! Shopping

2005\12\14@100246 by Mike Harrison

flavicon
face
On Wed, 14 Dec 2005 12:23:39 -0200, you wrote:

>On 12/14/05, Mike Harrison <mikespamKILLspamwhitewing.co.uk> wrote:
>>
>> It is Microchip's fault that information on a relatively obscure issue is not as obvious as it
>> should be.
>> The original query was about debugging with ICD2. You should not need to read the details of the
>> programming spec to be able to use a debugger, and it is inexcusable that the ICD2 gives a
>> misleading 'programming failed' type message when it 'knows' that the supply is inadequate to do a
>> bulk erase and should be able to guide the user better as to what the problem is, i.e. that the
>> code-protect setting needs changing.
>>
>>
>
>I think the real question is: "Who debugs code protected chips?"
>
>I can't think of a single reason to code protect chips going into
>development boards. Of course, prototypes that might travel outside
>the door are another issue, but on boards used for development it's
>just a hindrance. And therefore it becomes a non-issue.

of course there is no need to CP while debugging, but it is entirely possible that the setting could
be there by accident or unintentional default - e.g. __Config line pasted from another project, or
doing further work on something that has been previously released to the outside world.
The latter is a particularly troublesome situation, e.g. :
1) Debug the design.
2) Set the CP option and program the chip (and maybe a few extra fresh ones out of the tube) for
prototypes.
No errors occur at this point as the chips were not previously protected.
3) A few weeks later, after testing the prototypes, go back to the project to find that programming
no longer works - you have changed no settings since programming the (previously unprotected) parts,
it just  doesn't work any more. Natural thing is to look for a hardware problem...
Much head-scratching and swearing.....

..or it could be that you had prioviosly been using ICD2 on a 5V design and not noticed the CP
state, as it wouldn't matter. Then you start a 3V design and programming fails the second time you
program the chip.



2005\12\14@131309 by Jose Da Silva

flavicon
face
On December 14, 2005 04:10 am, Olin Lathrop wrote:
> Jose Da Silva wrote:
> > Out of curiosity, if the chip is code protected, will the attempt
> > to bulk erase unprotect the chip?
>
> Yes, right after erasing all the protected content.

Thanks for also confirming.
As long as the process is erase-first, then after erasure it unprotects the chip instead of a parallel process in which enabling bulk erasure also runs a parallel process which unprotects the chip.

> > If yes, then it is definitely a grand goof-up of major concern!
>
> No, it's quite reasonable unless you want a single-use chip.

This wasn't really the point. :-)   Being a single use chip is okay, or as someone else pointed out, just develop unprotected until the time you decide to commit the program with protection, and then it becomes a single use chip.

What was of interest is that it's accidental or unexpected procedures like this which "sometimes" uncover flaws which may or may not be of concern. For example, let's say perhaps Microchip tested the chip at 3.3v and found out that reliable burns are at 4.5v or higher, therefore the spec says 4.5v, which is okay, but suppose the chip wasn't tested for code protection and someone accidentally uncovers a flaw.

In this case, Jesse Lackey, pulled out his hair on what may have exposed a problem and in his words doing a test run himself he got:

>I just tried the same thing, and got some strange results.  Blank
>check failed, reprogramming verified (!) but didn't work correctly..

this would indicate that protection appears okay.... the chip attempted to erase, didn't get very far (maybe some bits erased while others stayed burnt), and since it failed to do a proper erase, then the code protection remained in place.  Now, this would have been a problem if the code protect bit was a parallel process, in which case the bulk erase is happening at the same time as the code protect bit getting erased. Think of what would happen if someone started a bulk erase, then cut-power at the right moment.... you have a partly erased chip, but it's unprotected for what didn't get erased.

You've seen plenty of errata, so you know what I'm indicating, which is sometimes the documentation isn't exactly what happens internally, but in this case, it appears all is well in protection (as far as this test was concerned).

Cheers!

2005\12\14@140106 by Jesse Lackey

flavicon
face
In my opinion, unusual exceptions should be highlighted in the
documentation for a chip (or anything else).  In my opinion, requiring a
different minimum voltage for doing a particular kind of erase vs.
programming or "row" erase qualifies as an unusual exception, especially
since it can't be worked around in software or with the ICD2.

My primary concern was resolving what was going on with my current
design and understanding why it didn't occur in similar previous ones.

I will now stop "whining" about Microchip.  End of thread.


Olin Lathrop wrote:
{Quote hidden}

2005\12\14@175016 by Gerhard Fiedler

picon face
Mike Harrison wrote:

> ..or it could be that you had prioviosly been using ICD2 on a 5V design
> and not noticed the CP state, as it wouldn't matter. Then you start a 3V
> design and programming fails the second time you program the chip.

Don't you put the fuse settings in the project files?

Gerhard

2005\12\14@175250 by Gerhard Fiedler

picon face
Mike Hord wrote:

> You're right, of course, Olin, but I've long thought that it's kind of
> ridiculous that the ICD2 can't power the target when it runs in
> bus powered mode- after all, it could negotiate for up to 500 mA
> from the PC, and that's enough to run a lot of my circuits.

Yes, but as you say, it could /negotiate/ -- and it may not get it, for
example when downstream of a USB hub without own power supply. Which could
make the ICD2 behavior still more "mysterious" to some :)

Gerhard

2005\12\14@182529 by Mike Harrison

flavicon
face
On Wed, 14 Dec 2005 20:45:17 -0200, you wrote:

>Mike Harrison wrote:
>
>> ..or it could be that you had prioviosly been using ICD2 on a 5V design
>> and not noticed the CP state, as it wouldn't matter. Then you start a 3V
>> design and programming fails the second time you program the chip.
>
>Don't you put the fuse settings in the project files?

Yes.
I also often use old source files as templates for new ones, and old files may well have had the CP
set in the __config directive to generate a production file.
For 5V ICD2 projects this didn't matter.






2005\12\15@002325 by n Pergola (sent by Nabble.com)

flavicon
face

Hello Jesse,

It appears that there is hope...

Please note that it appears that many PIC18F MCUs can  be bulk erased with a Vdd voltage less  than 4.5 volts (with respect to Vss).

If still interested in this topic, take a look at this thread I posted back in August 2005 at the Microchip Forums for all the details:


ICSP Bulk Erase Vdd "Low"down: Falling trend?

http://forum.microchip.com/tm.asp?m=108526


I'm wondering if you are able to upgrade to the PIC18F2321 (after proper testing and qualification of course)? (I'm not sure if it is available yet so this post is sort of useless to you). I'd just thought I'd try to help out though...

Best regards,

Ken Pergola

P.S. I'm posting this through the Nabble interface so my apologies if this post is messed up or the link is broken.
--
Sent from the MicroControllers - PIC forum at Nabble.com:
www.nabble.com/-EE-bulk-erase-of-18F-parts-when-running-at-3.3V-can%27t-be-done-%21-t737852.html#a1952852

2005\12\15@011614 by Hector Martin

flavicon
face
Jose Da Silva wrote:
> On December 14, 2005 04:10 am, Olin Lathrop wrote:
>
>>Jose Da Silva wrote:
>>
>>>Out of curiosity, if the chip is code protected, will the attempt
>>>to bulk erase unprotect the chip?
>>
>>Yes, right after erasing all the protected content.
>
>
> Thanks for also confirming.
> As long as the process is erase-first, then after erasure it unprotects
> the chip instead of a parallel process in which enabling bulk erasure
> also runs a parallel process which unprotects the chip.
>

There have already been relatively simple ways of unprotecting a PIC.
Bunnie (the guy who hacked the xbox) did it with the 18F1320.

http://www.bunniestudios.com/?page_id=13

Read up. Interesting way microchip protected the CP bits, and
interesting workaround! (for those who don't want to read up: the config
word bit cells have metal shields on top of them to prevent selective UV
erasure.  But if you angle the chip the light seeps underneath.)

--
Hector Martin (.....hectorKILLspamspam.....marcansoft.com)
Public Key: http://www.marcansoft.com/hector.asc

2005\12\15@054544 by Gerhard Fiedler

picon face
Mike Harrison wrote:

>> Don't you put the fuse settings in the project files?
>
> I also often use old source files as templates for new ones, and old
> files may well have had the CP set in the __config directive to generate
> a production file. For 5V ICD2 projects this didn't matter.

I do the same (using previous projects as templates). But I review the
settings... code protection bits may not matter for 5 V designs, but a few
other bits do matter even for 5 V designs.

Basic rule: if it's a different design, some things may be different :)

Gerhard

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