• AVR Freaks

Hot!error: (1356) fixup overflow referencing psect

Page: 12 > Showing page 1 of 2
Author
sjb741
Super Member
  • Total Posts : 805
  • Reward points : 0
  • Joined: 2010/01/25 08:45:39
  • Location: 0
  • Status: offline
2019/06/19 09:04:05 (permalink)
0

error: (1356) fixup overflow referencing psect

In detail: XC8 2.05, the error can sometimes go away if I add some Nop() calls.

dist/PWM/production\PWM.X.production.o:270:: error: (1356) fixup overflow referencing psect bssBANK1 (0xA3) into 1 byte at 0x1F02/0x2 -> 0xF81 (dist/PWM/production\PWM.X.production.o 270/0x26)


I loaded the object file into a text editor, and looked around offset 0x1F02, which seems to be just some comments.

Here is the total assembly code used - I have done many edits & compiles with this code unchanged and had no errrors. I would like to leave it be if possible.

   asm("bsf INDF0, 2");                     //re-start TMR 'A'
//re-initialise FSR0. Note we cannot simply use FSR1 as it is reserved by the compiler.   
   asm("movf _gpTyCON, w");
   asm("movwf FSR0L");
   asm("movf _gpTyCON+1, w");
   asm("movwf FSR0H");
   asm("bsf INDF0, 2");                     //re-start 'y' timer


I looked at FAQ47 "Why do I get the fixup error, and how can I correct it?", and I still do not know what to do about this error. The above FAQ states

So what causes this? In rough order of likelihood, this error is generated by:

    Hand-written assembly code that did not include the required address masking
    Incorrect bank qualifiers
    Functions or statements (e.g. switch statements) that are too big
    Incorrect linker options defined by the programmer

The 3rd item looks nebulous. Processor is 16F1824, and code is at 89%.
post edited by sjb741 - 2019/06/19 09:06:07
#1

23 Replies Related Threads

    1and0
    Access is Denied
    • Total Posts : 9287
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: error: (1356) fixup overflow referencing psect 2019/06/19 09:23:04 (permalink)
    +1 (1)
    Why use embedded assembly?  Have you taken care of the correct banking for accessing those variables?
     
    If I have to guess, it looks like gpTyCON hold the address of a Timer Control Register. If so, why not access it directly? ... and use C.
     
     
    post edited by 1and0 - 2019/06/19 09:26:39
    #2
    mbrowning
    Just a Member
    • Total Posts : 1418
    • Reward points : 0
    • Joined: 2005/03/16 14:32:56
    • Location: Melbourne, FL
    • Status: online
    Re: error: (1356) fixup overflow referencing psect 2019/06/19 09:37:24 (permalink)
    +1 (1)
    Check the How Do I Fix a Fixup Overflow Error section in the compiler user guide (2.7.8 in the c99 guide, 3.7.8 in the legacy guide). This is maybe because gpTyCon moved out of bank 0 and now the address doesn't fit in the 7bit address field in the mov instructions.

    Oh well - there's always next year
    #3
    1and0
    Access is Denied
    • Total Posts : 9287
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: error: (1356) fixup overflow referencing psect 2019/06/19 09:47:26 (permalink)
    0
    mbrowning
    Check the How Do I Fix a Fixup Overflow Error section in the compiler user guide (2.7.8 in the c99 guide, 3.7.8 in the legacy guide). This is maybe because gpTyCon moved out of bank 0 and now the address doesn't fit in the 7bit address field in the mov instructions.

    Frankly, I think the compiler should and can perform this truncation automatically. It does for this:
    uint16_t x;
    uint8_t y;
    y = x;

    so why not.!?
     
    #4
    1and0
    Access is Denied
    • Total Posts : 9287
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: error: (1356) fixup overflow referencing psect 2019/06/19 10:02:08 (permalink)
    0
    XC8 User's Guide
    In most cases, fixup errors are caused by hand-written assembly code. When writing assembly, it is the programmer’s responsibility to add instructions to select the destination bank or page, and then mask the address being used in the instruction

    The compiler knows the size of the address field in the instruction. Is it so dumb that it cannot just perform the truncation automatically, instead of having the programmer manually masks it? MPASM does the truncation automatically, surely a C compiler is smarter than it? ... and it would make for less-cluttered code, not to mention less typing too. ;)
    #5
    mbrowning
    Just a Member
    • Total Posts : 1418
    • Reward points : 0
    • Joined: 2005/03/16 14:32:56
    • Location: Melbourne, FL
    • Status: online
    Re: error: (1356) fixup overflow referencing psect 2019/06/19 12:03:56 (permalink)
    0
    ASPIC18 will automatically truncate when the address is known in advance, but generates warnings when it does.
    Thus to remove warnings my time critical (ISR) inline asm has a lot explicit truncation like this:
        asm("banksel SPI1RXB");        // (1) bank 61
        asm("movf (SPI1RXB&0xff),w,b");    // (1) w = SPI1RXB // rcv byte1

    For variables not in bank 0 however, the "fixup" mechanism doesn't seem to be smart enough, so I have to do the same silly thing.
     
    Simple test for pic18f56k42
    #include <xc.h>
    #include <stdint.h>

    uint8_t array1[128], array2[128], array3[128], array4[128];
     
    void main(void) {
        while (1) {
            asm("banksel _array1");
            asm("setf _array1");
            asm("banksel _array4");
            asm("setf _array4"); // << fixup error
        }
    }
    This gives the fixup error. Changing the 4th asm line to
    asm("setf _array4&0xff");
    no fixup error.

    Oh well - there's always next year
    #6
    1and0
    Access is Denied
    • Total Posts : 9287
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: error: (1356) fixup overflow referencing psect 2019/06/19 12:49:10 (permalink)
    0
    mbrowning
    ASPIC18 will automatically truncate when the address is known in advance, but generates warnings when it does.
    Thus to remove warnings my time critical (ISR) inline asm has a lot explicit truncation like this:
        asm("banksel SPI1RXB");        // (1) bank 61
        asm("movf (SPI1RXB&0xff),w,b");    // (1) w = SPI1RXB // rcv byte1


    This
    asm("movf (SPI1RXB&0xff),w,b"); 

    is not only cluttered but also removes the banking bit from the register forcing you to have to explicitly code the RAM access bit. In comparison, wouldn't this
    asm("movf SPI1RXB,w"); 

    be clearer and more readable?
     

    For variables not in bank 0 however, the "fixup" mechanism doesn't seem to be smart enough, so I have to do the same silly thing.
    ...
    Changing the 4th asm line to
    asm("setf _array4&0xff");
    no fixup error.

    As I said, that is needless cluttering up the code. What needs a "fixup" is the compiler and/or assembler. ;)
     
    #7
    1and0
    Access is Denied
    • Total Posts : 9287
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: error: (1356) fixup overflow referencing psect 2019/06/19 12:58:01 (permalink)
    0
    Also, for some unknown reasons, the BANKMASK() macro _no_ longer work, such as
    asm("setf BANKMASK(_array4)");

    or 
    asm("setf BANKMASK(PORTA)");

     
    #8
    sjb741
    Super Member
    • Total Posts : 805
    • Reward points : 0
    • Joined: 2010/01/25 08:45:39
    • Location: 0
    • Status: offline
    Re: error: (1356) fixup overflow referencing psect 2019/06/19 13:10:43 (permalink)
    0
    Many thanks all for the feedback.
     
    The assembly is needed as the code is time critical. The effect is to synchronise the period of any two PWM modules.
     
    The variable gpTyCON takes its value from a parameter passed into a generic function, which would be useful for PICs with say 4PWMs. For this PIC it is not strictly necessary to write such a generic routine, but I like to think ahead to other projects and have re-usable code. I do not know which TxCON is passed in, so I do not know the bank.
     
    Really, I'd like to understand the issue more than just fix it because that helps me for the future as well.
     
    (Aside: I copy the parameter to a global as the assembler does not recognise the parameter name for some reason, but that is a side-issue here. Also I was thinking that using FSR and INDF took care of banking).
     
    I have had this assembly code unchanged over dozens of edits to the rest of the code, and had lots of working compilations.
     
    So:
    1. Why does adding about line or two of C code, sometimg like "oldTicks = Ticks" in this case break it?
    2. How come most compilations work fine?
     
    I can undo my C-code edits, and it would compile. Those lines of assembly would not been altered.

    <Our posts crossed, so I am moving my edit to a new post>
     
    post edited by sjb741 - 2019/06/19 13:46:27
    #9
    1and0
    Access is Denied
    • Total Posts : 9287
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: error: (1356) fixup overflow referencing psect 2019/06/19 13:21:19 (permalink)
    0
    sjb741
    ...
    I do not know which TxCON is passed in, so I do not know the bank.
    ...
    (Aside: I copy the parameter to a global as the assembler does not recognise the parameter name for some reason, but that is a side-issue here. Also I was thinking that using FSR and INDF took care of banking).

    The banking issue is not with INDF, but with the MOVF instructions in your Post #1. The bank must be correct to access gpTyCON correctly, unless it is located in shared memory.
     
    Edit: For parameter and auto variables, the syntax is function_name@variable_name.
     
     
    1. Why does adding about line or two of C code, sometimg like "oldTicks = Ticks" in this case break it?
    It probably changes the bank.



    post edited by 1and0 - 2019/06/19 13:23:46
    #10
    mbrowning
    Just a Member
    • Total Posts : 1418
    • Reward points : 0
    • Joined: 2005/03/16 14:32:56
    • Location: Melbourne, FL
    • Status: online
    Re: error: (1356) fixup overflow referencing psect 2019/06/19 13:41:51 (permalink)
    +2 (2)
    sjb741
    I do not know which TxCON is passed in, so I do not know the bank.

    The bank must be known.   This code will not work if the BSR isn't set correctly
    asm("movf _gpTyCON, w");

    sjb741
    Really, I'd like to understand the issue more than just fix it because that helps me for the future as well.
      1  Why does adding about line or two of C code, sometimg like "oldTicks = Ticks" in this case break it?
      2  How come most compilations work fine?

    Is it possible that the error is not caused by the assembly code, but is instead symptomatic of the program memory getting fuller.

    Well I spent some time explaining exactly why this happens above. Here it is again.
    If "gpTyCON" is in bank 0,  asm("movf _gpTyCON, w"); will work without error. If "gpTyCON" is not in bank 0, it will give the fixup error. This is because the address of gpTyCON exceeds 127 and can't fit in the 7bit address field in the movf instruction.
     
    Changing code may cause variables to get placed by the linker in different places, so the error can come and go. Frankly this is a good thing for you because you aren't adjusting the BSR to point to the bank the variable is in so your code wouldn't work if the variable isn't in the expected bank (which must be 0 to get no fixup error).
     
    If the bank is correct, then
    asm("movf _gpTyCON&0x7f,w");

    would remove the fixup error.
     
    As 1and0 has made clear, it's pretty stupid that we have to do all this manual manipulation, but it is what it is.
     
    1and0
    In comparison, wouldn't this
    asm("movf SPI1RXB,w"); 

    be clearer and more readable?

    Sure, but "test.c:10:: warning: (1352) truncation of operand value (0x3d10) to 8 bits" is the result.

    Oh well - there's always next year
    #11
    sjb741
    Super Member
    • Total Posts : 805
    • Reward points : 0
    • Joined: 2010/01/25 08:45:39
    • Location: 0
    • Status: offline
    Re: error: (1356) fixup overflow referencing psect 2019/06/19 13:56:41 (permalink)
    0
    mbrowning: Sorry, I mentally blanked out most of your reply as I thought ASPIC18 was related to another toolchain, and you were discussing something 'related', but on another assembler/compiler product - my mistake.
     
    I wanted to be 100% sure that there was no way a future compiler version would change the way BANKSEL was implemented (I realise that scenario is pretty far-fetched, but I wanted to be absolutely sure, for timing reasons..., and I wanted to see the actual assembly in my source code, not a psuedo-op!).
    "As this pseudo instruction can expand to more than one instruction on mid-range or baseline parts "
     
    Forcing gpTyCON to BANK0 does work.
     
    Ideally I would get rid of gpTyCON, but as mentioned, the compilation fails if I try to reference things like  _SomeParameter - despite the examples in the manual doing that.
    post edited by sjb741 - 2019/06/19 14:21:30
    #12
    mbrowning
    Just a Member
    • Total Posts : 1418
    • Reward points : 0
    • Joined: 2005/03/16 14:32:56
    • Location: Melbourne, FL
    • Status: online
    Re: error: (1356) fixup overflow referencing psect 2019/06/19 14:20:18 (permalink)
    +1 (1)
    XC8's assembler is ASPIC (ASPIC18 for pic18's). I've mostly used pic18, but shouldn't have added the confusing reference.
    banksel works fine in asm("");
            asm("banksel _array1");
            asm("movf _array1,w");

    bankmask does not work as 1and0 noted.
     
    You can force a variable to an address.
    volatile uint32_t    spiarray[33]    @ 0x5c;    // force addr to last 4B of comram

    for example. If you are using XC8 in C99 mode, I think the syntax is a bit different. Check the manual.

    Oh well - there's always next year
    #13
    ric
    Super Member
    • Total Posts : 22654
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: error: (1356) fixup overflow referencing psect 2019/06/19 15:30:03 (permalink)
    0
    sjb741
    ...
    Ideally I would get rid of gpTyCON, but as mentioned, the compilation fails if I try to reference things like  _SomeParameter - despite the examples in the manual doing that.

    That is the wrong syntax for local variables.
    Post#10 shows the correct syntax.
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #14
    mad_c
    Super Member
    • Total Posts : 1188
    • Reward points : 0
    • Joined: 2010/12/12 17:48:27
    • Location: Brisbane, Australia
    • Status: offline
    Re: error: (1356) fixup overflow referencing psect 2019/06/19 16:10:40 (permalink)
    +2 (2)
    mbrowning
    bankmask does not work as 1and0 noted.

     
    You can use it, but since macro expansion does not take place inside quoted text, you have to use it in an unfortunately long-winded way, like:
     
    asm("movwf " ___mkstr(BANKMASK(PORTA)));
     
    I am pretty sure you can use the ___mkstr() macro once you have included <xc.h>. There was talk of trying to improve this situation, but I doubt those changes made it into 2.10.
     
    Jeff.
     
    #15
    1and0
    Access is Denied
    • Total Posts : 9287
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: error: (1356) fixup overflow referencing psect 2019/06/19 17:20:51 (permalink)
    0
    mad_c
    You can use it, but since macro expansion does not take place inside quoted text, you have to use it in an unfortunately long-winded way, like:
     
    asm("movwf " ___mkstr(BANKMASK(PORTA)));
     
    I am pretty sure you can use the ___mkstr() macro once you have included <xc.h>.

    Then you need to update the XC8 User's Guide, such as on page 153, etc.
     

    There was talk of trying to improve this situation, but I doubt those changes made it into 2.10.

    Please fix this fixup error and get rid of the need for BANKMASK(), &0x7F and &0xFF.
     
    Also, how come this does not work anymore:
    asm("#include <xc.inc>");

    ?
     
     
    #16
    ric
    Super Member
    • Total Posts : 22654
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: error: (1356) fixup overflow referencing psect 2019/06/19 17:45:43 (permalink)
    0
    1and0
    ...
    Then you need to update the XC8 User's Guide, such as on page 153, etc.

    The bit with all the typos? :)
    https://www.microchip.com/forums/m1070242.aspx
     
    I note that XC8 v2.05 still came with DS50002737A so it hasn't been fixed yet.
     
    Plainly this code came from page 226 of the old manual, which used the #asm / #endasm syntax, and it was just reformatted (badly) to use the asm() syntax, with no regard to if it would still work.
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #17
    1and0
    Access is Denied
    • Total Posts : 9287
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: error: (1356) fixup overflow referencing psect 2019/06/20 04:50:39 (permalink)
    0
    ric
    The bit with all the typos? :)
    https://www.microchip.com/forums/m1070242.aspx

    Yep.
    #18
    mad_c
    Super Member
    • Total Posts : 1188
    • Reward points : 0
    • Joined: 2010/12/12 17:48:27
    • Location: Brisbane, Australia
    • Status: offline
    Re: error: (1356) fixup overflow referencing psect 2019/06/20 14:43:38 (permalink)
    0
    1and0
    Then you need to update the XC8 User's Guide, such as on page 153, etc.

    It's already been done. In fact the example I showed was copied from the latest (unreleased) guide, which also fixes the typos.

    Please fix this fixup error and get rid of the need for BANKMASK(), &0x7F and &0xFF.

    Such a change would be 'significant'. It would also prevent any sort of bank check you wanted to implement in assembly.

    Also, how come this does not work anymore:
    asm("#include <xc.inc>");

     

    That gave me lexical errors with compilers going back quite a few versions, so what do you mean by "anymore"? Also, what exactly is that meant to do? Include an assembly-level header into C code?
     
    Jeff.
    #19
    1and0
    Access is Denied
    • Total Posts : 9287
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: error: (1356) fixup overflow referencing psect 2019/06/20 20:27:01 (permalink)
    0
    mad_c
    Such a change would be 'significant'. It would also prevent any sort of bank check you wanted to implement in assembly.

    Just curious, what was the reason behind requiring the programmer to manually mask the address of the file register?  How does BANKMASK() perform bank check?
     

     
    That gave me lexical errors with compilers going back quite a few versions, so what do you mean by "anymore"? Also, what exactly is that meant to do? Include an assembly-level header into C code?

    Including the <xc.inc> file allows usage of bit symbols in the assembly code. It works with the #asm/#endasm syntax and I was expecting it to work with asm("") too, but sadly it does not appear to. 
     
    For example, to use a symbol for the Carry bit, the following #asm/#endasm syntax with bit symbols from the device specific .inc include file works:
    #asm
    #include <xc.inc>

    bcf STATUS,STATUS_C_POSN
    bcf CARRY
    #endasm

     
    For the asm("") syntax, only a number 0 for the bit works
    asm("bcf STATUS,0");

    while the following symbols from the device specific .h header file give errors
    asm("bcf STATUS,_STATUS_C_POSN"); // Error [800] undefined symbol "_STATUS_C_POSN"
    asm("bcf STATUS,CARRY");          // Error [800] undefined symbol "CARRY"
    asm("bcf CARRY");                 // Error [876] syntax error
    asm("bcf CARRY_bit");             // Error [876] syntax error

    and
    asm("#include <xc.inc>");         // Error [844] lexical error

    #20
    Page: 12 > Showing page 1 of 2
    Jump to:
    © 2019 APG vNext Commercial Version 4.5