Code placement in program memory.

[Odin]

I have a question about how and where code is placed in the program memory. I'm not even shure what to ask about, but I'll give it a try:
I'm using MPlab 8.20 to modify a program for a PIC18F258. My task is to do some minor changes. The code was written 4-5 years ago, with an older version of MPlab. I have copied the whole project folder to my computer, and open the project file. So far, so good. At first build it asks wich mpasmwin.exe and mplink.exe I want to use. I think the project file points to some older versions, in a different folder. I choose the newest default from mplab. Building the project is all fine. But I notice a difference in where the code is put in the program memory. If I import the original hex-file, some of the code is placed from address 6000. With my assembly, all code is placed from address 0000. Is there any good reason for this? The program seems to work fine, but I don't know all the details about pics. I'm afraid to do something stupid here. Heck, I'm just doing a small change in a text, and I end up taking a masters degree in programming.

 

[Nigel Goodwin]

It doesn't matter where the code goes, as long as it works - there are essentially two methods of writing PIC code, one uses absolute addresses, and the code goes where you tell it (most code is written like this), or there's relocateable code, where it doesn't include specific addresses, and the assembler decides where it will go.

 

[Odin]

It doesn't matter where the code goes, as long as it works - there are essentially two methods of writing PIC code, one uses absolute addresses, and the code goes where you tell it (most code is written like this), or there's relocateable code, where it doesn't include specific addresses, and the assembler decides where it will go.

My plan was to assemble te code with the newest mplab, and verify that the new hex-file is the exact same as the old one. That would give me some piece of mind before starting to modify anything. Now I have two different files, wich I assume does the same job. But I can't be 100% certain. Maybe I should install an older version of mplab and check what happens. But in general I like to run the newest version of whatever I use.
Conclusion: Verification of a chip from mplab can tell me if the code is the same, but it can't tell me if it's different.

 

[Nigel Goodwin]

The version of MPLAB makes no difference, only how you're using it.

It sounds like you originally used absolute addressing code, and now you're uisng relocateable code.

 

[Odin]

The version of MPLAB makes no difference, only how you're using it.

It sounds like you originally used absolute addressing code, and now you're uisng relocateable code.

Well, "I" didn't do anything, but the programmer who worked here 3 years ago did. He's not available now, or at least it's rather difficult to get in touch with him. I've investigated further, and found that if a grab a working unit from the shelf, it verifies ok with my freshly assembled code. So I think everything's fine. However, if I verify against the hex-file in our archive, it doesn't verify ok. I suspect the procedure for burning the chips was to copy the project folder to a local machine, assemble and burn.
I wanted to just import the hex-file from the archive and burn it.

Next problem now are the config bits. If I import the hex file directly, and verify with the pic, it doesn't give any error if they're wrong set. I can of course set them manually. But there's an option in the config bits window in mplab to "Configuration bits set in code". I thought that would make life easy, just import file and burn. But the word "code" might not refer to the hex-file, but to the asm-file? Even if I uncheck the "config bits in code"-box, and change the values and it verifies ok. It needs a build before it fails verification. I don't wanna build the project every time I burn a chip. It's to easy to make changes, type something wrong etc.
Would the correct way be to import hex-file, set config manually and then burn? Strange thing, the config bits changes to the correct setting when the hex is imported. Maybe just a bug with verification here?

 

[Nigel Goodwin]

Config fuse settings should always be set in the source code, then they are assembled in the HEX file with the rest, and should verify along with the actual program code.