I am using an 18F452, and am a novice, so please forgive me if I am being
stupid.
I used to use __CONFIG commands for setting config bits, and put up with the
resultant warnings. However, I just decided to try the newer CONFIG
commands. My programmer now tells me I have a FUSE error in my HEX file.
I used MPLAB IDE V7.30 "configure/configuration bits" command to look at
what the bits had been set to. They are different, and maybe I'm missing
something, but for the life of me I can't undertand why. To expand on this:
Looking at the PIC18FXX2 manual, the value FE makes no sense to me. And yet
my programmer programs this OK, and the program runs OK - correct oscillator
speed, too.
Phil Cross wrote:
> I am using an 18F452, and am a novice, so please forgive me if I am being
> stupid.
>
> I used to use __CONFIG commands for setting config bits, and put up with the
> resultant warnings. However, I just decided to try the newer CONFIG
> commands. My programmer now tells me I have a FUSE error in my HEX file.
>
> I used MPLAB IDE V7.30 "configure/configuration bits" command to look at
> what the bits had been set to. They are different, and maybe I'm missing
> something, but for the life of me I can't undertand why. To expand on this:
>
Did you look at the P18F452.INC file (on my system, located at
c:\Program Files\Microchip\MPASM Suite\)? That has all the CONFIG
options. Perhaps that might give you a clue. (I still use the old
__CONFIG commands myself, so am not familiar with the new options -- but
starting with the include file would be what I would do).
> I am using an 18F452, and am a novice, so please forgive me if I am being
> stupid.
>
> I used to use __CONFIG commands for setting config bits, and put up with the
> resultant warnings. However, I just decided to try the newer CONFIG
> commands. My programmer now tells me I have a FUSE error in my HEX file.
>
> I used MPLAB IDE V7.30 "configure/configuration bits" command to look at
> what the bits had been set to. They are different, and maybe I'm missing
> something, but for the life of me I can't undertand why. To expand on this:
>
> OLD:
> __CONFIG _CONFIG1H, _OSCS_OFF_1H & _HSPLL_OSC_1H
> "configure/configuration bits" shows:
> 30001 FE Oscillator HS-PLL Enabled
> Osc, switch enable Disabled
>
> Looking at the PIC18FXX2 manual, the value FE makes no sense to me. And yet
> my programmer programs this OK, and the program runs OK - correct oscillator
> speed, too.
>
> NEW:
> CONFIG OSC =HSPLL ; Use HS PLL osc.
> CONFIG OSCS=OFF ; Disable osc. switching.
> "configure/configuration bits" shows:
> 30001 26 Oscillator HS-PLL Enabled
> Osc, switch enable Disabled
>
> Looking at the PIC18FXX2 manual, the value 26 looks correct. However, my
> programmer tells me I have a FUSE error, and won't program my chip.
>
> All the other values are wildly different too - I just chose the first one
> as an example.
>
> Please could someone enlighten me? I would be very grateful.
>
> Regards,
> Phil Cross
>
>
>
> From: .....piclist-bouncesKILLspam@spam@mit.edu
> [piclist-bouncesKILLspammit.edu] On Behalf Of Jan-Erik Soderholm
> Sent: Sunday, February 05, 2006 11:29 PM
>
> Phil Cross wrote :
>
> > NEW:
> > CONFIG OSC =HSPLL ; Use HS PLL osc.
> > CONFIG OSCS=OFF ; Disable osc. switching.
>
> Where are the rest ?
>
> *Always* specify *all* config options.
>
I think this is a good point for 18F. Unfortunately,
Microchip provides many samples (with MPLAB C18)
without doing this.
For absolute mode assembly code and they even provide the
default values inside the final hex file for those config
options not specified at the source.
It is also worth to take note that MPASM/MPLINK allow the
config word to split across files in the relocatable mode.
In that case, it will not fill in the default values in the
final hex file. I can not think why one wants to put
configuration word though.
For MPLAB C18, it seems to me that it produces hex file
without filling the default configuration values (in
consisent with the relocatable mode assembly).
John Nall wrote:
>Did you look at the P18F452.INC file ?
Yes I did. It contains the values generateded by __CONFIG, but not by
CONFIG. I assume the latter are provided by the assembler.
Rolf wrote:
>Let me guess... your programmer is one of the DIY Kit 128/149/150/182
>types.
No, it isn't. It is a cheapo Quasar kit - but it gives me reliable (so far)
ICSP.
Tom Sefranek wrote:
>;******************************************************************************
>; Filename: F452Conf.inc Part of
>MCA.asm *
>*SNIP SNIP*
Yep - that looks pretty much like my CONFIG definitions.
Jan-Erik Soderholm wrote:
>Where are the rest ?
>
>*Always* specify *all* config options.
I did - my penultimate sentence was "All the other values are wildly
different too - I just chose the first one as an example".
******I now believe I understand what is happening:******
__CONFIG writes a '1' in unused bits.
CONFIG writes a '0' in unused bits.
Hence, with OSCS set to '1', and FOSC set to '110', the config word 300001h
becomes 'XX1XX110', where X are the unused bits.
__CONFIG replaces X by 1, therefore 300001h becomes '11111110' = FEh
CONFIG replaces X by 0, therefore 300001h becomes '00100110'=26h
and these are the values that the MPLAB "configure/configuration bits"
command shows me. Similarly with all the other configuration registers.
My cheapo programmer has what it calls a "chipinfo" file with the driver.
This specifies fuse settings, presumably for checking purposes (?), and
these are the old __CONFIG generated values. So it craps out with a FUSE
error.
>John Nall wrote:
>
>
>>Did you look at the P18F452.INC file ?
>>
>>
>
>Yes I did. It contains the values generateded by __CONFIG, but not by
>CONFIG. I assume the latter are provided by the assembler.
>
>Rolf wrote:
>
>
>>Let me guess... your programmer is one of the DIY Kit 128/149/150/182
>>types.
>>
>>
>
>No, it isn't. It is a cheapo Quasar kit - but it gives me reliable (so far)
>ICSP.
>
>
>
------------------snip-------------------
Phil,
As your programmer has a chipinfo file it is almost certainly one of the
DIY kits. Quasar markets them. if you look at http://www.kitsrus.com you will
almost certainly find your programmer and 'may' find some useful updates.
>My cheapo programmer has what it calls a "chipinfo" file
>with the driver. This specifies fuse settings, presumably
>for checking purposes (?), and these are the old __CONFIG
>generated values. So it craps out with a FUSE error.
So presumably you could add entries for the CONFIG version so you don't get
errors ?
Yes - but my point is that it doesn't specify the VALUES of LP, XT, etc, as
it does for the __CONFIG constants.
In any case, those statements are all commented - the assembly process won't
use them, will it? I assumed they were just for programmer reference. My
whole argument has been about the different VALUES of configuration bits
generated by CONFIG and __CONFIG, which seems to be down to CONFIG setting
unused bits to '0', but __CONFIG setting them to '1'.
> -----Original Message-----
> From: .....piclist-bouncesKILLspam.....mit.edu
> [EraseMEpiclist-bouncesspam_OUTTakeThisOuTmit.edu]On Behalf Of Phil Cross
>
> My whole argument has been about the different VALUES of
> configuration bits generated by CONFIG and __CONFIG,
> which seems to be down to CONFIG setting
> unused bits to '0', but __CONFIG setting them to '1'.
This is a valid question to Microchip and I do not
want to say that Microchip is always right with MPLAB.
In fact, MPASM 5.01 and MPLAB C18 V3.01 have fixed
some problems with CONFIG settings and there may still
be some errors.
There are quite some problems with the wrong CONFIG
options which break some codes (even the Microchip
examples). For example, PICKit 2 firmware will fail to
build with the V3.01 version of MPLAB C18 due to
the wrong config options used in the old version of
MPLAB C18.
MPLAB C18 v3.02 is just out. I have not checked it out.
You may want to check out the readme for V3.01 and V3.02.
Release Notes for MPLAB(R) C18, PICmicro(R) 18Cxx C Compiler
v3.01
18 November, 2005
...
(27358 / 27515) The #pragma config directive causes unimplemented bits
to become 0, but should be left a '1'.
Unimplemented/reserve bits are now included in the mask and
default settings when the bit must be maintained set.
...
Here is the readme file for MPASM V5.01 (comes with
MPLAB C18 V3.01)
Release Notes for MPASM(TM) Assembler version v5.01
18 November, 2005
...
-----------------------------------------------------------------
Repairs and Enhancements Made in v5.01
-----------------------------------------------------------------
Problems resolved:
(27358 / 27515) The new config directive causes unimplemented bits to
become 0, but should be left a '1'.
Unimplemented/reserve bits are now included in the mask and
default settings when the bit must be maintained set.
Following are the devices and configuration words that were
corrected:
...
>> Yes - but my point is that it doesn't specify the VALUES of
>> LP, XT, etc, as it does for the __CONFIG constants.
>>
Does someone have a macro or macros to wrap around the microchip
"__config" directive that will enforce having the user set an
explicit value for every settable bit?
Jan-Erik Soderholm wrote:
>Why do you need those "values" ?
>I'm sorry if I missed something from the start of the thread.
Well, yes - I think you did. I started the thread because use of CONFIG
instead of __CONFIG caused my programmer to throw a FUSE error. It turned
out to be because my programmer driver checks the fuse values against values
in a "chipinfo.cid" file, and the values it checks them against are those
generated by __CONFIG. And to repeat myself, this is because __CONFIG fills
unused bits with '1's, but CONFIG fills them with '0's.
I agree with what you say in general - it is just that I have a cheapo
crappo programmer, which for some reason demands that FUSE values be of the
old __CONFIG type.
Now I understand, and can deal with the problem, the discussion has
satisfied my needs, and I won't go on about it :)
> It turned out to be because my programmer driver checks the
> fuse values against values in a "chipinfo.cid" file, and the values
> it checks them against are those generated by __CONFIG. And
> to repeat myself, this is because __CONFIG fills unused bits
> with '1's, but CONFIG fills them with '0's.
Ah, yes !
I get it. :-)
And with "unused bits" you mean the bits in the config words
that has no config function (in the processor), not the bits that
aren't specificaly set by the __CONFIG (or CONFIG) directives,
right ?
Yes, that's makes sense. I had a similar problem where what
was read back from the "unused" bits in i config words did
not match what was in the HEX file. That broke the verify.
In that case (this was while using __CONFIG) each config
word was adjusted with an extra "& ..." to set the unused
bits in the HEX file to match whatever was read back from
the processor. A later version of the software simply
stripped off the unused bits before doing the verify, so they
could be set to anything in the HEX file.
That also explains why I saw no direct need to know
the "values" each CONFIG parameter had, since the
unused bits are clearly documented in the datasheet
anyway.
ARRL.net
