gnupic: Re: [gnupic] xwisp2 1.7.01 released
Subject:
Re: [gnupic] xwisp2 1.7.01 released
From:
Rob Hamerling ####@####.####
Date:
20 Sep 2005 10:08:45 +0100
Message-Id: <432FD196.1000701@hccnet.nl>
Hi Xiaofan,
Chen Xiao Fan wrote:
> 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.
I didn't realize it was about a 12F629. I agree fully about the
handling of the bandgap bits, and I also realise this torpedoes my
reasoning w.r.t. verify!
But I would say the U0 bits should be set to 0 in the hexfile.
> 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.
Bandgap bits and OSCCAL are preserved by XWisp2. You can check with the
'log' command.
There was a time that XWisp2 had an Osccal command to reconstruct the
OSCCAL word, but not anymore. OSCCAL and bandgap bits can be restored by
not preserving 'm (remove the appropriate 'preserve' lines from
xwisp2.cfg and adding the appropriate settings to the hex file). Agreed,
this is not very convenient, but one should think twice (and xwisp2
forces you!) before overriding preserved locations.
Please read the 'changes.txt' for the history of OSCCAL handling.
> 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.
OK, I think this can be fixed for the next release.
> 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?
Indeed questionable! Was introduced when I learned about the
Vpp-before-Vdd issue, but insights change.... I think I'll remove it
from xwisp2.cfg.
Thanks for sharing your insight!
Regards, Rob.
--
Rob Hamerling, Vianen, NL phone +31-347-322822
homepage: http://www.robh.nl/
