PCHL vs PCWH Fuse Bits

[ednspace]

I am having an interesting problem, where by I compile a simple code set under windows compiler and everything works as expected, compile the same code under linux and the micro wont start up. It seems to be a fuse bit problem. I can extract the configuration words from both trials and they are different. I can compile under linux and then force program the config bits extracted from windows and the program then runs fine. It acts like and MCLR problem however that config bit appears to be identical on windows and linux.

PIC = 18F2455 20mHz crystal
Linux PCML version = PCH compiler version 4.049;8/6/2007
Windows PCWH version = 4.038

Lin Win
0C24 0C24
1E39 1E39
0300 0300
0000 0080 (DEBUG Difference)
C00F C00F
E00F E00F
400F 400F

(Note that under windows these F's show up as 7's)
That is extracted fuse bits under linux have F's where shown above for both hex files and under windows they appear as 7's for both hex files, I don't know why.

So... is this a bug? Is there a way to edit the part under linux to fix this. Why would it matter if DEBUG was set or not? How could that keep the part from starting up, I can touch MCLR with my finger and it goes, just as if MCLR was enabled for reset however it is not. Where are these fuse bits in the HEX file, I can not find them, Was only able to extract them with the programming software. The two generated HEX files do not match!

Thanks for any help, I have been at this a while,

[Guest]

Debug, is an inverted bit, so Windows has it disabled, while Linux is enabling it. With debug enabled the chip will require the handler code to be loaded at the top of memory to run. MCLR, is a slightly 'unusual' bit, since it retains the connection to the clear circuitry, and has no protection diode, hence you can trigger a reset, even when it is turned off, if the line goes above 5v.
On most programmers, you can set the config bits from their own software (easiest way of fixing it).
Try being lateral. What happens if you set the fuses to 'DEBUG', rather than 'NODEBUG'. I'd not be suprised if the logic was accidentally reversed (since it is an inverted fuse). You could then just use an if statement, to check the compiler version and correct the fuse.
The fuses are at the end of the .hex file. Usually three lines in from the end. The forth line in, sets the 'page', to the 0x30000 area, wth a line like:

:020000040030CA

Then the next line is the config bits.

Best Wishes

[ednspace]

Thanks for the info on the fuse bit location and the suggestion to think laterally Very Interesting.

I tried setting NODEBUG to DEBUG in the fuse line, however the configuration bit still comes up unset. Makes no difference which way it goes I get the same result in the hex file. Ah Well.

I guess for now I can just manually program the fuses with the programmer under linux. I am not changing the fuse line around much anyway and want to move on.

It would be nice if there was a way to manually edit the part of CCS that is controlling the fuse settings for this part.

Is there a way to do this under linux?

Do you all think I should file a bug report, seems to me to be a bug at this point.

Thanks so much for the quick response.
ED

[Ttelmah]

I'd definately report it as a bug.
You will probably find they'll fix this very quickly (this type of one is normally done fast). I don't know of a way to fix this type of bug from the Linux compiler (or the Windows command line one), but you could probably just add a #ROM statement to get the right values.

Best Wishes