Post by thread:[PIC:] 16F87xA silicon bug (programming)

>Yeah, that's a well known issue on some 16 family PICs, although I wasn't >aware of it on the 87xA series because I haven't implemented support for >them yet. I think I first noticed that a couple of years ago on the 16F877, >but I'm not in the same office right now as my notes on that. I'm surprised >you got away without the fix for this long. No Olin, this is NOT a well known issue with any other 16 family PIC and if were, chances are I would have been the one to made it well known. I am providing information based on my experience of providing programming support for every single 16F PIC, user feedback from a base of thousands and many hours of hands on testing backed up by the testing of others. The is a problem quite specific to some silicon revisions of the 16F87xA family. You cannot make comparisons with any other 16F family member because either the erase algorithm is different and/or no such problem manifests. For example, in the 16F877 that you bought up, the erase algorithm very clearly specifies loading of the write latches with 0x3fff. The specs for the 16F87xA parts however are equally clear: [Quote]Previously, a load data with 0FFh command was recommended before any Bulk Erase. On these devices, this will not be required. [/unquote] The intent of the 16F87xA programming spec is clear and the specified chip erase algorithm does work correctly for the earlier silicon. The same chip erase algorithm is specified for the 16F81x and 16F88/89 PICs and no such problem exists with those devices. Are you getting this? >It kindof makes sense when you think about it, since you are essentially >writing 1s to all the bits. I'm guessing this is more of an error in the >programming spec than the chips, but in any case I always write 3FFFh to the >data latches on a bulk erase on these parts. You are right of course, you are guessing and not taking in what is being presented here. You of all people would do well to not dismiss this as a "well known issue." After all, I still have a schematic of one of your earlier easyprog revisions. You know, the one where you implemented only a single VDD channel and wired it to pin-36 of the programming socket, and after all that had been said by me, BAJ and others on this issue over the years. See: http://www.piclist.com/techref/microchip/16F877/hvprog.htm Regards, Jim

Jim Robertson wrote: > No Olin, this is NOT a well known issue with any other 16 family PIC > and if were, chances are I would have > been the one to made it well known. I am providing information based on > my experience of providing programming > support for every single 16F PIC, user feedback from a base of thousands > and many hours of hands on testing > backed up by the testing of others. > > The is a problem quite specific to some silicon revisions of the 16F87xA > family. You cannot make comparisons > with any other 16F family member because either the erase algorithm is > different and/or no such problem manifests. > > For example, in the 16F877 that you bought up, the erase algorithm very > clearly specifies loading of the write latches > with 0x3fff. OK, so that wasn't the one. It's morning again, and I'm not in the same office as my notes on this, but I definitely remember running into a problem like this a few years back. The bulk erase didn't work right, and after some trial and error I discovered that a different value had to be written somewhere than specified in the programming spec. At the time I mentioned it to someone at Microchip, and they reacted like "Yeah, we know about that". I therefore concluded the issue was "well known". This was only one of several errors or misleading information in the programming specs. > [Quote]Previously, a load data with 0FFh command was recommended > before any Bulk Erase. On these devices, > this will not be required. > [/unquote] If I remember right (and I may not, it was 2 1/2 years ago), the spec I found the problem with explicitly said to write 0 somewhere and the right answer was 3FFFh. > Are you getting this? Geesh, no need to get peeved. I was reporting what I believed to be the case. I wasn't trying to piss off you or anyone else. > You of all people would do > well to not dismiss this as a "well known issue." I wasn't dismissing it. It definitely needs to be worked around, and hopefully Microchip will update the documentation. > After all, I still > have a schematic of one of your earlier easyprog > revisions. You know, the one where you implemented only a single VDD > channel and wired it to pin-36 of the > programming socket, and after all that had been said by me, BAJ and > others on this issue over the years. See: > http://www.piclist.com/techref/microchip/16F877/hvprog.htm Wow, that brings back some old history! I had to go digging thru old schematics to see what you were talking about. I had never seen that web page before, but I do remember discovering the problem for myself sometime around August 2002. I note that the date on that web page is November 2003, although that is probably when it was last changed, not when your original comment was posted. This bug existed in version 1 of the schematic, and was fixed in version 2. Both have the same file date on my system of December 2002, which is probably due to some system restore. This was probably changed around September 2002. By the way, the schematic for the EasyProg being sold is version 7 from July 2004. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

> > >OK, so that wasn't the one. It's morning again, and I'm not in the same >office as my notes on this, but I definitely remember running into a problem >like this a few years back. The bulk erase didn't work right, and after >some trial and error I discovered that a different value had to be written >somewhere than specified in the programming spec. At the time I mentioned >it to someone at Microchip, and they reacted like "Yeah, we know about >that". I therefore concluded the issue was "well known". This was only one >of several errors or misleading information in the programming specs. The 16C84 dataEE erase was wrong (missing begin programming command) and the 16F84 code protection bits "mask" value was wrong. They are two that come to mind. > > Are you getting this? > >Geesh, no need to get peeved. I was reporting what I believed to be the >case. I wasn't trying to piss off you or anyone else. Ok, I did get pissed off. A lot of work and experience went into this investigation. Your reply made it look like it was a wasted effort and everybody knew already. I spend at least 30 hours (unpaid) and then gave away my findings to all my competitors. Good reason to get peeved but I'm over it now. {Quote hidden}> > After all, I still > > have a schematic of one of your earlier easyprog > > revisions. You know, the one where you implemented only a single VDD > > channel and wired it to pin-36 of the > > programming socket, and after all that had been said by me, BAJ and > > others on this issue over the years. See: > > > <http://www.piclist.com/techref/microchip/16F877/hvprog.htm>http://www.piclist.com/techref/microchip/16F877/hvprog.htm > >Wow, that brings back some old history! I had to go digging thru old >schematics to see what you were talking about. I had never seen that web >page before, but I do remember discovering the problem for myself sometime >around August 2002. I note that the date on that web page is November 2003, >although that is probably when it was last changed, not when your original >comment was posted. 1999 I first raised the issue. It has been raised over and over since. Have a look at this thread from June 2002. Not quite to with pin-36 but the same issue none the less. http://www.piclist.com/techref/postbot.asp?by=thread&id=%5BPIC%5D%3A++Programming+the+16F627+with+warp%2D13%2E&tgt=browse See, you were there. Notice your "helpful" contribution? I did. ;-) Regards, Jim

Jim Robertson wrote: > The 16C84 dataEE erase was wrong (missing begin programming command) > and the 16F84 code protection bits "mask" value was wrong. They are two > that come to mind. That wasn't any of the ones I found since I never implemented algorithms for those chips. I finally remembered to look for my notes and only found one such issue written down. In the PIC16F62x programming spec, DS30034D, page 12, Section 3.3 Disabling Code Protection, Step 1. It says to issue a Load Configuration command with a data word of 0. My notes say that this is wrong and that the data word really needs to be 3FFFh. This isn't exactly the symptom you described, but I would be suspicious of any data word not being 3FFFh on any erase on PIC 16 parts. > A lot of work and experience went into this > investigation. Your reply made it look like it was > a wasted effort and everybody knew already. I spend at least 30 hours > (unpaid) and then gave away my > findings to all my competitors. So don't do that then. If you give out hard won information publicly, you have to expect competitors might make use of it, or even hear that others already knew about it or at least aren't too surprised by it. On the other hand, you get to look like the expert. Only you can judge these tradeoffs. Nobody is forcing you either way. In any case, you live with the consequences, both good and bad. Getting upset about the bad ones is pointless. I've chosen to make all my host software and the complete EasyProg design including firmware public while not disclosing the ProProg design and firmware. The host software and EasyProg firmware has already been used with competitor's hardware, but I don't have a problem with that. I knew this was a possbility when I released it, and shouldn't have done so if I didn't want that to happen. I actually view it as a good thing, since in the long run I think I will derive benefit from it. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com