Broken output of PIC Basic Pro 2.60 code compiled using 3.0.10 on Win10 64bit.

[fsteff]

Hi,

I've been tasked with making some slight alterations to an old legacy product.
It's designed in 2010, based around an PIC18F2420 and according to an old .ASM file, it's programmed in Pic Basic Pro 2.60. Unfortunately I don't know the version of MPLAB/MPASM used.

I've installed Pic Basic Pro 3.0.10 on my Windows Pro 64bit, and use it together with MPLAB 8.92 and the command line.

Using this setup, I am able to compile the old source, and to generate a HEX file with a used code size almost identical to the old size, however if I compare the contents of the two files side by side, there's about 20% differences, and worst of all, when programming the new HEX file to my target MCU, it's not working at all. :-(

Comparing the end of the two HEX files, I notice some changes that may be related to some PIC configuration not set identical.
The original and working HEX file ends like this:

:020000040030CA
:0E000000FF081FEEFF01BBFF00FFFFFFFF40E8
:00000001FF

While the new version end like this:

:020000040030CA
:03000100021F13C8
:020005008181F7
:060008000FC00FE00F40E5
:00000001FF

I'm yet to dive in, and try to understand the exact meaning of these values.


Comparing the two ASM files side by side, the translation from Basic to ASM is identical, except for paths and slight contents changes to both the 18F2420.INC file and the MODEDEF.BAS file.


I invoke the compiler like this: "C:\Program Files (x86)\PBP3\PBPX.EXE" -ampasmwin -k- -v -c -ow0 -oq -k# -p18F2420 "UTC.bas"
and it flawlessly creates an ASM file, which I then assemble using: "mpasmwin /w0 /q /o- C:\Work\p0703\UTC.ASM"


It's unfortunately not possible for me to run PIC Basic Pro 2.60 on any computer I have available, but I have tried a few other 3.x series (3.07 and 3.08 to be exact) with similar results.

Anyway, since the contents of the .ASM files are mostly identical I do suspect MPASM much more...

But before I start testing various versions of MPLAB, too, I'd like to ask if this is this a known problem with an existing workaround?

Any suggestions on how to proceed will be highly appreciated!.

Regards,
Flemming

[Charles Leo]

Are you saying that the rest of the hex in both files is identical, except for these few lines?

You can use a device programmer to get more information about the differences. Disable code-protection, program one hex file, then open the other hex file in the programmer software and perform a Verify operation. The programmer should give you exact information about the location of the differences. You can also just open each file in turn and view the configuration memory of each, comparing for differences.

Many users of 2.60 modified the default config directives in a file instead of placing them in the program. If you did this, the modifications won't carry over to PBP3. In PBP3, the config directives should be written in the program using the #CONFIG directive.

[fsteff]

Thank you for your reply, Charles,

No, the two HEX files data have about 20% differences (something one in every 5 hex values differ), and the used program space in the HEX file is only a few bytes off between the versions, so my (perhaps ungrounded) guess is that a newer MPASM may change the order of the parts in the HEX file output.

The reason I included the two snippets from the end of each version's HEX file, was because I thought I recognized it (without understanding it) as flags that might control the configuration of the PIC, ie. which oscillator to use, etc. I'll have to try to decode the intelHEX to figure out more.

I only have a copy of the program code, and resulting files after a compilation, such as LST, ERR, COF, etc. files. In the BAS file I do not see any CONFIG statements, but looking into the LST file, I do see some have been included, so they appear to only originate in PBP. Looking at the old LST file, I see complaints that __CONFIG is deprecated and CONFIG should be used instead. I'll try to compare them, to see if they reveal something that might explain what's going on.

Best regards,
Flemming

[fsteff]

I was correct in suspecting this problem was due to wrong PIC configuration settings.
Unfortunately, nothing remained of the original configuration (which were probably in an external file, as suggested by Charles Leo), but I were able to read out the values from the old preserved LST file, and also to compare the end of the .HEX file.

I first tried to configure inside the MPLAB IDE, but I couldn't set exactly the same bit-pattern as had been used in the original (mostly a case of unused bits defaulting to 1 instead of to 0), and the resulting binary continued to not run on the target.

Finaly I disabled the configuration in MPLAB, and instead added the following code to the start of my main .BAS file:

#IF __PROCESSOR__ = "18F2420"
  #CONFIG
    __CONFIG _CONFIG1H, B'00001000'
    __CONFIG _CONFIG2L, B'00011111'
    __CONFIG _CONFIG2H, B'11101110'
    __CONFIG _CONFIG3H, B'00000001'
    __CONFIG _CONFIG4L, B'10111011'
    __CONFIG _CONFIG5L, B'00000000'
    __CONFIG _CONFIG5H, B'11111111'
    __CONFIG _CONFIG6L, B'11111111'
    __CONFIG _CONFIG6H, B'11111111'
    __CONFIG _CONFIG7L, B'11111111'
    __CONFIG _CONFIG7H, B'01000000'
  #ENDCONFIG
#ELSE
  #ERROR "Program is intented for 18F2420, not " + __PROCESSOR__
#ENDIF

With this, the code generates exactly the same PIC configuration values as in the original .HEX file, and it runs perfectly on the target.