Compiler C30 V3.23 to V3.30C Trouble

Author
Ajitha
New Member
  • Total Posts : 13
  • Reward points : 0
  • Joined: 2010/01/13 02:59:38
  • Location: 0
  • Status: offline
2011/09/13 00:38:15 (permalink)
0

Compiler C30 V3.23 to V3.30C Trouble

Hello guys,
 
I am using mplab IDE V8.6 and C30 compiler V3.23, my project works fine.
Now i'm getting under mplab IDE V8.76 and C30 compiler V3.30C, when compiled my project i get this error
 
c:/program files/microchip/mplabc30/v3.30c/bin/bin/../../lib\libc-elf.a(fflush.XXeo)(.libc.fflush+0x30):
In function `.L2':
: Link Error: PC Relative branch to '_write' is out of range. Suggest large-code model
 
I already checked "large-code model"
 
I am out of mood with microchip tools, i think it's not professionnal !
There is no help, nothing
 
If someone could help me
#1

11 Replies Related Threads

    leon_heller
    Super Member
    • Total Posts : 6410
    • Reward points : 0
    • Joined: 2004/08/17 13:19:45
    • Location: St. Leonards-on-Sea, E. Sussex, UK.
    • Status: offline
    Re:Compiler C30 V3.23 to V3.30C Trouble 2011/09/13 03:17:43 (permalink)
    0
    Code?

    Leon Heller
    G1HSM

    #2
    Ajitha
    New Member
    • Total Posts : 13
    • Reward points : 0
    • Joined: 2010/01/13 02:59:38
    • Location: 0
    • Status: offline
    Re:Compiler C30 V3.23 to V3.30C Trouble 2011/09/13 05:38:18 (permalink)
    0
    Sorry i can't give the project
    #3
    leon_heller
    Super Member
    • Total Posts : 6410
    • Reward points : 0
    • Joined: 2004/08/17 13:19:45
    • Location: St. Leonards-on-Sea, E. Sussex, UK.
    • Status: offline
    Re:Compiler C30 V3.23 to V3.30C Trouble 2011/09/13 05:49:41 (permalink)
    0
    You won't get any help, then.

    Leon Heller
    G1HSM

    #4
    DavidePizzolato
    Junior Member
    • Total Posts : 95
    • Reward points : 0
    • Joined: 2010/11/25 11:55:54
    • Location: 0
    • Status: offline
    Re:Compiler C30 V3.23 to V3.30C Trouble 2011/09/13 05:54:31 (permalink)
    0
    try rebuilding the project from scratch, it could be something wrong in a single file configuration or in the build order
    #5
    Ajitha
    New Member
    • Total Posts : 13
    • Reward points : 0
    • Joined: 2010/01/13 02:59:38
    • Location: 0
    • Status: offline
    Re:Compiler C30 V3.23 to V3.30C Trouble 2011/09/13 06:24:14 (permalink)
    0
    I have already done it.

    I have a computer with Mpalb IDE V8.6 and C30 V3.23 => works fine
    And the other one with Mpalb IDE V8.76 and C30 V3.30C => c:/program files/microchip/mplabc30/v3.30c/bin/bin/../../lib\libc-elf.a(fflush.XXeo)(.libc.fflush+0x30):
    In function `.L2':
    : Link Error: PC Relative branch to '_write' is out of range. Suggest large-code model
    #6
    cawilkie
    Administrator
    • Total Posts : 1954
    • Reward points : 0
    • Joined: 2003/11/07 12:49:11
    • Status: offline
    Re:Compiler C30 V3.23 to V3.30C Trouble 2011/09/13 08:09:46 (permalink)
    0
    The error means that the linker has put fflush() too far away to call write().  This should not happen because we build fflush() and write() into sections that belong together.  Unless you have written your own version of write()?

    Changing the memory model will not have any effect on pre-compiled code, sorry.

    If not, please upload your .gld file and a .map file.  If you can't do this on a public forum, then please submit a support request to support.microchip.com (which you should probably do anyway).

    Regards
    Calum
    #7
    eskopal
    Super Member
    • Total Posts : 281
    • Reward points : 0
    • Joined: 2003/11/07 12:35:18
    • Location: Ossining, New York
    • Status: offline
    Re:Compiler C30 V3.23 to V3.30C Trouble 2011/09/13 08:11:06 (permalink)
    0
    Look at the .map files generated for each.  It appears that the modules in the library are not compiled with the large code model (or they were written in assembler not using the large-code model techniques).  You need to force the caller of "_write" to be nearer where "_write" is loaded.
     
    Sometime ago Microchip rewrote the linker's allocation routines to better find and use every available location in memory.  This changed the order that modules were loaded and thus their relative positions.
     
    I modified the .gld file to add (.text) back to force it to load before the (.const) section.  Otherwise the calls to the library are always over the (.const) section which makes them a lot further away, requiring the large-code model (my .const section is HUGE).  The large-code model can make you program a lot larger as CALL instructions (outside the local module) take two-words to encode instead of one.
     
    /*
      ** User Code and Library Code
      **
      ** This section must not be assigned to __CODE_BASE,
      ** because CodeGuard(tm) sections may be located there.
      **
      ** Note that input sections *(.text) are not mapped here.
      ** The best-fit allocator locates them, so that .text
      ** may flow around PSV sections as needed.
      **
      ** [ES] -- Added *(.text); back -- otherwise .const is allocated
      ** [ES] at [0xFFFF] and down -- forces Text above that address requiring
      ** [ES] large code model (longer calls and jump).  PSV doesn't care if
      ** [ES] const is above [0xFFFF] so forced all of .text to load before .const.
      ** [ES] Also, moved ISR above (.text) since vectors are long jumps.
      */
      .text :
      {
            *(.init);
            *(.user_init);
            KEEP (*(.handle));
            *(.libc) *(.libm) *(.libdsp);  /* keep together in this order */
            *(.lib*);
            *(.text);
            KEEP (*(.isr*));
      } >program
     
    Hope this helps,
     
    ..Eugene..
    #8
    aschen0866
    Super Member
    • Total Posts : 4074
    • Reward points : 0
    • Joined: 2006/01/08 22:18:32
    • Location: San Diego
    • Status: offline
    Re:Compiler C30 V3.23 to V3.30C Trouble 2011/09/13 13:34:03 (permalink)
    0
    cawilkie

    ...This should not happen because we build fflush() and write() into sections that belong together.  Unless you have written your own version of write()?
    ...

    I suppose if someone wants to override the weak version of write() from C30's stdio library, the proper function declaration should be:

    int __attribute__((__section__(".libc")))
    write(int handle, void *buffer, unsigned int len)
    {
        /* user provided code */
    }

    Without the section attribute, the Linker may place the code out of the reach of fflush(). Is my understanding correct? If so, then the prototype for write(), as documented in  16-Bit Language Tools Libraries Section 4.3 should have the section attribute in it.

    #9
    Ajitha
    New Member
    • Total Posts : 13
    • Reward points : 0
    • Joined: 2010/01/13 02:59:38
    • Location: 0
    • Status: offline
    Re:Compiler C30 V3.23 to V3.30C Trouble 2011/09/14 05:37:46 (permalink)
    0
    Thanks guys for your help, especially eskopal and aschen0866 which solve my problem.

    fdan00 your reply is stupid no need answer like that
    #10
    dhenry
    Super Member
    • Total Posts : 4994
    • Reward points : 0
    • Joined: 2003/11/07 12:35:12
    • Location: Colorado
    • Status: offline
    Re:Compiler C30 V3.23 to V3.30C Trouble 2011/09/14 05:57:57 (permalink)
    0
    Ajitha
    fdan00 your reply is stupid no need answer like that

    If you think that one is stupid, here's one even more so:

    http://www.microchip.com/forums/fb.ashx?m=601383
    #11
    cawilkie
    Administrator
    • Total Posts : 1954
    • Reward points : 0
    • Joined: 2003/11/07 12:49:11
    • Status: offline
    Re:Compiler C30 V3.23 to V3.30C Trouble 2011/09/14 09:56:28 (permalink)
    0
    Ajitha

    Thanks guys for your help, especially eskopal and aschen0866 which solve my problem.

    fdan00 your reply is stupid no need answer like that


    I take it then you had redefined 'write' and it was being located too far away?  I like Alan's suggestion and will have the manual updated in either case, but it would be good to know if this was the root cause of your issue.

    Regards
    Calum
    #12
    Jump to:
    © 2017 APG vNext Commercial Version 4.5