RE: Xwisp2 1.7.2 released

You are right that the two hex files have almost the same 
content. One of them has no EEPROM and empty user id. I've
write the PIC with the one with EEPROM and user id. So this
behavior is tally with what you described and it is not
a bug. I agree with you that there is no real problem if 
"go" command is always used to write a new hex file 
(erase first and then write).

I discovered this when I was testing Mark's python_pickit
(or pyk) for PICKit 2. I programmed the PIC using pyk and
use Wisp628A/xwisp2 to verify the PICs under Linux.

So my suggestion is to have another "verifyall" command 
to verify all regions and keep "verify" the same as before.
Sine "go" command also performs verification, normally
"verify" command is not necessary.

Then I have another question, "write" does not erase the
chip first. So it also only write those in the hex file 
without erasing the existing memory content, right?

Regards,
Xiaofan


-----Original Message-----
From: Rob Hamerling
Sent: Wednesday, September 28, 2005 3:20 AM
To: [email protected]
Subject: Re: [gnupic] Xwisp2 1.7.2 released

I could not reproduce this behaviour. When I do a verify with a hex file 
with different contents I get a verify error report.

Your report is somewhat incomplete: did you verify with really different 
contents or did you verify with a hexfile with no ID or data memory?

The Verify function in Xwisp2 compares if memory in the target PIC 
matches the contents of the hex file. The compare is restricted to the 
range of addresses which are 'covered' by the hex file. So positions in 
memory which are not addressed in the hex file are not compared (with 
some minor excpetions). To my opinion this is OK for normal practice 
when you erase a PIC before loading a new program.

An alternative would be to read all memory regions completely and check 
if the areas not addressed in the hex file are blank. This is time 
consuming and the question is if it is an error when these areas are not 
blank.  Maybe the program writes to other memory areas or even to areas 
addressed in the hex file before you do a verify!

When you have a different view of the required verify process, feel free..

Regards, Rob.