PDA

View Full Version : Error 115 - Duplicate label



ChrisKiwi
- 8th June 2014, 09:48
Hi, I have encountered some kind of duplicate #define type problem (?). The error is

Error[115] ...\LBA_1509_PBP3_0_1.X\MAIN.ASM 14 : Duplicate label ("SPBRG" or redefining symbol that cannot be redefined)


I'm thinking that there may be a typo in the PIC16F1509.PBPINC file...

I see there is another thread on the subject relating to a different problem so it got me thinking and I found a workable (?) solution, for the time being at least. I'm not sure of the implications of what I have done so am seeking advise on this. I have the blinky led program working now, to test this idea out, but the blinky led doesn't require the use of much PIC hardware. What I have done is comment out a line in the PIC16F1509.PBPINC file like this:

#HEADER
LIST
LIST p = 16F1509, r = dec, w = -302, c = 255
INCLUDE "P16F1509.INC" ; MPASM Header
BLOCK_SIZE EQU 32
;#define SPBRG SPBRGL; Comment out this line
#define EEDATL PMDATL
#define EEADRL PMADRL
#define EEDATH PMDATH
#define EEADRH PMADRH
#define EECON1 PMCON1
#define EECON2 PMCON2
#ENDHEADER
As far as I know this only relates to the EUSART baudrate settings. I have looked in the p16F1509.inc file but can't really find anything useful apart from the fact that there is SPBRGL and SPBRGH. I'm thinking that there may be a typo in the PIC16F1509.PBPINC file but I don't know the best way to correct it.
Any help appreciated :)
Chris

Demon
- 8th June 2014, 15:09
Show us your code. I'm guessing you are defining something that is already defined without realizing it.

Robert


Edit: it's always possible you are the first to use that chip and found a bug.

ChrisKiwi
- 9th June 2014, 08:34
My blinky led code...

#CONFIG
__config _CONFIG1, _FOSC_INTOSC & _WDTE_OFF & _MCLRE_ON & _CP_OFF & _CLKOUTEN_OFF & _PWRTE_OFF & _BOREN_OFF
__config _CONFIG2, _LVP_OFF & _LPBOR_OFF
#ENDCONFIG
#define OSC 4
OSCCON=%01101000 ' 4MHz internal
TRISC=0
PORTC=0
LED0 var PORTC.0

Start:
LED0=1
Pause 500
LED0=0
Pause 500
Goto Start
And I doubled checked by un-commenting the line in the .PBPINC file and trying to compile (with the same error result).

EarlyBird2
- 9th June 2014, 08:49
#define OSC 4 is the error

should it be

DEFINE OSC 4?

ChrisKiwi
- 10th June 2014, 09:02
Actually thats not what I have in my project so I must have copied and pasted the wrong code, though the rest of the lines are the same. I tried changing my code to what I posted and it compiles and runs OK (if I have the line commented out as noted in my original post) and I've just checked in the PBP3 manual and that syntax is allowed, like the #config

EarlyBird2
- 10th June 2014, 09:16
Just trying to help. No need to get upset.

HenrikOlsson
- 10th June 2014, 10:25
Hi,
I tried to compile the code, specifically:

#CONFIG
__config _CONFIG1, _FOSC_INTOSC & _WDTE_OFF & _MCLRE_ON & _CP_OFF & _CLKOUTEN_OFF & _PWRTE_OFF & _BOREN_OFF
__config _CONFIG2, _LVP_OFF & _LPBOR_OFF
#ENDCONFIG

#define OSC 4

OSCCON=%01101000 ' 4MHz internal
TRISC=0
PORTC=0
LED0 var PORTC.0

Start:
LED0=1
Pause 500
LED0=0
Pause 500
Goto Start

And it compiles and assembles for the 16F1509 without any error messages or warnings using PBPX 3.0.7.4 and MPASM 5.45.
What version of MPASM are you using?

As for the DEFINE vs #DEFINE.... Yes both are valid but different and in this case you DO want DEFINE OSC 4 - without the # - but it's not related to the error message you get.
See section 2.3.3 (DEFINEs defined) as well as section 4.10 (#DEFINE) in the manual.

/Henrik.

ChrisKiwi
- 10th June 2014, 11:01
I wasn't upset and I appreciate the fact you replied with a suggestion. The error was mine, in that I posted code from the wrong window, but from your response, we have both discovered something new about PBP3 - so I guess we are both winners :)

EarlyBird2
- 10th June 2014, 11:22
The only reason I come here is to learn, as most people do. Whether what I learn will be of any use or not is debatable. For me it just needs to be interesting.

ChrisKiwi
- 10th June 2014, 11:30
Hi,
I tried to compile the code, specifically:

And it compiles and assembles for the 16F1509 without any error messages or warnings using PBPX 3.0.7.4 and MPASM 5.45.
What version of MPASM are you using?

/Henrik.
I have MPSAM 5.56 in the Microchip install folder, but I also have 5.37 installed in another folder completely outside the Microchip install folder. I'm running MPLAB X 2.10 and I also have a copy of MPLAB 8.92 installed. I have removed MPSAM 5.37 from the tool list in MPLAB X but still same error. My PBP3 is version 3.07 (I downloaded the trial) Would you mind looking at your PIC16F1509.PBPINC file, line 41 and advise if it reads as

#define SPBRG SPBRGL

If it does, then I guess I have some version conflict which I need to sort out (perhaps it is time to reinstall fresh). Thanks, Chris

HenrikOlsson
- 10th June 2014, 12:24
Hi,
Yes, line 41 of my PIC16F1509.PBPINC reads exatly like that.

Yeah, there's probably some sort of conflict between the definitions in the PBP inc file and MPASM inc file. Since the #header block is passed directly to the assembler I'm guessing that the ASM inc file ALSO includes a line defining ("aliasing") SPBRG as SPBRGL - but that's just a guess.

If you're actually USING MPLABX as your IDE then I'm not the right guy to help you (never got it working). If you're not using it (or don't feel you HAVE to use it) I recommend you download and install the full package (including MPLAB 8.90) available from Melabs download page (http://pbp3.com/download.html) and use MicroCodeStudio as the IDE.

/Henrik.

ChrisKiwi
- 10th June 2014, 22:53
Thanks Henrik, I was thinking along those lines as I felt that it looked like it was trying to define it's self in a sense, but I really don't have enough knowledge to be sure, hence the reason I was asking! I have the full package, I'll try installing that. I use to use MCS but I lost the key and the crowd that makes it wasn't interested in helping me retrieve it so I gave up on that (I got a new computer or the hard drive fell over or some such, was a few years ago) and I didn't feel inclined to pay a second time. Using the free version - well, that really did upset me, so I turfed it out LOL Thanks for your help :)

ChrisKiwi
- 11th June 2014, 12:37
Yeah, there's probably some sort of conflict between the definitions in the PBP inc file and MPASM inc file. Since the #header block is passed directly to the assembler I'm guessing that the ASM inc file ALSO includes a line defining ("aliasing") SPBRG as SPBRGL - but that's just a guess.
/Henrik.
Your comments got me thinking further so I downloaded the "Full" version of PBP3 and installed MPLAB 8.9 and got my code to compile and run with out commenting out the line in the PBPINC file. I compared the Microchip INC files and found that MPSAM 5.49 that installed from the full PBP3 download only had entries for SPBRGL and SPBRGH while MPASM 5.56 (Installed with MPLAB-X) had SPBRG (the offending one) SPBRGL and SPBRGH. The data sheet for the pic refers to SPBRGL and SPBRGH as 2 8 bit registers but refers to SPBRG as the combined value of the 2 registers. In the MPASM 5.56 inc file (MPLAB-X) SPBRG and SPBRGL have the same address, so in effect that is saying that SPBRG abd SPBRGL are the same thing, thus, you are defining the same thing twice or in different places (as per the error message) when you are using MPLAX-X with MPASM 5.56 and PBP3 but not when you are using the older version of MPLAB with MPASM 5.49 and PBP3. My solution is to comment out the line out in the PBP3 .PBPINC file on the basis that I think PBP3 should be compatible to MPASM, rather than the other way round. I wonder if this could be considered a "bug" ? - which came first - the chicken or the egg? Chris

HenrikOlsson
- 11th June 2014, 13:50
Hi,
Yey, so my guess was spot on then :)

My solution is to comment out the line out in the PBP3 .PBPINC file on the basis that I think PBP3 should be compatible to MPASM
I agree, though one could argue that PBP3 was, and still is, compatible with the version of MPASM available at the time of release and with the version available and included in the PBP3 download package.
Then Microchip decides to change things at their end (or possibly fixing a potential isssue that PBP3 provided a workaround for) resulting in an incompatibillity issue between the different versions.

It kind of sucks that Mecanique (if that's where you got MCSP) didn't want to help you recover the license. I'd try speaking to MELABS and see if they can help you. If you got it prior to PBP3 you'd need to upgrade it anyway.

/Henrik.