gnupic: Re: [gnupic] xwisp2 1.7.01 released
Subject:
RE: [gnupic] xwisp2 1.7.01 released
From:
Chen Xiao Fan ####@####.####
Date:
20 Sep 2005 08:58:29 +0100
Message-Id: <3B8AEFFADD3DD4118F8100508BACEC2C0A289222@spex>
Yes I understand the your concern and next time I will
use the "go" command.
In this special case, there seems to be some different preference of
how the verify command should do.
12F629/675 Configuration bits
BG1 BG0 | U0 U0 U0 /CPD | /CP BODEN MCLRE /PWRTE | WDTE FOCS2 FOSC1 FOSC0
(U0 stands for un-implemented and will be read as zero).
The hex file gives the configuration of 3F8C since it did not know
the bandgap caliberation bits (BG1 BG0) and it will leave the umplemened
bits (read o) unprogrammed. The readout is 118C since the bandgap
caliberation
is 1000. I would not think that the hex file is wrong. The bandgap should
be preserved and this should be taken care of by the programming command.
For the "go" command, the bandgap bits (BG1 BG0) and the OSCCAL value
should be read out first and then write back for the programming part
and then verify again. A seperate command can be implemented to
erase the bandgap bits and the OSCCAL value. It would be even better
to implement one more command to regenerate the OSCCAL value for
MCUs like 12F629/675.
The verify command itself can not verify that if the bandgap is correct or
not. Therefore it should mask this. Again the three implemented bits
will be read as 0 and the verify command should ignore this difference IMHO.
From: xwisp2.cfg
PIC = 12F629
Algorithm = PIC16C
DeviceID = 0F80
ProgSize = 2048
DataSize = 128
ProtectMask = 01A0 --> why 10A0? should be 0180, right?
--> why mask the MCLRE bit?
Delay = 50
FuseFixedZero = 31FF --> mask the U0 U0 U0, they will be read as
o.
FuseFixedOne = 3000 --> mask the bandgap bits for verification
Preserve = 400E,3000 ; bandgap bits
Preserve = 07FE,3FFF ; whole OSCCAL word
From Microchip PICkit 1 VB application:
Public Sub LookupDevice()
If ((DevId And &H3FE0) = &HF80) Then
DeviceName = "PIC12F629"
DevicePgmSize = 1024
DeviceEESize = 128
DeviceTestSize = 64
DeviceSaveOscCal = True
DeviceSaveBGBits = True
DeviceBandGapMask = &H3000 --> mask the BG1 | BG0
DeviceCPMask = &H180 --> mask the /CPD | /CP
DeviceConfigMask = &H1FF --> mask the BG1 BG0 U0 U0 U0
DevicePgmMode = ByOne
ProgCon.mnuWriteOscCal.Enabled = True
ProgCon.mnuBandGapDefault.Enabled = True
ProgCon.Label4.Enabled = True
ProgCon.Label5.Enabled = True
ProgCon.lblOscCal.Enabled = True
ProgCon.lblBandGap.Enabled = True
Regards,
Xiaofan
-----Original Message-----
From: Rob Hamerling
Sent: Tuesday, September 20, 2005 3:18 PM
To: ####@####.####
Subject: Re: [gnupic] xwisp2 1.7.01 released
Hi Xiaofan,
Xiaofan Chen wrote:
> Still the verification caused false alarm.
To my opinion this is not a false alarm!
With 'verify' the contents of target memory and hex file are compared
and differences should be reported. In your case there is a difference
in the config word, and xwisp2 signals this rightly!
Now you have to find out which of both values is wrong. According to the
datasheet some bits of the config word are not used and read back as 0,
but your hex file specifies these bits as 1. So obviously your hex file
is in error.
I have introduced fusefixedzero and fusefixedone masks to adjust the
config word bits with the 'write' operation to *suppress* the verify
alarm with the write-verify operation (implied in the most popular
command: 'go'). This is done for the convenience of the 'simple' user (I
myself use practically only the 'go' command!)
The choice for a change in xwisp2 is:
1. disable suppress of the error report with write-verify
2. enable suppress of the error report with verify
To my opinion: when chosing for the second option 'verify' is crippled:
you will not find errors in the config word specification of your
program (either caused by yourself or by the compiler you are using).
Regards, Rob.
