Searching \ for '[PIC] 18LF6722 Verify Errors with ICD-2' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/devprogs.htm?key=icd
Search entire site for: '18LF6722 Verify Errors with ICD-2'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] 18LF6722 Verify Errors with ICD-2'
2006\08\21@105909 by Harold Hallikainen

face picon face
I'm working on a system using the 18LF6722 running at 3.3V, using the
ICD-2 to program the chip. The first program of the chip seemed fine, but
now, on one board, I'm getting verify errors at location 0. It's finding
0x00 instead of the proper code in that location. I was having a similar
problem last week when I noticed that F chips instead of LF chips had been
loaded. These were swapped out and everything worked fine. Now, trying the
second program of the chips, I'm getting the error again. I'm running
MPLAB 7.31, but am downloading 7.41 in the hopes that fixes it. If it
doesn't, does anyone else have any ideas?

THANKS!

Harold


--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2006\08\21@112159 by Xiaofan Chen

face picon face
On 8/21/06, Harold Hallikainen <spam_OUTharoldTakeThisOuTspamhallikainen.com> wrote:
> I'm working on a system using the 18LF6722 running at 3.3V, using the
> ICD-2 to program the chip. The first program of the chip seemed fine, but
> now, on one board, I'm getting verify errors at location 0. It's finding
> 0x00 instead of the proper code in that location. I was having a similar
> problem last week when I noticed that F chips instead of LF chips had been
> loaded. These were swapped out and everything worked fine. Now, trying the
> second program of the chips, I'm getting the error again. I'm running
> MPLAB 7.31, but am downloading 7.41 in the hopes that fixes it. If it
> doesn't, does anyone else have any ideas?
>

I hope V7.41 can solve your problem. If not, a better solution is to foget
about ICD2 for professional work (I think you are most likely doing
professional work, correct me if I am wrong) and Promate III is
highly recommended. Or maybe you can try Olin's ProProg.

In one of the Microchip forum post, I recommened PM3 to replace ICD2
and the user is happy about PM3.

Quote from his reply:
"We received the PM3 last friday and tested it today. Worked like a charm!
Too bad we didn't know this before we vasted all the time on the ICD2.. "

Regards,
Xiaofan

2006\08\21@113401 by Xiaofan Chen

face picon face
On 8/21/06, Xiaofan Chen <.....xiaofancKILLspamspam@spam@gmail.com> wrote:
{Quote hidden}

I forget to put the link:
http://forum.microchip.com/tm.aspx?m=173411

2006\08\21@114634 by Bob Axtell

face picon face
Harold Hallikainen wrote:
> I'm working on a system using the 18LF6722 running at 3.3V, using the
> ICD-2 to program the chip. The first program of the chip seemed fine, but
> now, on one board, I'm getting verify errors at location 0. It's finding
> 0x00 instead of the proper code in that location. I was having a similar
> problem last week when I noticed that F chips instead of LF chips had been
> loaded. These were swapped out and everything worked fine. Now, trying the
> second program of the chips, I'm getting the error again. I'm running
> MPLAB 7.31, but am downloading 7.41 in the hopes that fixes it. If it
> doesn't, does anyone else have any ideas?
>
> THANKS!
>
> Harold
>
>
>  
Get rid of all MPLAB except 7.4 or above. The ICD2 firmware is broken on
earlier versions. It
will fix all this crazy stuff.

--Bob

2006\08\21@125101 by Harold Hallikainen

face picon face
OK, MPLAB 7.41 did not fix the problem. I guess use of another programmer
(like PM3) would be ok, but how am I supposed to debug stuff without the
ICD-2? This used to work fine! I really count on the use of the ICD-2 for
debug. It's a whole lot easier than just staring at the code trying to see
what's wrong (or even running it through the simulator, which doesn't
simulate all our hardware). This is really bad if we can't get the ICD
running! Again, until last week, it worked great! I dunno what changed. I
had not done an MPLAB upgrade in a while (I was running 7.31), so the ICD
firmware should not have changed. Now I'm running 7.41 in the hopes that
would fix the problem, but it did not. Here's the output when I try to
program the chip for debug:

MPLAB ICD 2 Ready
Resetting Target
MPLAB ICD 2 Ready
Programming Target...
...Validating configuration fields
...Erasing Part
...Programming Program Memory (0x0 - 0x6AFF)
...Loading DebugExecutive
...Programming DebugExecutive
...Programming Debug Vector
...Programming RSBUG
Verifying...
...Program Memory
ICD0161: Verify failed (MemType = Program, Address = 0x0, Expected Val =
0xD00C, Val Read = 0x0)
ICD0275:  Programming failed.
MPLAB ICD 2 Ready


Any ideas as to what to do for debug? We can get another programmer for
production, but we need to debug!

Thanks!

Harold


--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2006\08\21@140445 by Bob Axtell

face picon face
Harold Hallikainen wrote:
> OK, MPLAB 7.41 did not fix the problem. I guess use of another programmer
> (like PM3) would be ok, but how am I supposed to debug stuff without the
> ICD-2? This used to work fine! I really count on the use of the ICD-2 for
> debug. It's a whole lot easier than just staring at the code trying to see
> what's wrong (or even running it through the simulator, which doesn't
> simulate all our hardware). This is really bad if we can't get the ICD
> running! Again, until last week, it worked great! I dunno what changed. I
> had not done an MPLAB upgrade in a while (I was running 7.31), so the ICD
> firmware should not have changed. Now I'm running 7.41 in the hopes that
>  
oops. You did NOT upgrade to the downloadable firmware provided for the
ICD2 I/O by MPLAB7.4?
That's where the error is.

--Bob

{Quote hidden}

2006\08\21@145110 by Xiaofan Chen

face picon face
On 8/21/06, Harold Hallikainen <.....haroldKILLspamspam.....hallikainen.com> wrote:
> OK, MPLAB 7.41 did not fix the problem. I guess use of another programmer
> (like PM3) would be ok, but how am I supposed to debug stuff without the
> ICD-2?

You will not regret to go with PM3 for production programming.

> Any ideas as to what to do for debug? We can get another programmer for
> production, but we need to debug!
>

Get the US$500 Real ICE. You can check with Microchip about the availability.
It is much cheaper than ICE2000/4000 but it is said to be much better than ICD2.

Regards,
Xiaofan

2006\08\21@151831 by Harold Hallikainen

face picon face

{Quote hidden}

The only ICD-2 file I see after doing the upgrade to MPLAB 7.4 is:

C:\Program Files\Microchip\MPLAB IDE\ICD2\ICD05010309.hex

Is that not the current version? If not, what is, and where can I get it?

Also, when I do an erase, that doesn't work.

Here's what I get:

MPLAB ICD 2 Ready
Downloading Operating System
Connecting to MPLAB ICD 2
...Connected
Setting Vdd source to target
Target Device PIC18F6722 found, revision = Rev 0x0
...Reading ICD Product ID
Running ICD Self Test
...Passed
...Download Operating System Succeeded
MPLAB ICD 2 Ready
Erasing Target Device...
...Erase Succeeded
MPLAB ICD 2 Ready
Blank Checking...
...Program Memory
ICD0161: Verify failed (MemType = Program, Address = 0x0, Expected Val =
0xFFFF, Val Read = 0x0)
...Device not blank
MPLAB ICD 2 Ready


Ideas?

Thanks!

Harold

--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2006\08\21@152548 by Xiaofan Chen

face picon face
On 8/21/06, Xiaofan Chen <EraseMExiaofancspam_OUTspamTakeThisOuTgmail.com> wrote:

> > Any ideas as to what to do for debug? We can get another programmer for
> > production, but we need to debug!
> >
>
> Get the US$500 Real ICE. You can check with Microchip about the availability.
> It is much cheaper than ICE2000/4000 but it is said to be much better than ICD2.
>

More info for Real ICE. I have not seen it. But there is a discussion in
Microchip Forum.
http://forum.microchip.com/tm.aspx?m=180114

http://www.telcom-semi.com/stellent/groups/dspic_sg/documents/devicedoc/en024226.pdf

Page 46.

Features
Key features of the MPLAB REAL ICE system include:
• Full speed emulation on target device itself — no
separate emulator device needed
• Robust electrical design for safe, low-cost in-circuit
emulation
• High speed USB 2.0 PC interface
• Multiple target connections: traditional ICSP interface or
LVDS (add-on option)
• Run, Halt and Single-step modes
• 6 hardware breakpoints and other advanced breakpoint
features depending on the device
• 1000 software breakpoints (depending on the device)
• Instrumented (user-controlled) Program Memory Trace
and Data Memory Log, with run-time updates in MPLAB
IDE
• Stopwatch cycle counter
• Logic probe
• In-Circuit Serial Programming and read of on-chip Flash
memory




Regards,
Xiaofan

2006\08\21@153304 by Harold Hallikainen

face picon face
Checking the Microchip forums, it appears this is a common problem! It's
interesting that it started on Friday of last week. I don't think I'd done
any changes to MPLAB between the time it worked and when it didn't work.
We did change out the chips here (changing from 18F6722 to 18LF6722) and
they programmed fine... the first time. Now we get programming errors, as
pointed out before. Someone on the Microchip Forums said the problem was
the chips were not getting erased. I tried just an erase and blank check.
Results are:

MPLAB ICD 2 Ready
Running ICD Self Test
...Passed
Erasing Target Device...
...Erase Succeeded
MPLAB ICD 2 Ready
Blank Checking...
...Program Memory
ICD0161: Verify failed (MemType = Program, Address = 0x0, Expected Val =
0xFFFF, Val Read = 0x0)
...Device not blank
MPLAB ICD 2 Ready


So, it looks like that's the problem! Now, anyone know what can be done
about it? I'm currently using ICD05010309.hex on the ICD. Is there,
perhaps, a better older or newer revision? If so, what version works, and
where do I get it?

Though the PM3 may do the job as a production programmer, I DO need a
debugger!

THANKS!

Harold


--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2006\08\21@162325 by Mark Scoville

flavicon
face
>
>
> Ideas?
>
> Thanks!
>
> Harold
>

Hi Harold, I'm jumping in real late so excuse me if you already tried these
ideas.

I had similar issues about a year ago I think, my ICD2 would fail during the
verify phase during programming. As I recall it turned out to be a cabling
problem. Maybe try a different USB cable and/or different ICSP cable. Might
seem nuts, but what have you got to lose.

-- Mark



2006\08\21@164357 by John Temples

flavicon
face
You can't ICSP bulk erase or program some PICs with Vdd <4.5V.  What
I've noticed in practice is that programming often works, but erasing
doesn't.  So your first program of a new chip will be successful since
the part is blank, but subsequent attempts to erase will fail.

On Mon, 21 Aug 2006, Harold Hallikainen wrote:

{Quote hidden}

> --

2006\08\21@185538 by Harold Hallikainen

face picon face
Thanks! Interesting that it did work for a couple months of development,
then stopped last week. I can't raise Vdd without blowing out everything
else on the board. More ideas so I can get back to debugging new code?

THANKS!

Harold

{Quote hidden}

>> --

2006\08\21@194545 by Peter van Hoof

face picon face
Harold,

Did you try to go to icd2 program settings, the program tab, select manually select memory
and ranges and uncheck the "erase all before Programming" if I understand correctly
it will not try a bulk erase and this might solve your problem

YMMV
Peter van Hoof


{Original Message removed}

2006\08\21@200209 by John Temples

flavicon
face
Did you say your Vdd was 3.3V?  Does the ICD2 support programming that
part with that Vdd?

On Mon, 21 Aug 2006, Harold Hallikainen wrote:

{Quote hidden}

> --

2006\08\21@201300 by Peter van Hoof

face picon face
Disregard this suggestion,

According to the help file this will not work , programs will be merged and not as I expected erased  row by row.

Peter van Hoof

{Original Message removed}

2006\08\21@203740 by Xiaofan Chen

face picon face
On 8/21/06, Harold Hallikainen <haroldspamspam_OUThallikainen.com> wrote:
> Thanks! Interesting that it did work for a couple months of development,
> then stopped last week. I can't raise Vdd without blowing out everything
> else on the board. More ideas so I can get back to debugging new code?
>

Just a thought: you mentioned that you can program the chip when
debugging under 3.3V before even thought the guaranteed voltage for
bulk erasing is above 4.5V. Maybe you can try a new PIC18LF6722
or a new board and it might work again. I suspect that at 3.3V many
LF chips can be bulk-erased even though it can get worse after some
operations. This is not a good solution, I know.

The design should upfront take care of ICSP and debugging (to have a
isolated 5V supply for ICSP programming and debugging).

Maybe it is a good idea to avoid these LF chips for 3.3V operation
since they are a bit troublesome for ICSP and debugging.

Still I believe Real ICE is a better solution. The problem is that it
has not officially been out yet.

Regards,
Xiaofan

2006\08\21@222402 by peter green

flavicon
face

> Get the US$500 Real ICE. You can check with Microchip about the
> availability.
> It is much cheaper than ICE2000/4000 but it is said to be much
> better than ICD2.
isn't realice for the pic24/dspics only?

2006\08\21@224008 by John Chung

picon face
Just a hunch. When you program the chip off the board
does it work? Does bulk erase work?

John

--- Harold Hallikainen <@spam@haroldKILLspamspamhallikainen.com> wrote:

{Quote hidden}

> --

2006\08\22@004557 by Harold Hallikainen

face picon face

>
> Maybe it is a good idea to avoid these LF chips for 3.3V operation
> since they are a bit troublesome for ICSP and debugging.
>

What's the difference between an F and an LF? I kinda thought that an LF
was the same as an F that passed low voltage testing.

Do we really need to isolate the Vdd supply from the rest of the circuit
so it can be pulled up to 5V for ICSP?


Thanks!

Harold



--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2006\08\22@004630 by Harold Hallikainen

face picon face

> Did you say your Vdd was 3.3V?  Does the ICD2 support programming that
> part with that Vdd?
>

Well... I dunno. It worked for the past few months. How do you debug a
3.3V system with an ICD-2 if you can't program the chip?

Harold


--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2006\08\22@045954 by Bob Axtell

face picon face
Harold Hallikainen wrote:
>> Maybe it is a good idea to avoid these LF chips for 3.3V operation
>> since they are a bit troublesome for ICSP and debugging.
>>
>>    
>
> What's the difference between an F and an LF? I kinda thought that an LF
> was the same as an F that passed low voltage testing.
>
> Do we really need to isolate the Vdd supply from the rest of the circuit
> so it can be pulled up to 5V for ICSP?
>
>  
Yep. I normally use a diode.

--Bob
> Thanks!
>
> Harold
>
>
>
>  

2006\08\22@052501 by Lee Jones

flavicon
face
> PIC18LF6722 at 3.3V

I ran into a similar problem with a 18LF6621 at 3.3V.  I could
program and reprogram the part just fine with an ICD-2 on USB.

Then I set code protection on a part.  The erase command claimed
to work fine.  Program command claimed to succeed but verify kept
failing.  Erase at 3.3V wouldn't clear code protection.

I traced it ot the USB connection to ICD-2 won't supply necessary
>4.5V to PIC which is needed to bulk erase the code protect bits.

To fix it, I used jumpers from an external 3 x AA battery pack
via clip leads to the Vdd on the PIC part.  A repeat of the bulk
erase command via ICD-2 cleared the code protect bits & board/PIC
went back into normal development (program/debug/reprogram/etc).

                                               Lee Jones

2006\08\22@055605 by Lee Jones

flavicon
face
> Do we really need to isolate the Vdd supply from the rest of the circuit
> so it can be pulled up to 5V for ICSP?

Yes.
                                               Lee Jones

2006\08\22@062347 by Wouter van Ooijen

face picon face
> > Do we really need to isolate the Vdd supply from the rest
> of the circuit
> > so it can be pulled up to 5V for ICSP?
>
> Yes.

I would say: only if the rest of circuit won't tolerate 5V, or the
progger can't suply the required current.

Wouter van Ooijen

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


2006\08\22@082129 by olin piclist

face picon face
Harold Hallikainen wrote:
> Do we really need to isolate the Vdd supply from the rest of the circuit
> so it can be pulled up to 5V for ICSP?

Generally yes.  http://www.embedinc.com/picprg/icsp.htm

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

2006\08\22@113344 by Harold Hallikainen

face picon face
THANKS! I have not looked at the details of programming the chips, leaving
that to the programmer itself. I've done a few 3V projects and have not
had a problem with programming or debugging the PIC. It's just this week
that I found the problem. I guess I've been lucky! So, now I have to
figure out how to modify the circuit to make it work.

I guess the problem is "bulk erase." Is there a "non-bulk" erase, such as
that used in bootloading? Is there any chance a serial programmer could
use that? If I add a low Vf diode between my +3.3V supply and the PIC Vdd
(with bypass capacitors on the PIC pins) and allowing the programmer to
drive the PIC Vdd, should that work? During programming, I assume all the
PIC I/O pins are in input mode and will not shove 5V out to my 3.3V
devices, right? During debug, the ICD stops driving Vdd so my normal
supply would drive it, right?

I guess I should've looked more closely at programming when running the
PIC on low voltage. Again, is the only problem bulk erase? Is there a way
around that?

THANKS to everyone!

Harold


> Harold Hallikainen wrote:
>> Do we really need to isolate the Vdd supply from the rest of the circuit
>> so it can be pulled up to 5V for ICSP?
>
> Generally yes.  http://www.embedinc.com/picprg/icsp.htm
>
> ******************************************************************
> Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
> consultant in 2004 program year.  http://www.embedinc.com/products
> -

2006\08\22@122458 by Bob Axtell

face picon face
Harold Hallikainen wrote:
> THANKS! I have not looked at the details of programming the chips, leaving
> that to the programmer itself. I've done a few 3V projects and have not
> had a problem with programming or debugging the PIC. It's just this week
> that I found the problem. I guess I've been lucky! So, now I have to
> figure out how to modify the circuit to make it work.
>
>  
I isolate the rest of the circuit with a simple schottky diode
(germanium has less drop, if you have room
for a 1N270). The VDD is supplied from programmer or ICD2. When
programming, no external
circuits need be activated.

--Bob

{Quote hidden}

>> --

2006\08\22@123638 by Xiaofan Chen

face picon face
On 8/21/06, peter green <KILLspamplugwashKILLspamspamp10link.net> wrote:
>
> > Get the US$500 Real ICE. You can check with Microchip about the
> > availability.
> > It is much cheaper than ICE2000/4000 but it is said to be much
> > better than ICD2.
> >
> isn't realice for the pic24/dspics only?
> --

Yes you are right that it initially only supports the dsPIC30F601XA,
dsPIC33F, PIC24H and PIC24F 16-bit devices. But I think they
will extend the support to PIC18F or even 16F later.

http://www.telcom-semi.com/stellent/groups/dspic_sg/documents/devicedoc/en024226.pdf

Regards,
Xiaofan

2006\08\22@132331 by WH Tan

picon face
2006/8/22, Harold Hallikainen wrote:

> Well... I dunno. It worked for the past few months. How do you debug a
> 3.3V system with an ICD-2 if you can't program the chip?
>

Harold,

Have you inadvertently turned on any code protection bit in the device
configuration?

If you just want to debug, it's fine and you SHOULD be able to do so,
even without isolate the the target Vdd. But you have to be careful
about this:  never turn on any code protection bit!  If you do so,
then the only way to get the device back to its original condition is
by "bulk erase", which of course only can be done with Vdd > 4.5V for
your PIC18LF6722.

About a year ago I had a prototype with PIC18LF8720, operated in 3.3V.
Well I can't recall any problem with my debugging session with ICD2.
Today after read your problem here, and out of my own curiosity, plus
worry that Microchip might decide to change thing a bit, I have taken
out my old proto-board to carry out some test.  Well you might just
like the result I got here:

MPLAB IDE v7.41
PIC18LF8720 with Vdd = 3.3V

Downloading Operating System
Connecting to MPLAB ICD 2
...Connected
Setting Vdd source to target
Target Device PIC18F8720 found, revision = a4
...Reading ICD Product ID
Running ICD Self Test
...Passed
...Download Operating System Succeeded

MPLAB ICD 2 Ready
Programming Target...
...Validating configuration fields
...Erasing Part
...Programming Program Memory (0x0 - 0x749F)
...Loading DebugExecutive
...Programming DebugExecutive
...Programming Debug Vector
...Programming RSBUG
Verifying...
...Program Memory
...Debug Executive
...Debug Vector
...Verify Succeeded
Programming Configuration Bits
.. Config Memory
Verifying configuration memory...
...Verify Succeeded
Connecting to debug executive
...Programming succeeded
...........

MPLAB ICD 2 Ready





And in the MPLAB ICD2 setting dialogue box>Power tab, I have MPLAB
reported the following:

Power target circuit check box:  Unchecked
Target Vdd: 3.28V
Target Vpp: 12.54V


Well I think I can conclude that the MPLAB ICD2 works as before:  When
you have a target circuit with Vdd less than the nominal voltage for
bulk erase, ICD2 will be smart enough not to use bulk erase, but
something that I have forgotten its name: FIXME maybe 'page erase'...


Now as far as your problem is concerned, I have no clue.  But I think
it's you who should have a better idea.  You said that it worked
before, then all of sudden it didn't work now.  Can you recall any
change you have made to your system?  Also how about the code
protection of the configuration?


Best regards,

--
WH Tan

2006\08\22@141911 by Herbert Graf

flavicon
face
On Mon, 2006-08-21 at 20:43 -0700, Harold Hallikainen wrote:
> >
> > Maybe it is a good idea to avoid these LF chips for 3.3V operation
> > since they are a bit troublesome for ICSP and debugging.
> >
>
> What's the difference between an F and an LF? I kinda thought that an LF
> was the same as an F that passed low voltage testing.

Generally F and LF parts are the exact same dies. The only difference is
LF parts have been tested at a lower voltage and passed.

> Do we really need to isolate the Vdd supply from the rest of the circuit
> so it can be pulled up to 5V for ICSP?

If you're doing "normal" devel no, since "normal" devel never needs a
bulk erase.

I've worked with the 18LF2320 at 3.3V with the ICD2 with zero problems.

If you enable code protection OTOH you have to do a bulk erase, and for
that you'll need to be up near 5V.

TTYL

2006\08\22@142114 by Herbert Graf

flavicon
face
On Mon, 2006-08-21 at 20:45 -0700, Harold Hallikainen wrote:
> > Did you say your Vdd was 3.3V?  Does the ICD2 support programming that
> > part with that Vdd?
> >
>
> Well... I dunno. It worked for the past few months. How do you debug a
> 3.3V system with an ICD-2 if you can't program the chip?

If the circuit is self powered, and you don't program the chip in such a
way that requires a bulk erase to reprogram (i.e. enabling code
protection) you can program the chip with the ICD2 at 3.3V without a
problem.

TTYL

2006\08\22@144537 by Harold Hallikainen

face picon face

{Quote hidden}

THANKS for the info! So, from above, it looks like I only get into trouble
with programming with Vdd at 3.3V if I previously programmed with code
protect on? I just looked at that project, and code protect IS on. I may
have turned it on because I felt they were getting close to shipping
product.

Interesting that the ICD is "smart enough" to not do a bulk erase if the
code protection is disabled, but is dumb if code protection is enabled. I
GUESS that might be a protective measure keeping someone from erasing the
boot area, dropping in their own dump hex code, and then seeing the rest
of the chip. Right?

I guess I'll try replacing the chips on the prototypes and turn off code
protect.

THANKS!

Harold



--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2006\08\22@150618 by Jan-Erik Soderholm

face picon face
Harold Hallikainen wrote :

> Interesting that the ICD is "smart enough" to not do a bulk
> erase if the code protection is disabled,

Not becuse it's smart, but becuse it's possible.

> but is dumb if code protection is enabled.

And that is becuse low-voltage erase are not possible on
"protected" memory areas. Not much the ICD2 can do about
that.

The only way to erase/reprogram a protected memory block,
is throught high-voltage "bulk erase", no matter what programmer
or debugger is used.

Jan-Erik.



2006\08\22@150803 by Harold Hallikainen

face picon face

{Quote hidden}

THIS seems to be key! I guess the bulk erase requirement if code protect
is on is a security measure. I DID set code protect when my client sent a
unit to Freescale to figure out what was going on with their DSPs. I guess
I'll swap out chips one more time and not set code protect until we
actually start shipping!

Thanks to all!

Harold


--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2006\08\22@164210 by Herbert Graf

flavicon
face
On Tue, 2006-08-22 at 11:45 -0700, Harold Hallikainen wrote:
> Interesting that the ICD is "smart enough" to not do a bulk erase if the
> code protection is disabled, but is dumb if code protection is enabled.

I'm pretty sure the ICD2 DOES the bulk erase if code protect is on. Even
if it doesn't, you can't blame it for you trying to do something out of
spec.

> I
> GUESS that might be a protective measure keeping someone from erasing the
> boot area, dropping in their own dump hex code, and then seeing the rest
> of the chip. Right?

It has nothing to do with the ICD2. The chip enforces this rule: if code
protect is on, a bulk erase is required before any programming takes.

If you don't supply the chip enough voltage to do the bulk erase, it
won't happen.

TTYL

2006\08\22@164316 by Jan-Erik Soderholm

face picon face
Just a minor thing that comes to mind...

You (Harold) wrote about letting the ICD2 supply 5V
to the curcuit. And that the pins will he high-Z during
the programmer anyway so it would not damage
the rest of the curcuit (if it's not 5V compatible).

Now, I'm not sure how the ICD2 works, but if there is
a "run" function or mode (that releases the MCLR line)
one must be sure that the 5V supply is also shut down
first. If not, all output pins of the processor will begun
outputting 5V into the rest of the curcuit.

Maybe the ICD2 manages this in a clever way,
I don't know. It was just a thought....

Jan-Erik.



2006\08\22@200901 by Harold Hallikainen

face picon face
THANKS to all those who responded! The trick was that I had set code
protect, which then requires the bulk erasing, which could not be done at
3.3V. We're modifying the board to put a low Vf diode to the PIC Vdd pins
with bypass capacitors at the pins. We also have an unused pin right next
to the Vdd pin on our ICSP header, so we're going to put 3.3V on that.
Once the device is programmed, we'll put a jumper between those two pins
so the PIC has full voltage. Most updates will be bootloaded in, but this
way we can also ICSP load new code.

Again, THANKS for all the help!

Harold

--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2006\08\23@074858 by olin piclist

face picon face
Harold Hallikainen wrote:
> I guess the problem is "bulk erase." Is there a "non-bulk" erase, such
> as that used in bootloading?

Some PICs have means to erase and re-write parts of memory.

> Is there any chance a serial programmer
> could use that?

That depends on the programmer of course.  Even when PICs do have the
ability to erase and re-write only a section of memory, there are always
restrictions.  For example, it can't be done with code protection enabled.
As far as I am aware, the only way to turn off code protection is via the
special erase commands that also erase the whole area covered by the code
protection bits you want to disable.  Some PICs give you several regions
that can be erased and code protection disabled independently, with others
providing a whole chip bulk erase as the only means.

Because of the various restrictions, all of my programmers do a bulk erase
to start with.  This is the only way to absolutely put any PIC in a known
state.  Other programmers may be more fancy and use some of the partial
erase commands.  I think the ICD2 does this since it is capable of using the
target Vdd and still update the firmware for debugging - most of the time.

> If I add a low Vf diode between my +3.3V supply and the
> PIC Vdd (with bypass capacitors on the PIC pins) and allowing the
> programmer to drive the PIC Vdd, should that work?

It should work for programming.  Whether your circuit can tolerate the diode
drop is something only you can answer.

> During programming,
> I assume all the PIC I/O pins are in input mode and will not shove 5V
> out to my 3.3V devices, right?

All except PGC and PGD, which will be driven between ground and whatever the
PIC Vdd is at the time.  Also remember that Vpp can go to around 13V in most
cases.


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


'[PIC] 18LF6722 Verify Errors with ICD-2'
2006\09\11@101232 by alan smith
picon face
I've also run into this...so you need to program the part with 5V the first time around, a real pain if the board Vdd is 3.3V, but once you have done it, then you can program to your hearts content with 3.3.

John Temples <RemoveMEpiclistTakeThisOuTspamxargs.com> wrote:  You can't ICSP bulk erase or program some PICs with Vdd <4.5V. What
I've noticed in practice is that programming often works, but erasing
doesn't. So your first program of a new chip will be successful since
the part is blank, but subsequent attempts to erase will fail.

On Mon, 21 Aug 2006, Harold Hallikainen wrote:

               
---------------------------------
Stay in the know. Pulse on the new Yahoo.com.  Check it out.

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