Searching \ for '[PIC]:build problem with PIC16F877 - bank2' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/memory.htm?key=bank
Search entire site for: 'build problem with PIC16F877 - bank2'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]:build problem with PIC16F877 - bank2'
2000\11\08@150900 by Sam Linder

flavicon
face
This message is being re-transmitted as I had forgotten the required [PIC]:
notation.

To all the smart PICers out there:

First let me apologize for the length of this query, but I felt that all of
the information was necessary.

I've got a strange build problem that doesn't make much sense to me and I'm
hoping someone out there can deciper the following data and explain what I'm
doing wrong (yes, I've read the Hi-Tech C Manual and read the Hi-Tech C Help
files). The following lines are lifted straight from the Error Section of
the Hi-Tech C Manual.

fixup overflow in expression *
The linker was asked to relocate (fixup) an item that would not fit back
into the space after relocation. For example this will occur if a byte size
object is initialized with an address that is bigger than 255. This error
occurred in a complex expression.

fixup overflow referencing *
The linker was asked to relocate (fixup) an item that would not fit back
into the space after relocation. For example this will occur if a byte size
object is initialized with an address that is bigger than 255.


In module COMOMAIN.C:
bank2 unsigned int  ui_flowsensor_threshold;

In module COMOSE~1.C:
extern bank2 unsigned int ui_flowsensor_threshold;

My PIC16F877 program is mostly written in C, with a bit of in-line assembly
tossed in as needed. As can be noted from the above lines, the variable
unsigned int  ui_flowsensor_threshold is defined as "living" in bank2 where
there appears to be plenty of room (see RAM Map at end of this email). Yet I
get the error messages seen below and my build fails. If I simply change the
variable to "live" in bank1, I get a successful compile. Que Pasa?


Building COMO.HEX...

Compiling COMOSE~1.C:
Command line: "C:\HT-PIC\BIN\PICC.EXE -q -Gcomo.dbg -D24 -E -ASMLIST -16F877
-C -N -fakelocal C:\HT-PIC\COMO\COMOSE~1.C"
Enter PICC -HELP for help

Compiling COMOMAIN.C:
Command line: "C:\HT-PIC\BIN\PICC.EXE -q -Gcomo.dbg -D24 -E -ASMLIST -16F877
-C -N -fakelocal C:\HT-PIC\COMO\COMOMAIN.C"
Enter PICC -HELP for help

Linking:
Command line: "C:\HT-PIC\BIN\PICC.EXE -q -Gcomo.dbg -INTEL -Ecomo.err
-Mcomo.map -PSECTMAP -16F877 -oCOMO.HEX -N -fakelocal -asmlist COMOSE~1.OBJ
COMOMAIN.OBJ COMO1W~1.OBJ COMODE~1.OBJ "
Error[000] comose~1.obj 134 : Fixup overflow referencing symbol
_ui_flowsensor_threshold (loc 0x19F6 (0x19B2+68), size 1, value 0x110)
Error[000] comose~1.rlf 2575 : Fixup overflow in expression (loc 0x78
(0x78+0), size 1, value 0x110)

MPLAB is unable to find output file "COMO.HEX".

Build failed.



UNUSED ADDRESS RANGES

BANK0            007F-007F
BANK1            00EC-00EF
BANK2            011F-016F
BANK3            0190-01EF
CODE             0800-0804
                 1000-1020
                 1800-1FFF
COMBANK          007F-007F
CONST            0800-0804
                 1000-1020
                 1800-1FFF

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\11\08@171902 by Andrew E. Kalman

flavicon
face
Re:

>In module COMOMAIN.C:
>bank2 unsigned int  ui_flowsensor_threshold;
>
>In module COMOSE~1.C:
>extern bank2 unsigned int ui_flowsensor_threshold;
>
>My PIC16F877 program is mostly written in C, with a bit of in-line assembly
>tossed in as needed. As can be noted from the above lines, the variable
>unsigned int  ui_flowsensor_threshold is defined as "living" in bank2 where
>there appears to be plenty of room (see RAM Map at end of this email). Yet I
>get the error messages seen below and my build fails. If I simply change the
>variable to "live" in bank1, I get a successful compile. Que Pasa?

Your declarations appear to be correct.

Some other things to look at are whether you've correctly defined any
pointers to ui_flowsensor_threshold, and whether you are passing it
as a parameter and your parameter list is correctly defined,
especially if you're passing it by reference.

In other words, all references to ui_flowsensor_threshold (not just
the two above) that should have a bank2 specifier must have it or
else you'll have this sort of problem.  The reason why it works in
bank1 is that bank1 and the unspecified bank0 are really equivalent
in this case (one covers 0x00-0x7F, the other 0x80-0xFF), and (I
suspect that) somewhere else in your code you're accessing
ui_flowsensor_threshold (unbenknownst to you) as if it were in one of
those banks (probably bank0, as that's the default). Absolutely
everything must be consistent or you'll get this kind of error.
That's why I suggest using typedefs with the bank specifier in them,
instead of an explicit bank specifier for each declaration, etc.

There's an App Note (AN-3) on our web site that covers this issue in-depth.

Regards,

--

 ______________________________________
  Andrew E. Kalman, Ph.D.   spam_OUTaekTakeThisOuTspampumpkininc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\11\08@182600 by Sam Linder

flavicon
face
Thank you for the insight. I accessed your website and downloaded AN-3 and
followed the suggestion. As you knew it would, it worked. I was passing
ui_flowsensor_threshold by reference to a function as follows:

function call:
ConvertASCIITo16BitBinary(&ui_flowsensor_threshold, uc_rxptr+2);

function declaration:
ConvertASCIITo16BitBinary(unsigned int *ui_binaryvalue, unsigned char
*uc_bufferptr);

It never occured to me that the function should be declared as follows:
ConvertASCIITo16BitBinary(bank2 unsigned int *ui_binaryvalue, unsigned char
*uc_bufferptr);

This raises an interesting situation. I was calling the function using two
different integer variables as input. One of them was in bank2, the other in
bank0. It appears that I need to ensure that all integer inputs calling this
particular function must be in the same bank or I'll get another error.
Something I'll have to watch for very carefully in the future with all my
other functions.

Thanks again for the assistance.



{Original Message removed}

2000\11\08@191117 by Andrew E. Kalman

flavicon
face
Sam wrote:

>This raises an interesting situation. I was calling the function using two
>different integer variables as input. One of them was in bank2, the other in
>bank0. It appears that I need to ensure that all integer inputs calling this
>particular function must be in the same bank or I'll get another error.
>Something I'll have to watch for very carefully in the future with all my
>other functions.

Yep, you got it. It will be  a runtime error, not a compile-time
error. The function will set the bank bits according to the parameter
declaration, and you'll find it operating on data in the wrong bank.
It's a bit tricky until you do it a couple of times, then it becomes
second nature.

To avoid such problems, I ended up using two typedefs for each type
of variable, with just a single-character postfix to differentiate
the two typedef names.

The first (what I call the qualified typedef) is used for variable
declarations and includes the bank specifier. The other, used
exclusively in parameter declarations, does not, in the sense that
the parameter itself is not banked (i.e. not qualified), although it
may very well point to a banked object. All of which is explained in
AN-3 as you found out.

I'm glad I was able to help ...


--

 ______________________________________
  Andrew E. Kalman, Ph.D.   .....aekKILLspamspam@spam@pumpkininc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\11\08@214809 by Bob Ammerman

picon face
I'm not a "C" guy on the PIC (tho' I do tons of it on other platforms), and
this got me to thinking.

given, on a '87x

typedef bank0 unsigned short us_0;
typedef bank1 unsigned short us_1;
typedef bank2 unsigned short us_2;

us_0    my_0;
us_1    my_1;
us_2    my_2;

void myfunc(us_0 *arg)
{
   <code>
}

I am guessing that:

   myfunc(&my_0);

will work.

And that:

   myfunc(&my_1);
   myfunc(&my_2);

should get compile time errors.

And that:

   myfunc((us_0 *) &my_1);

should work.

But that:

   myfunc((us_0 *) &my_2);

will break at runtime.


The difference between the cases for &my_1 and &my_2 is that the pointer is
loaded into FSR and the STATUS,IRP is set or cleared appropriately.

Since bank0 and bank1 are both accessed with IRP clear:

   (us_0 *) &my_1

will work.

Did I guess this right?

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




2000\11\09@114859 by Sam Linder

flavicon
face
Pretty good guess. Only Hi-Tech C causes link-time errors instead of
run-time errors with     myfunc((us_0 *) &my_2);


{Original Message removed}

More... (looser matching)
- Last day of these posts
- In 2000 , 2001 only
- Today
- New search...