Is Hi-Tech P18 compiler 9.80 more buggy than 9.63?

[Paul Price]

When I attempt to set configuration words with Ver. 9.80 I get unexpected results for setting CONFIG1 bits.

For example, in my source code:
__PROG_CONFIG(1,0x2500);
__PROG_CONFIG(7,0x400F);
The correctly compiled Intel Hex file  results reveals:
020001002500FD
or
02 number of bytes in payload
    0001  Start Address of Payload Bytes 0x 30 0000 0001
            00  Ordinary Data Record
                25   Byte at 0001 corresponding to 0x 30 0000 0001 location of CONFIG1H
                    00  is byte at Address 0x 30 0000 0002 and is the location of the WDT and other bits,  not requested to be set!
                        FD  Checksum
which properly shows CONFIG1H=0x25 CONFIG1L=00 (not implemented), but WDT settings would be changed!

Does Version 9.63 have this same problem?

[Paul Price]

For example, in my source code:
__PROG_CONFIG(1,0x2500);
__PEOG_CONFIG(2,0x3F1F);
__PROG_CONFIG(7,0x400F);
The correctly compiled Intel Hex file  results reveals:
04000100251F3F0078
or
04 number of bytes in payload
    0001  Start Address of Payload Bytes 0x 30 0000 0001
            00  Ordinary Data Record
                25   Byte at 0001 corresponding to      0x 30 0000 0001 location of CONFIG1H
                    1F  is byte at Address                       0x 30 0000 0002 and is the location of the WDT  CONFIG2L
                        3F  other WDT settings correct     0X 30 0000 0003  WDT CONFIG2H     
                            00 would be the byte at           0x 30 0000 0004 for the CONFIG3L (not implemented) but not set for change
which properly shows CONFIG1H=0x25 CONFIG1L=00 (not implemented)but what is the trailing 00 indicating?

or else to include the next CONFIG bits:
For example, in my source code:
__PROG_CONFIG(1,0x2500);
__PEOG_CONFIG(2,0x3F1F);
__PROG_CONFIG(7,0x400F);
The correctly compiled Intel Hex file  results reveals:
:06000100251F3F00BF8532
or
06 number of bytes in payload
    0001  Start Address of Payload Bytes 0x 30 0000 0001
            00  Ordinary Data Record
                25   Byte at 0001 corresponding to      0x 30 0000 0001 location of CONFIG1H
                    1F  is byte at Address                       0x 30 0000 0002 and is the location of the WDT  CONFIG2L
                        3F  other WDT settings correct     0X 30 0000 0003  WDT CONFIG2H     
                           00 would be the byte at            0x 30 0000 0004 for CONFIG3L correct
                                BF                                                            0005      CONFIG3H correct
                                   85                                      0x 30 0000 0006      CONFIG4L (What if this value was required to be 0?)
                                        32 Cheksum
 How would a programmer know if the 0x85 was 00, would the burning program know it was to erase the default 0x85?
Does Version 9.63 have this same problem?

[Paul Price]

But, if in my source code all the CONFIG words 1 to 7 are given values to be configured:
__PROG_CONFIG(1,0x2500);
__PROG_CONFIG(2,0x3F1F);
__PROG_CONFIG(3,0xBF00);
__PROG_CONFIG(4,0x85);
__PROG_CONFIG(5,0xC00F);
__PROG_CONFIG(6,0xE00F);
__PROG_CONFIG(7,0x400F);

The correctly compiled Intel Hex file  results reveals:
:06000100251F3F00BF8532
06 number of bytes in payload
    0001  Start Address of Payload Bytes 0x 30 0000 0001
            00  Ordinary Data Record
                25   Byte at 0001 corresponding to      0x 30 0000 0001 location of CONFIG1H
                    1F  is byte at Address                       0x 30 0000 0002 and is the location of the WDT  CONFIG2L
                        3F  other WDT settings correct     0X 30 0000 0003  WDT CONFIG2H     
                            00 would be the byte at           0x 30 0000 0004 for the CONFIG3L (not implemented) and set for change
                                BF                                         0x 30 0000 0005 for the CONFIG3H set for change
                                   85                                      0x 30 0000 0006 for the CONFIG4L  and correct  value but hi-byte missing
                                       32    CheckSum
                                                                       (Next Intel Hex Record)
:060008000FC00FE00F40E5
06 number of bytes payload 
   0008  Start Address of Payload Bytes 0x 30 0000 0008
             00  Ordinary Data Record
                 0F   Byte at 0004 corresponding to      0x 30 0000 0008 location of CONFIG5L
                    C0  is byte at Address                       0x 30 0000 0009 location of CONFIG5H
                        0F                    settings correct     0X 30 0000 000A                  CONFIG6L   
                            E0 would be the byte at            0x 30 0000 000B for            CONFIG6H
                                0F                                          0x 30 0000 000C for            CONFIG7L set for change
                                   40                                       0x 30 0000 000D for            CONFIG7H  and correct  value
                                        E5    CheckSum
Everything's correct with this record

But are these records in the correct syntax, in the way these Intel8 Hex records should be correctly represented?
Is it that all the CONFIG bits must be configured for correct results?

[Ian.M]

You are likely to find more people familiar with the older HiTech compilers over on the Microchip Technology forums.  Microchip bought HiTech lock stock and barrel, and some of the original HiTech development team are members of the current XC8 team and are active on the Microchip forums.

I expect you'd get an answer here eventually, but its likely to take a while.

I would comment that most serious coders on Microchip PICs prefer to use the symbolic names for the CONFIG bit options and let the compiler sort them out rather than trying to set them in hex with a 'magic number'.   Also if you are asking about the effects of device specific stuff like this, it is ESSENTIAL to state exactly which PIC you are using.

[mikerj]

It always helps to RTFM

Also covered in this thread.

In summary, don't use magic numbers in the fuse configuration.  Instead use the macros provided by HiTech.

[Paul Price]

Thanks Mikerj,

This is very good advice, I read the errata for ver 9.63.

I searched the Microship website for an errata  for the 9.80 P18 compiler but couldn't find one.

Wpi;ld anyone please download the errata for the PIC18 9.80?

[Ian.M]

two minutes with google:
http://ww1.microchip.com/downloads/en/DeviceDoc/PICC_18_9_80_readme.pdf

However all the manuals, readme etc. should have been put in the compiler's doc folder by its installer, so why not simply go there and RTFM?

[Paul Price]

Thanks Ian.M for your help.

I always assumed that if there is an bug list, that getting the latest edition of it would be the most informative, up to date and comprehensive, and this means that the document shipped with the compiler is obviously out of date with the latest bugs discovered years after it has been installed, so the web is the only place to look for it.

I didn't think using the same doc name to google it would find what I am looking for.

[Paul Price]

I also noticed in another post using MPLAB that the CONFIG bit code is very clear:
:0A7FF6000000000000000000000081
:020000040020DA
:08000000FFFFFFFFFFFFFFFF00
:020000040030CA
:0E00000000255F3FFFD3A5FF0FC00FE00F40AC //this is CONFIG info quite easy to understand by any prom burning program.
:00000001FF

[Ian.M]

If you want to know what issues have been exposed, as Microchip don't run a public bugtracker, all you can do is look at the release notes for a later version.   I believe PICC18 v9.80 was the last release, but XC8 was developed from it and early releases certainly reported PICC/PICC18 bugs that had been resolved.

However why not simply use XC8 which you can get current support for?