Xwisp2 users,

Follow-up of a conversation of about half a year ago...

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

Olin Lathrop wrote:

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

I finally took some time to improve the verify behaviour of Xwisp2. In
version 1.9.0, released today, I introduced the 'full' command option.
When specified all memory locations are verified, also the locations not
in the hex file.  It may not be very 'intelligent', but it ensures the
target contains the full (and nothing but the) contents of the hex file.

Xwisp2 can be found at http://www.robh.nl/ (pointer in left margin).

Regards, Rob.



-- 
Rob Hamerling, Vianen, NL (http://www.robh.nl/)
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist