Rob Hamerling wrote:
> XWisp2 assumes that all words which are not addressed in the hex file
> are erased in the target. Verify of program memory is performed by
> Xwisp2 in blocks of 4 words from begin to end. Blocks with all words
> 0x3FFF are not read back from the target, thus not really verified
> (even blocks which are explicitly set in the hex file to all 0x3FFF).

That explains the very fast times for the xxx_empty HEX file.  However, I
think this is not a good idea.  Wouter's method of verifying whatever
locations were specified in the HEX file is more reasonable.  If a address
is listed in the HEX file, then I think the software must assume that the
value there is significant, whether it happens to be the erased value or
not.  While a bunch of successive ADDLW h'FF' instructions aren't likely,
successive values of 3FFFh could be valid table entries.  Verification is
just as much to catch erase failures as it is to catch write failures.  In
fact the few times I've seen genuine verification failures, I seem to
remember that most of them were 0s that should have been 1s.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist