Is Hi-Tech P18 compiler 9.80 more buggy than 9.63? - Page 1
Forum section: electronics / general

author: Paul Price
author_rank: Super Contributor
timestamp: June 06, 2015, 01:29:30 am
content: 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:020001002500FDor02 number of bytes in payload0001 Start Address of Payload Bytes 0x 30 0000 000100 Ordinary Data Record25 Byte at 0001 corresponding to 0x 30 0000 0001 location of CONFIG1H00 is byte at Address 0x 30 0000 0002 and is the location of the WDT and other bits, not requested to be set!FD Checksumwhich properly shows CONFIG1H=0x25 CONFIG1L=00 (not implemented), but WDT settings would be changed!Does Version 9.63 have this same problem?

author: Paul Price
author_rank: Super Contributor
timestamp: June 06, 2015, 01:43:52 am
content: 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:04000100251F3F0078or04 number of bytes in payload0001 Start Address of Payload Bytes 0x 30 0000 000100 Ordinary Data Record25 Byte at 0001 corresponding to 0x 30 0000 0001 location of CONFIG1H1F is byte at Address 0x 30 0000 0002 and is the location of the WDT CONFIG2L3F other WDT settings correct 0X 30 0000 0003 WDT CONFIG2H00 would be the byte at 0x 30 0000 0004 for the CONFIG3L (not implemented) but not set for changewhich 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::06000100251F3F00BF8532or06 number of bytes in payload0001 Start Address of Payload Bytes 0x 30 0000 000100 Ordinary Data Record25 Byte at 0001 corresponding to 0x 30 0000 0001 location of CONFIG1H1F is byte at Address 0x 30 0000 0002 and is the location of the WDT CONFIG2L3F other WDT settings correct 0X 30 0000 0003 WDT CONFIG2H00 would be the byte at 0x 30 0000 0004 for CONFIG3L correctBF 0005 CONFIG3H correct85 0x 30 0000 0006 CONFIG4L (What if this value was required to be 0?)32 CheksumHow 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?

author: Paul Price
author_rank: Super Contributor
timestamp: June 06, 2015, 02:16:52 am
content: 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::06000100251F3F00BF853206 number of bytes in payload0001 Start Address of Payload Bytes 0x 30 0000 000100 Ordinary Data Record25 Byte at 0001 corresponding to 0x 30 0000 0001 location of CONFIG1H1F is byte at Address 0x 30 0000 0002 and is the location of the WDT CONFIG2L3F other WDT settings correct 0X 30 0000 0003 WDT CONFIG2H00 would be the byte at 0x 30 0000 0004 for the CONFIG3L (not implemented) and set for changeBF 0x 30 0000 0005 for the CONFIG3H set for change85 0x 30 0000 0006 for the CONFIG4L and correct value but hi-byte missing32 CheckSum(Next Intel Hex Record):060008000FC00FE00F40E506 number of bytes payload0008 Start Address of Payload Bytes 0x 30 0000 000800 Ordinary Data Record0F Byte at 0004 corresponding to 0x 30 0000 0008 location of CONFIG5LC0 is byte at Address 0x 30 0000 0009 location of CONFIG5H0F settings correct 0X 30 0000 000A CONFIG6LE0 would be the byte at 0x 30 0000 000B for CONFIG6H0F 0x 30 0000 000C for CONFIG7L set for change40 0x 30 0000 000D for CONFIG7H and correct valueE5 CheckSumEverything's correct with this recordBut 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?

author: Ian.M
author_rank: Super Contributor
timestamp: June 06, 2015, 03:05:30 am
content: 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.

author: mikerj
author_rank: Super Contributor
timestamp: June 06, 2015, 10:20:28 am
content: It always helps toRTFMAlso covered inthis thread.In summary, don't use magic numbers in the fuse configuration. Instead use the macros provided by HiTech.

author: Paul Price
author_rank: Super Contributor
timestamp: June 07, 2015, 12:50:52 pm
content: 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?

author: Ian.M
author_rank: Super Contributor
timestamp: June 07, 2015, 01:02:15 pm
content: two minutes with google:http://ww1.microchip.com/downloads/en/DeviceDoc/PICC_18_9_80_readme.pdfHowever 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?

author: Paul Price
author_rank: Super Contributor
timestamp: June 07, 2015, 03:55:46 pm
content: 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.

author: Paul Price
author_rank: Super Contributor
timestamp: June 07, 2015, 04:05:16 pm
content: 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

author: Ian.M
author_rank: Super Contributor
timestamp: June 07, 2015, 04:28:26 pm
content: 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?