Searching \ for '[PIC] chip erase 16F877A problems' 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=16F
Search entire site for: 'chip erase 16F877A problems'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] chip erase 16F877A problems'
2006\06\25@130901 by Stef Mientki

flavicon
face

I just had a series of 12 pieces of 16F877A,
and because the first (and only ;-) one didn't erase very well,
(locations 0, 8, 16, etc were not completely erased)
so I tested the whole serie a number of times.

And although the programming specs say something like this:
"Previously a load data with 0FFh was recommended before an erase is
performed.
On these devices, this will not be required."

I tested the whole series several times,
both with pointing to the program memory (no config erase)
and pointing to the config memory,
and this were the results:
data = 0FFh        not reliable, even one PIC would never get completely
erased
data = 03FFFh   not reliable, even one PIC would never get completely erased
data = 0             works perfect (on this series ;-)

Has anyone seen this behavior before ?
or knows if it's noticed in one the microchip documents ?

thanks,
Stef Mientki

2006\06\25@153214 by Bob Axtell

face picon face
Stef Mientki wrote:
{Quote hidden}

I have seen this many times. It is caused by only ONE thing (besides a
bad PIC):

Make absolutely ABSOLUTELY sure that the VCC is at 4.75+ (without
ripple) at all times during bulk erase.
I have seen "ripply" wallwarts cause this strange result. Remember that
4.8V with  50 mV of ripple will NOT
work.

--Bob

2006\06\26@063011 by Jim Robertson

flavicon
face

{Quote hidden}

Sounds like a more severe form of a problem I described on the piclist
back in late Feb 2005. Notice I also refer to a Mod 8 erase issue.

Below is a cut and paste to save you digging though the archives.

It would be interesting to see what you can confirm on this issue.

Regards,

Jim

{Quote hidden}

2006\06\26@071246 by olin piclist

face picon face
part 1 1378 bytes content-type:text/plain; format=flowed; charset="iso-8859-1"; (decoded 7bit)

Jim Robertson wrote:
> Sounds like a more severe form of a problem I described on the piclist
> back in late Feb 2005. Notice I also refer to a Mod 8 erase issue.
>
> Below is a cut and paste to save you digging though the archives.
>
> ...
>
>> Fortunately, there is a easy work around. If the write latch is
>> preloaded with 0x3FFF the problem does not manifest.
>> Note that the Programming specs says this step is not required.
>> the reality is that with some (not all, some) silicon revisions it is.

I ran into a similar problem with the original 16F877 (I think that was it)
a long time ago.  I remember figuring out that the write latches needed to
be loaded with 3FFFh for the bulk erase to work, even though this was not
mentioned in the programming spec.  It sortof makes sense that this might be
needed.  Since then I've always sent data of 3FFFh with any erase command
and I haven't had problems.  That's probably why I never ran into this case
for the 16F87xA.  I've attached the source code of the erase subroutine for
the 16F87xA.  This is in the file PICPRG_16.PAS in the PICPRG source
directory in case anyone wants to see more of the code.  All my PIC
programmer software, including source code and build scripts, and be
downloaded from http://www.embedinc.com/picprg/sw.htm.


part 2 1339 bytes content-type:text/plain;
(decoded quoted-printable)

{
*******************************************************************************
*
*   Subroutine PICPRG_ERASE_16F87XA (PR, STAT)
*
*   Erase all erasable non-volatile memory in the target chip.
*
*   This version is specific to devices that use the CHIP ERASE command,
*   like the 16F87xA family.
}
procedure picprg_erase_16f87xa (       {erase routine for 16F87xA}
 in out  pr: picprg_t;                {state for this use of the library}
 out     stat: sys_err_t);            {completion status}
 val_param;

begin
 picprg_reset (pr, stat);             {reset target to put it into known state}
 if sys_error(stat) then return;

 picprg_cmdw_writing (pr, stat);      {indicate the target is being written to}
 if sys_error(stat) then return;

 picprg_send6 (pr, 2#000000, stat);   {send LOAD CONFIGURATION command}
 if sys_error(stat) then return;
 picprg_send14ss (pr, 16#3FFF, stat); {send the data word for this command}
 if sys_error(stat) then return;

 picprg_send6 (pr, 2#111111, stat);   {CHIP ERASE}
 if sys_error(stat) then return;
 picprg_cmdw_wait (pr, 0.010, stat);  {force delay before next operation}
 if sys_error(stat) then return;

 picprg_reset (pr, stat);             {reset target to guaranteed known state}
 if sys_error(stat) then return;
 end;


part 3 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

2006\06\27@164132 by Stef Mientki

flavicon
face
Bob, Jim, Olin,

thanks for the information.

Bob, I measured the ripple, and it was about 40 mV (a few 100 kHz).
I doubt if this could really be the problem,
because why should the ripple have no effect when I preload with data=0 ?
It's also not easy to achievem because the PIC to be programmed is
connected through a 25 cm flatcable,
and no capacitors are allowed at the end of the flatcable (because of
switching times).

Jim, I've tested again, and I still find the exact opposite of your
measurements,
maybe I do really have a bad PIC ;-)

Olin, thanks for the information. Interesting to see that I've chosen
the opposite approach:
the PC-program is very general and doesn't contain any intelligence,
all the intelligence (as far as possible) is put in the PIC that
controls the programmer.
The reason for that is quit simple,
as most pic users are not very experienced with writing  / modifying PC
programs,
and a I wanted every PIC user to be fully able to implement whatever
programming algorithm (s)he wants.
If you're interested, you can see a preview here
http://oase.uci.kun.nl/~mientki/data_www/pic/jalcc/help/uploader.html

So based on the above experience, I simply try all plausible datawords,
until the chip is fully erased.

So here th JAL program that performs the tasks.

-- start trying to erase with preloading of DATA=0
-- according to the datasheets, the value of data shouldn't matter
-- but from my own experience a data value of zero worked best
data=0
PIC_write_cmd_word (cmd_load_configuration)
PIC_write_cmd (cmd_chip_erase)
delay_1ms(8)

if ! verify_full_erase then
  -- if erase was not succesfull,
  -- try to erase with preloading of DATA=0x3FFF
  -- this suggestion was made by several programmer builders
  data=0x3FFF
  PIC_write_cmd_word (cmd_load_configuration)
  PIC_write_cmd (cmd_chip_erase)
  delay_1ms(8)

    -- if erase was still not succesfull,
    -- try to erase with preloading of DATA=0xFF
    -- this value was suggested for "old" devices
    if ! verify_full_erase then
    data=0xFF
    PIC_write_cmd_word (cmd_load_configuration)
    PIC_write_cmd (cmd_chip_erase)
    delay_1ms(8)
  end if
end if

cheers,
Stef


Olin Lathrop wrote:
{Quote hidden}

2006\06\27@173139 by olin piclist

face picon face
Stef Mientki wrote:
> Interesting to see that I've chosen
> the opposite approach:
> the PC-program is very general and doesn't contain any intelligence,
> all the intelligence (as far as possible) is put in the PIC that
> controls the programmer.

You are either going to need a very big PIC to hold all the programming
algorithms and higher level information, or your programmer is going to be
ghastly slow.  There is a lot of PIC-specific data that has to be kept
somewhere, let alone acted upon.

For example, my data file that defines the particulars of every PIC I
support is over 4000 lines long and nearly 100Kbytes in size.  Of course
that's verbose text since a few 100Kbytes don't matter compared to clarity
and maintainability.  I ran it thru WinZip and it reduced to 4Kbytes.  Even
that is probably more than necessary if a tight data structure were designed
just for the purpose.  However it gives some feel for the volume of data
required.

> The reason for that is quit simple,
> as most pic users are not very experienced with writing  / modifying
> PC programs,
> and a I wanted every PIC user to be fully able to implement whatever
> programming algorithm (s)he wants.

Most PIC users don't know from programming algorithms and don't really want
to deal with them.  Even for those that do, the existence of higher level
logic on the PC doesn't proclude them from implementing their own
algorithms.

> So based on the above experience, I simply try all plausible
> datawords,
> until the chip is fully erased.

And how long does it take if it starts out with 0, goes up sequentially, and
3FFFh is eventually found to be the right answer?


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

2006\06\28@025612 by Wouter van Ooijen

face picon face
> It's also not easy to achievem because the PIC to be programmed is
> connected through a 25 cm flatcable,
> and no capacitors are allowed at the end of the flatcable (because of
> switching times).

Stef, I hope you do have decoupling cap(s) (at the very least one 100nF)
on the power pins directly at the target chip? I have heard of PICs
failing to program in mysterious ways without that cap.

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\06\28@152634 by Stef Mientki

flavicon
face

> Stef, I hope you do have decoupling cap(s) (at the very least one 100nF)
> on the power pins directly at the target chip?
hi Wouter, I didn't ....
... I shouldn't know an elegant way with a 40 pins ZIF socket,
where pin assignments continuously change ;-)
I could make a special flatcable ...
... but a tested with the "bad" chip,
and 100nF + 10uF directly on the chip pins,
doesn't change anything,
the only thing that helps is preloading zeroes !!

cheers,
Stef

2006\06\28@154516 by Stef Mientki

flavicon
face


Olin Lathrop wrote:
> Stef Mientki wrote:
>  
>> Interesting to see that I've chosen
>> the opposite approach:
>> the PC-program is very general and doesn't contain any intelligence,
>> all the intelligence (as far as possible) is put in the PIC that
>> controls the programmer.
>>    
>
> You are either going to need a very big PIC to hold all the programming
> algorithms and higher level information, or your programmer is going to be
> ghastly slow.  There is a lot of PIC-specific data that has to be kept
> somewhere, let alone acted upon.
>  
I think I didn't declare what I see as "intelligence" ;-)
In the PC program I use an inifile,
which either be edited in the program or just with a plain text editor.
This inifile contains for each chip the
number/ID/sizes/programming-algoritme-number.
The programming-algortime-number is just a number,
which is translated in the PIC to the different algoritms.
So still yields, the PIC user can implement anything he likes,
by just writing a program in his favorite PIC language.
> Most PIC users don't know from programming algorithms and don't really want
> to deal with them.  Even for those that do, the existence of higher level
> logic on the PC doesn't proclude them from implementing their own
> algorithms.
>  
In the past I was asked several times,
to implement the algoritm for xxx or yyy,
because the asker couldn't deal with the higher language on the PC,
as I'm doing this all in my spare time,
I thought this would be the perfect solution,
at least for me ;-)

>  
>> So based on the above experience, I simply try all plausible
>> datawords,
>> until the chip is fully erased.
>>    
>
> And how long does it take if it starts out with 0, goes up sequentially, and
> 3FFFh is eventually found to be the right answer?
>  
3 plausible datawords, an intelligent checking algortime,
that'll be for an 8k memory size about 2*0.1 msec extra.
Well I think I can afford that ;-)

cheers,
Stef

2006\06\28@162817 by Wouter van Ooijen

face picon face
> > Stef, I hope you do have decoupling cap(s) (at the very
> least one 100nF)
> > on the power pins directly at the target chip?

> hi Wouter, I didn't ....

Just remember to try this when you run into (other) trouble. I dunno
whether your 25 cm would cause a problem or not, but I certainly had
reports that omitting the decoupling at the target caused problems.

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\06\28@192102 by Xiaofan Chen

face picon face
On 6/29/06, Wouter van Ooijen <spam_OUTwouterTakeThisOuTspamvoti.nl> wrote:
> > > Stef, I hope you do have decoupling cap(s) (at the very
> > least one 100nF)
> > > on the power pins directly at the target chip?
>
> > hi Wouter, I didn't ....
>
> Just remember to try this when you run into (other) trouble. I dunno
> whether your 25 cm would cause a problem or not, but I certainly had
> reports that omitting the decoupling at the target caused problems.
>
> Wouter van Ooijen

The bypass capacitor and cable can be the issue here. I had problems
with 18F4550 with xwisp2/Wisp628 when I was testing xwisp2 beta versions
last year. Adding the bypass capacitor and shortening the cables solved
the problems.

This problem affect PICkit 2 and ICD2 as well. Now I am using a
universal programming adapter where the bypass capacitors are
already in. The picture of the adapter is here:
http://www.pic16.com/wzcapi/mcd2/ad01.jpg

Here is one related thread.
http://forum.microchip.com/tm.aspx?m=170399

Regards,
Xiaofan

2006\06\28@194536 by Bob Axtell

face picon face
Xiaofan Chen wrote:
{Quote hidden}

It also seems to solve problems when programming the PIC16F88. The clue
was that ICSP
connections always worked perfectly, but when programmed on the ZIP
socket, the failure
was high. No, the PGM pin was pulled down. 0.01uF seemed to do the trick.

--Bob
> Here is one related thread.
> http://forum.microchip.com/tm.aspx?m=170399
>
> Regards,
> Xiaofan
>  

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