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



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

>To: PICLIST
>Subject: [PIC] 16F87xA silicon bug (programming)
>
>
>It would appear the some revisions of the 16F87xA do not program
>correctly under some circumstances (detailed below.)
>
>This issue has plagued some owner of the WARP-13 and possibly
>other programmers. It really depends on how the programmer did
>the chip erase and what revision of silicon you had.
>
>The problem manifest itself as intermittent programming failures.
>(Sometimes as much as every second program cycle.) Usually the
>addresses that failed followed a pattern (Mod 8 was typical but
>other patterns have also been noted.)
>
>The problem relates to the "chip erase" (0x1f) command as it does
>not always work correctly even when used as documented in
>programming specification 39589b
>
>The conditions when it fails are.
>
>1) LVP disable (prior to chip erase)
>2) PC = 2000-201F during chip erase.
>3) Certain Silicon revisions as DUT
>
>(4) Oscillator settings have influence sometimes.)
>
>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.
>
>Anyone with a WARP-13 who has had problems with the programming
>of the 16F87xA in the past should contact myself directly for the
>URL of the latest interim driver. An official release is pending other
>improvements and could be a few days off yet so please contact
>me directly for the stop gap release.
>
>Regards,
>
>Jim


-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist