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:
> 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.
> {
> ******************************************************************************* 
>
> *
> *   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;
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist