A Little Perplexed About Being Mis-Hexed

[SuzyC]

I am compiling C-Code for the PIC 18F25K22 and trying to set configuration bits.
According to the Hi-Tech 18 compiler Ver 9.63, and according to their manual, the configuration bits can be set for the 7 config words used with this chip with the simple __CONFIG(Confign,x) where n identifies the configuration word and x is the 16-bit configuration payload.
However, when I compile code and look a the resulting InteL Format Hex File, the results are inconsistent with the values set by code. The compiler command line .bat file   clearly identifies the chip with --CHIP=18F25X22 and the results shows there are no compiler errors or any warnings at all relating to configuration words.

Not all 16-bits of the configuration word bit fileds are used in each configuration word, and unused bits are read as 0's according to the PIC18F2xF22 datasheet.

However, the values that I see in the Intel Hex File to program the chip are astonishingly different that one would expect.

For example:

#include <htc.h>
#include <string.h>
#include <stdio.h>
#include <math.h>
#include <P18F25K22.h>

__CONFIG(1,0xDFFF);
__CONFIG(2,0xFF00);
__CONFIG(3,0xFF00);
__CONFIG(4,0xFF00);
__CONFIG(5,0xFFFF);
__CONFIG(6,0xFFFF);
__CONFIG(7,0xFFFF);


.................................................
and then a dump of the hex file show this result: (These are the last three lines of the Hex File, CONFIG words info)

:020000040030CA //Following  bytes will be burned at extended linear address. Configuration Word start address
:0E000000FF05E03F00BF7AFF0FC00FE00F408A //configuration words 1 to 7 record
:00000001FF    //end of file

The middle line can be parsed to show the individual values more clearly:
:0E 0000 00 FF05 E03F 00BF 7AFF 0FC0 0FE0 0F40 8A


The middle line is in the following Intel Hex format:

:OE------------------number of data bytes payload
     0000------------address offset from 0x30000 where configuration bytes reside
             00---------Indicates the following bytes are consecutive data (these are the configuration reg words)
                 FF05---Configuration Word 1 hex value to burn
                 E03F---Configuration Word 2
                 008F---                                3
                 7AFF---                                4
                 0FC0--                                 5
                 0FE0--                                 6
                 0F40--Configuration Word   7
                         --8A---Two's Complement ChkSum for this record.

:0E 0000 00 FF05 E03F 00BF 7AFF 0FC0 0FE0 0F40 8A


Huh???


 

[dannyf]

Huh???

They provided configuration word macros for you to use.

[sunnyhighway]

Huh???

Hint: Little Endian (Little End first)

[SuzyC]

Thanks dannyf, but I used the __CONFIG(n,x) macros to get these unexpected results?

Thanks sunnyhighway, but little or big endean, the results are not making any sense to me in the .hex file.

I seem to think I am doing everything right to get everything so wrong.

[android]

What happens when you use the configuration bit names instead of literal values? For example (shamelessly stolen from the interweb...not actually your config bits):

Code: [Select]

__CONFIG(1, FCMDIS & IESODIS & XT);
__CONFIG(2, BORDIS & BORV45 & PWRTEN & WDTDIS & WDTPS1);
__CONFIG(3, CCP2RB3 & LPT1DIS & MCLRDIS); // & 0xFDFF);
__CONFIG(4, DEBUGDIS & XINSTDIS & LVPDIS & STVRDIS);It's probably better in the long run to do it that way anyway (easier to read)

[mikerj]

Thanks dannyf, but I used the __CONFIG(n,x) macros to get these unexpected results?

Danny means that you should use the predefined fuse names instead of a "magic number" like 0xDFFF.  The compiler release notes are clear on this:

__CONFIG macro function (9.63PL3)
The way in which the configuration words are programmed
by the compiler has changed. A consequence of this is using this macro function to program a
literal value in a configuration word may produce unexpected results. Only the configuration
setting macros provided in the device specific header files should be used with this function.

You are using a literal value, and getting unexpected results...

The format is just as android has shown, the fuse names are defined in the PICC18 device header file, but are mostly the same or very similar to the names used in the datasheet.

[SuzyC]

Aha!

Silly me..didn't read the newest errata!

16-bit Hex literals are literally not allowed.

Thanks to all, I just needed to use this form of setting config bytes with the correct fuse names=values

#pragma config

Now I am hexing it up!

Solved!

[dannyf]

If you put the typpical config word settings in a file, grouped with conditional compilation directives, you can simply include it in your future projects - no need to look them up each time.

I have those config files, about 50KB for my PIC24s and 100KB for PIC12/16/18s. It saves lots of time.

[22swg]

Good to see you back in PICworld...