gnupic: Re: [gnupic] Xwisp2 1.7.2 released
Subject:
RE: [gnupic] Xwisp2 1.7.2 released
From:
Chen Xiao Fan ####@####.####
Date:
28 Sep 2005 02:55:08 +0100
Message-Id: <3B8AEFFADD3DD4118F8100508BACEC2C0A28927C@spex>
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: ####@####.####
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.
