Actually I believe it IS the part. I've also tested a Theory and drawn a Conclusion and a work-around... so stick with this till the end...

I've now got 10 pieces of 16F676 with Batch 0340044.

I also have had several verify errors when programming then verifying or just reading back. This in itself is strange (all will be explained why later)...

If I program the EEPROM manually (not using the PBP Compiler but using the editing functions of my EEPROM programmer into a BLANK - erased - PIC) as so for the 1st 32 Memory locations...

00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

and I just read it back... the 2nd line (addresses $10 thru $1F) which should be all FF's come back as expected.

Now, creating a PBP program so...

'
' EEPROM Preset Data
' ------------------
Data @0,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
'
' Variable Defines
' ----------------
CounterA var Byte
MyByte var Byte
'
' Actual Program Start
' --------------------
Start:
For CounterA=0 to 15
Read CounterA,MyByte
MyByte=MyByte+16
Write CounterA+16,MyByte
Next CounterA
Loop:
Pause 1000
Goto Loop

End

Programming an erased PIC and just simply reading it back, I already find EEPROM corrupted expecting to find addresses $10 thru $1F as all $FF, instead I find addresses $10 with contents $10 and address $11 with contents $11 - as if my program has been ruuning for a few moments - but no, all I have done is programmed the PIC and read it straight back...

Now running the above program, and reading it back, you would expect addresses $10 thru $1F to contain...

10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F

instead they contain...

10 11 FF 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F

You will notice that address $12 is corrupt and not containing the expected data.

THEORY
======

It's almost as if the PIC has momentarily started to run for a few milliseconds whilst in the programmer, and being powered by the programmer before the programmer starts executing it's Read or Verify cycle.

Looking at the Datsheet I notice this is one of the new family of devices that really consumes micoamps, so to test the theory I've changed my test program...

'
' EEPROM Preset Data
' ------------------
Data @0,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
'
' Variable Defines
' ----------------
CounterA var Byte
MyByte var Byte
'
' Actual Program Start
' --------------------
Start:
Pause 2000
For CounterA=0 to 15
Read CounterA,MyByte
MyByte=MyByte+16
Write CounterA+16,MyByte
Next CounterA
Loop:
Pause 1000
Goto Loop

End

Notice I've put a BIG 2 second power-on delay before I start reading/writing to EEPROM...

Programming the PIC and immediately reading it back, whereas previously memory locations $10 and $11 (and sometimes $12) were corrupted, they are now $FF as they should be...

Running the program and then reading back the EEPROM contents the whole bank of $10 thru to $1F (including address $12) again is what it should be.

I've repeated this with all ten PIC's and have consistantly confirmed the EEPROM errors without the Pause, and no errors with the Pause.

CONCLUSION
=========

This PIC starts to run your program momentarily during the VERIFY or READ cycle of your programmer. That's where sometimes the VERIFY failed after the PIC's been programmed - the expected EEPROM contents had already changed!! Since I get two EEPROM locations written to (at 10mS each I believe) and a third is corrupted, this means that in my programmer at least this PIC is executing some 30mS worth of code.

Work-around... this PIC needs a Power-On delay at the start of your code BEFORE you do anything else... Pause 500 should suffice (probably overkill and Pause 100 would do it)... otherwise your brand-new programmed PIC that you've just taken out of your programmer may have actually already started executing your code adversely - so you put it in your board and it doesn't behave the way you expect with all kinds of internals corrupted by those few milliseconds of unexpected operation.

You don't expect PICs to start executing their code whilst sitting in your programmer so this is a real new one on me. Thanks to you Joe we've all learned something here - we should really stop being surprised at getting curve-balls thrown at us with these new PIC's.

What shall we call this for posterity... the "Joe effect" or the "Melanie effect"?

Melanie