Compiler/assembler problems preventing a simple change

I have been trying to fix an issue with some PBP code that was originally compiled with PBP 2.60A. When I compile the code with PBP 2.60A, I can burn it onto the chip (an 18F4520), but it doesn't do anything and the LCD screen its connected to just shows white rectangles. I believe I am also using the MPASM version that was originally used with the code.

I went through the code and the hardware schematics and am completely confident that I only need to change the value of *one* number in the code. It's the lower bound of a comparison in an if statement.

I have the original .hex file which, when burned, will actually work - is there an easy way to find the number in the original hex file?

Any other thoughts into how to solve this problem? In a nutshell, it's that I know how to fix a bug in the code, but can't seem to replicate the settings under which the code was originally compiled.

Here's another question that, when answered, may solve my problem:

-What variables affect the generation of the .hex file by MicroCode Studio, and how can I extract information on them from a .hex file or other product of an earlier compilation?

Hi,

As you do not report compilation/assemble errors I'll assume there are none.

In theory it shouldn't matter which assembler you use - with the proviso that it understands the syntax produced by the compiler.

Have you compared the two hex files? You should have one changed byte and a couple of changed checksums.

How sure are you that you are using the correct version of the compiler?

Yes its possible to change a byte in a hex file, the format is well documented. I beleive there is a overall checksum and one for each line.

Quote:

---

What variables affect the generation of the .hex file by MicroCode Studio

---

All the variables.

Does you source include the fuses used for flash programming? If not I guess you manually enter them into your programmer?

Does your programmer allow you to make modifications?

Personally, I wouldn't even try to change the hex file, I'd find out whats wrong.

George

Normally I find that white squares on an LCD is a timing issue. Are you sure you have the correct crystal installed and correct OSC set in the code ?

Thank you for the quick replies!

towlerg:
Yes, the code compiles fine. A bit of backstory: I was given code to fix, and it came in two files- one was a text file with PBP code, and the other was a PBP file that was mostly macro functions written in assembly. The code was previously compiled with PBP 2.60A, and I was given the version of MPASM that it was originally compiled with.

When I compile the code with PBP 2.60A and the same MPASM version now in MicroCode Studio, the hex file that is produced just writes white squares to the LCD of the hardware I'm working with, even though *nothing* has changed in the code.

I should have clarified what I meant when I asked about variables: I was wondering if PBP 2.60A relies on certain environment variables in windows, or if compiling it on a windows XP machine would yield different results than compiling it on a windows 8 machine. I would hope not, but I am running out of other possibilities. Browsing other threads, I have heard of people resorting to reinstalling their OS's to get things working, especially after mistakenly installing an incorrect version of software.

I'll need to compare the hex files next... and I'll also look for the fuses. I haven't seen any in the code so far, but I'll need to look through it again with that in mind.

Scampy: I'm glad you mentioned that - a timing issue and the currently-unknown states of the fuses leaves the possibility that my code configures the oscillator one way, but the programmer (meLabs programmer beta) might be overwriting the oscillator config.
Is there any way to read the config/fuse settings from the hex file/from a programmer connected to a functional piece of hardware?

I believe PBP 2.60a needs an older MPASM to work properly. It needs MPLAB v8.15a as the latest to use.

Why Yes Chrome, you can see all of the CONFIG settings, (fuses) by reading back the data from the particular PIC processor you are using. Provided the code protect bit is NOT set. This is done using an ICSP programmer like the PICKIT2 or PICKIT3 or ICD programmer connected to the ICSP pins and using MPLAB.