possible inconsistencies between a .hex file generated from PBP v 2.5c and v 3.0.6.1?

Hey guys I'm new to this forum but I had kind of a specific question that I couldn't find the answer for in Google (yes, it had to happen someday) so I'm posting it here. If this issue has already been discussed somewhere and you have a link to it I'd appreciate it if you'd let me know. Otherwise I'm going to post the question here.

I'm working on modifying a code that was originally compiled on PBP version 2.5c and am currently using trial version of PBP 3.0.6.1 before I purchase the full version of the product. Problem I'm having right now is that when I compile the code, even without any modifications, and program a pic16f876a microcontroller with it, it does nothing.

Now that wouldn't be an issue if the .Hex file of the same code that was generated using PBP v2.5c didn't work just fine.

pic16f876a in this particular application is used to control an LCD screen and uses the standard LCDout function in order to display characters on the screen. Code compiles without errors and microcontroller programs just fine, however, once placed within the board the LCD outputs 8 black squares on half of the screen while the other half of the screen remains blank.

I'm using a picstartplus programmer and Mplab IDE v 8.63.

Any suggestions on what might be causing this error would be greatly appreciated.

Hi,
How are you setting the CONFIG bits of the chip? Within your code, or thru PICStart interface in MPLAB or not at all (ie. you're relying on the defaults)?

What's the frequency of your oscillator?
PBP3 defaults to XT_OSC for the 877A, if you're running with a high frequency crystal, like 20MHz then you need HS_OSC instead.

/Henrik.

I'm not setting the CONFIG bits in code, I am relying on defaults as you pointed out. I have the microcontroller set to pic16f876A in MicroCode Studio. Original code also didn't set the config bits of the chip so i assumed (probably falsely) the default settings must have been the same.

I am not changing the config bits in PICStart interface, I have "Configuration bits set in code" box checked in "Configure Bits" dialog box like it was by default.

frequency of the oscillator is 8 MHz so XT_OSC I think should be fine for this case.

Hi,
I'd assume that as well - and they probably ARE the same but I guess double checking it wouldn't hurt (I don't have any old version of the compiler on this machine so I can't check).
When you say that the it works with the .hex from 2.5c are you actually compiling the code with 2.5c and using the resulting .hex file or are you using a previosuly compiled and saved .hex? The reason I ask is because you might, at some point in time, have used MPLAB to change the CONFIG and saved it back into the original .hex.

Anyway, the datasheet for 876A says that you should use HS_OSC for 8MHz and up - my guess is that's where the problem is.
Import the original .hex file in MPLAB and look at the CONFIG (Configure->Configuration bits), does it say XT or HS? Then do the same with the new .hex, if it says XT change it HS before programming the chip. If that does the trick then take a look at the #CONFIG directive in the manual and use it to change the CONFIG in your code.

/Henrik.

Henrik you da man. :)

That's exactly right on both accounts. No I didn't use 2.5c compiler, the .hex file I had was previously compiled on a 2.5c compiler and I bet you are right, the CONFIG bits were probably changed using MPLAB and saved in the original .hex file.

It did not even cross my mind to import the original .hex file in MPLAB to check the configuration bits and yes I just checked and it says HS rather than XT. I'll try and set all CONFIG bits to be identical to the original code as it won't be needed to change for the functions I'm modifying.

With that said, does MPLAB automatically overwrite the original .hex file after setting the bits through MPLAB?

Thank you very much.

Hi,
Not sure but I certainly wouldn't expect it to. You'd probably need to save or export it again in order for the CONFIG changes to be saved back into the .hex.
Good luck!

/Henrik.