• AVR Freaks

Hot!error: (1347)

Page: 12 > Showing page 1 of 2
Author
Andy_Taiwanese
Super Member
  • Total Posts : 508
  • Reward points : 0
  • Joined: 2014/12/19 02:59:38
  • Location: 0
  • Status: offline
2018/01/29 00:24:32 (permalink)
0

error: (1347)

Hi, there. I got to add new features to my previous project, and output window shows a bunch of:
:0: error: (1347) can't find 0x7C words (0x7c withtotal) for psect "text30" in class "CODE" (largest unused contiguous range 0x47)
:0: error: (1347) can't find 0x6E words (0x6e withtotal) for psect "maintext" in class "CODE" (largest unused contiguous range 0x47)
:0: error: (1347) can't find 0x69 words (0x69 withtotal) for psect "text24" in class "CODE" (largest unused contiguous range 0x47)
:0: error: (1347) can't find 0x66 words (0x66 withtotal) for psect "text17" in class "CODE" (largest unused contiguous range 0x47)
:0: error: (1347) can't find 0x4A words (0x4a withtotal) for psect "text33" in class "CODE" (largest unused contiguous range 0x47)
:0: error: (1347) can't find 0x3B words (0x3b withtotal) for psect "text8" in class "CODE" (largest unused contiguous range 0x8)
:0: error: (1347) can't find 0x3A words (0x3a withtotal) for psect "text20" in class "CODE" (largest unused contiguous range 0x8)
:0: error: (1347) can't find 0x37 words (0x37 withtotal) for psect "text3" in class "CODE" (largest unused contiguous range 0x8)
:0: error: (1347) can't find 0x36 words (0x36 withtotal) for psect "text4" in class "CODE" (largest unused contiguous range 0x8)
:0: error: (1347) can't find 0x31 words (0x31 withtotal) for psect "text5" in class "CODE" (largest unused contiguous range 0x8)
:0: error: (1347) can't find 0x28 words (0x28 withtotal) for psect "text1" in class "CODE" (largest unused contiguous range 0x8)
:0: error: (1347) can't find 0x28 words (0x28 withtotal) for psect "text43" in class "CODE" (largest unused contiguous range 0x8)
:0: error: (1347) can't find 0x27 words (0x27 withtotal) for psect "text29" in class "CODE" (largest unused contiguous range 0x8)
:0: error: (1347) can't find 0x24 words (0x24 withtotal) for psect "text40" in class "CODE" (largest unused contiguous range 0x8)
:0: error: (1347) can't find 0x22 words (0x22 withtotal) for psect "text18" in class "CODE" (largest unused contiguous range 0x8)
:0: error: (1347) can't find 0x22 words (0x22 withtotal) for psect "text39" in class "CODE" (largest unused contiguous range 0x8)
:0: error: (1347) can't find 0x22 words (0x22 withtotal) for psect "text41" in class "CODE" (largest unused contiguous range 0x8)
:0: error: (1347) can't find 0x21 words (0x21 withtotal) for psect "text38" in class "CODE" (largest unused contiguous range 0x8)
:0: error: (1347) can't find 0x20 words (0x20 withtotal) for psect "text9" in class "CODE" (largest unused contiguous range 0x8)
:0: error: (1347) can't find 0x1C words (0x1c withtotal) for psect "text35" in class "CODE" (largest unused contiguous range 0x8)
:0: error: (1347) can't find 0x1B words (0x1b withtotal) for psect "stringtext1" in class "STRCODE" (largest unused contiguous range 0x8)
:0: error: (1347) can't find 0x19 words (0x19 withtotal) for psect "text31" in class "CODE" (largest unused contiguous range 0x8)
:0: error: (1347) can't find 0x19 words (0x19 withtotal) for psect "text42" in class "CODE" (largest unused contiguous range 0x8)
:0: error: (1347) can't find 0x18 words (0x18 withtotal) for psect "text6" in class "CODE" (largest unused contiguous range 0x8)
:0: error: (1347) can't find 0x18 words (0x18 withtotal) for psect "text7" in class "CODE" (largest unused contiguous range 0x8)
:0: error: (1347) can't find 0x16 words (0x16 withtotal) for psect "text13" in class "CODE" (largest unused contiguous range 0x8)
:0: error: (1347) can't find 0x12 words (0x12 withtotal) for psect "swtext2" in class "CONST" (largest unused contiguous range 0x8)
:0: error: (1347) can't find 0x11 words (0x11 withtotal) for psect "text36" in class "CODE" (largest unused contiguous range 0x8)
:0: error: (1347) can't find 0x10 words (0x10 withtotal) for psect "text44" in class "CODE" (largest unused contiguous range 0x8)
:0: error: (1347) can't find 0xE words (0xe withtotal) for psect "swtext3" in class "CONST" (largest unused contiguous range 0x8)

 
After reading XC8 user guide, I think it's because the device is out of memory(both program and data maybe?), now I need to find why and a way to fix it.
 
As far as I know, if there are two or more snippet code doing the same thing, there is only on instance in the memory, i.e.:
the function below does plus.
int func(int a, int b)
{
    return (a+b);
}

 
If there are two or more function calls to this function in the program, there is only one snippet machine code in the memory.
 
Does this rule apply to XC8 with no optimization? I tried an experiment, it seems it's not the case.
 
Is there any solution to fix this error?(I prefer not to optimize the compiler, because sometimes the program flow is wrong)
#1

22 Replies Related Threads

    du00000001
    Just Some Member
    • Total Posts : 2890
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: online
    Re: error: (1347) 2018/01/29 02:06:05 (permalink)
    +1 (1)
    Please share your "little experiment" with us !

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #2
    Sobottech
    Super Member
    • Total Posts : 253
    • Reward points : 0
    • Joined: 2015/12/02 03:32:17
    • Location: 0
    • Status: offline
    Re: error: (1347) 2018/01/29 04:29:32 (permalink)
    #3
    qɥb
    Monolothic Member
    • Total Posts : 3332
    • Reward points : 0
    • Joined: 2017/09/09 05:07:30
    • Location: Jupiter
    • Status: offline
    Re: error: (1347) 2018/01/29 04:48:37 (permalink)
    +1 (1)
    Andy_Taiwanese
    ...After reading XC8 user guide, I think it's because the device is out of memory(both program and data maybe?), now I need to find why and a way to fix it.

    All the errors are for "code" or "const", so you have run out of FLASH memory.
     

    As far as I know, if there are two or more snippet code doing the same thing, there is only on instance in the memory, i.e.:
    the function below does plus.
    int func(int a, int b)
    {
        return (a+b);
    }


    Correct, the function will occur once, and be called from different place.
     

    If there are two or more function calls to this function in the program, there is only one snippet machine code in the memory.

    Yes, UNLESS one call is from non-interrupt code, and one call is from inside an interrupt service routine.
    In that instance, XC8 has to make a second copy of the whole function.
     

    Does this rule apply to XC8 with no optimization? I tried an experiment, it seems it's not the case.

    You are mistaken, so it's something wrong with how you did this test. As du00000001 says, we can probably point out why if you reveal how you did this test.
     

    Is there any solution to fix this error?(I prefer not to optimize the compiler, because sometimes the program flow is wrong)

    You mean the program flow is not how you would expect. It still follows the rules of C, and will give the correct result, it's just harder to see intermediate results when you're debugging.


     

    This forum is mis-configured so it only works correctly if you access it via https protocol.
    The Microchip website links to it using http protocol. Will they ever catch on?
    PicForum "it just works"
    #4
    qɥb
    Monolothic Member
    • Total Posts : 3332
    • Reward points : 0
    • Joined: 2017/09/09 05:07:30
    • Location: Jupiter
    • Status: offline
    Re: error: (1347) 2018/01/29 04:50:23 (permalink)
    +3 (3)
    n.b. with XC8, you can always inspect the .LST file output by the compiler to see exactly what the compiled machine code is doing.
     

    This forum is mis-configured so it only works correctly if you access it via https protocol.
    The Microchip website links to it using http protocol. Will they ever catch on?
    PicForum "it just works"
    #5
    COSMOTRON
    electronic engineer
    • Total Posts : 3
    • Reward points : 0
    • Joined: 2018/02/23 18:21:07
    • Location: 0
    • Status: offline
    Re: error: (1347) 2018/11/14 13:10:34 (permalink)
    0
    Hi, I have same error when i trie printf a float whith PIC16F15325
    #6
    NKurzman
    A Guy on the Net
    • Total Posts : 17610
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: offline
    Re: error: (1347) 2018/11/14 13:53:12 (permalink)
    +1 (1)
    That is a 7K word part floats and Printf() do take up alot of space. 
    #7
    AlanMcR
    New Member
    • Total Posts : 9
    • Reward points : 0
    • Joined: 2018/07/26 10:42:22
    • Location: 0
    • Status: offline
    Re: error: (1347) 2019/04/17 11:33:27 (permalink)
    0
    How about the opposite error? 
    Here I'm trying to place 0x24 words into a space of 0x15D.  Still no-go?!?
    :0:: error: (1347) can't find 0x24 words (0x24 withtotal) for psect "mathTables" in class "CODE" (largest unused contiguous range 0x15D)
    Anyone have an explanation for that?
     
     
    #8
    qhb
    Superb Member
    • Total Posts : 9998
    • Reward points : 0
    • Joined: 2016/06/05 14:55:32
    • Location: One step ahead...
    • Status: offline
    Re: error: (1347) 2019/04/17 15:31:32 (permalink)
    +1 (1)
    Which device?
    Which version compiler?
    It would be useful to include the entire log.
     

    Nearly there...
    #9
    jack@kksound
    code tags!
    • Total Posts : 3201
    • Reward points : 0
    • Joined: 2014/05/14 10:03:19
    • Location: 0
    • Status: offline
    Re: error: (1347) 2019/04/17 15:48:57 (permalink)
    +1 (1)
    Anyone have an explanation for that?

    Yes I am sure someone does have an explanation however as already stated by providing more information (more context) you will get a better "explanation". My guess: You have a whole list of error messages before the one you shared.
    #10
    AlanMcR
    New Member
    • Total Posts : 9
    • Reward points : 0
    • Joined: 2018/07/26 10:42:22
    • Location: 0
    • Status: offline
    Re: error: (1347) 2019/04/17 16:04:38 (permalink)
    0
    12F1572, v5.05
    Note that I can allocate an array at the desired code space in C.  The space is created and left blank, as requested. However if I instead try to assign the very same space in assembly with a PSECT, it fails. (Yes, I took out the C declaration).
     
    The relevant build output, I cut it off at the failure.
     
    make -f nbproject/Makefile-default.mk SUBPROJECTS= .build-conf
    make[1]: Entering directory 'C:/Users/310217025/OneDrive/MyDocuments/Projects/Lumileds/Casambi/SparseGrid+Customizable.X'
    make  -f nbproject/Makefile-default.mk dist/default/production/SparseGrid_Customizable.X.production.hex
    make[2]: Entering directory 'C:/Users/310217025/OneDrive/MyDocuments/Projects/Lumileds/Casambi/SparseGrid+Customizable.X'
    "C:\Program Files (x86)\Microchip\xc8\v2.00\bin\xc8-cc.exe"  -mcpu=12F1572 -c  -fno-short-double -fno-short-float -O1 -fasmfile -maddrqual=ignore -xassembler-with-cpp -Wa,-a -DXPRJ_default=default  -msummary=-psect,-class,+mem,-hex,-file  -ginhx032 -Wl,--data-init -mno-keep-startup -mno-osccal -mno-resetbits -mno-save-resetbits -mno-download -mno-stackcall   -std=c99 -gdwarf-3 -mstack=compiled:auto:auto     -o build/default/production/DesatRGBMain.p1 DesatRGBMain.c
    "C:\Program Files (x86)\Microchip\xc8\v2.00\bin\xc8-cc.exe" -c  -mcpu=12F1572  -fno-short-double -fno-short-float -O1 -fasmfile -maddrqual=ignore -xassembler-with-cpp -Wa,-a -DXPRJ_default=default  -msummary=-psect,-class,+mem,-hex,-file  -ginhx032 -Wl,--data-init -mno-keep-startup -mno-osccal -mno-resetbits -mno-save-resetbits -mno-download -mno-stackcall -std=c99 -gdwarf-3 -mstack=compiled:auto:auto   -o build/default/production/ColorPoints.o  ColorPoints.s
    "C:\Program Files (x86)\Microchip\xc8\v2.00\bin\xc8-cc.exe"  -mcpu=12F1572 -Wl,-Map=dist/default/production/SparseGrid_Customizable.X.production.map  -DXPRJ_default=default  -Wl,--defsym=__MPLAB_BUILD=1  -fno-short-double -fno-short-float -O1 -fasmfile -maddrqual=ignore -xassembler-with-cpp -Wa,-a -msummary=-psect,-class,+mem,-hex,-file  -ginhx032 -Wl,--data-init -mno-keep-startup -mno-osccal -mno-resetbits -mno-save-resetbits -mno-download -mno-stackcall -std=c99 -gdwarf-3 -mstack=compiled:auto:auto      -Wl,--memorysummary,dist/default/production/memoryfile.xml -o dist/default/production/SparseGrid_Customizable.X.production.elf  build/default/production/DesatRGBMain.p1 build/default/production/Flash.p1 build/default/production/Communications.p1 build/default/production/Tables.o build/default/production/ColorPoints.o     
    Flash.c:16:: warning: (520) function "_flashReadConfig" is never called
    Flash.c:39:: warning: (520) function "_flashReadBlock" is never called
    Flash.c:135:: warning: (520) function "_heFlashReadByte" is never called
    Flash.c:41:: warning: (1498) pointer (flashReadBlock@buffer) in expression may have no targets
    :0:: error: (1347) can't find 0x1F0 words (0x1f0 withtotal) for psect "colorPoints" in class "CODE" (largest unused contiguous range 0x5DE)
    Non line specific message::: advisory: (1493) updated 32-bit floating-point routines might trigger "can't find space" messages appearing after updating to this release; consider using the smaller 24-bit floating-point types
    (908) exit status = 1
     
    Also, I'm not using any floating point.
    post edited by AlanMcR - 2019/04/17 16:06:37
    #11
    mad_c
    Super Member
    • Total Posts : 1191
    • Reward points : 0
    • Joined: 2010/12/12 17:48:27
    • Location: Brisbane, Australia
    • Status: offline
    Re: error: (1347) 2019/04/17 16:26:59 (permalink)
    +2 (2)
    AlanMcR
    12F1572, v5.05
    Note that I can allocate an array at the desired code space in C.  The space is created and left blank, as requested. However if I instead try to assign the very same space in assembly with a PSECT, it fails. (Yes, I took out the C declaration).

     
    Psects can have all sorts of limitation as to where they can be linked. How did you define the psect?
     
    Jeff.
    #12
    AlanMcR
    New Member
    • Total Posts : 9
    • Reward points : 0
    • Joined: 2018/07/26 10:42:22
    • Location: 0
    • Status: offline
    Re: error: (1347) 2019/04/17 16:40:23 (permalink)
    0
    Ah, should have posted that:
    PSECT colorPoints,class=CODE,local,noexec,pure,optim=,reloc=0xbf0,delta=2
    GLOBAL _colorPoints
    _colorPoints
    (followed by 0x200 words of DW data.)

     
    If I leave out the reloc=0xbf0, then the correct sized table will be linked in, just not in the correct place.  Clearly the space is available.

    This is the same location (in words vs. bytes) as the C declaration that does work.  While the declaration is char, each char takes up a full word, so the same space is allocated.
    const char colorPoints[0x200] __at(0x5F8);
     
    So, in summary, the space is available, even the error message acknowledges that.  However, it refuses to put the table where I want it when I try to force things with assembly. 
     
    Any hints greatly appreciated!
    #13
    NKurzman
    A Guy on the Net
    • Total Posts : 17610
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: offline
    Re: error: (1347) 2019/04/17 17:23:22 (permalink)
    +1 (1)
    So you are forcing things to be a Locations of your Choosing? 
    The linker seems to have an issue with you choice of location.  Is there a reason you need it there?
    Is it in the Middle somewhere? The linker may not work around your block.
    #14
    AlanMcR
    New Member
    • Total Posts : 9
    • Reward points : 0
    • Joined: 2018/07/26 10:42:22
    • Location: 0
    • Status: offline
    Re: error: (1347) 2019/04/17 18:17:04 (permalink)
    0
    That is why I wrote the C equivalent.  The linker has no problem forcing a huge block in that same spot when it is called for by the C compiler, just not the assembler.  I definitely want it there in that location.  The table will get burned with custom data on a per-product basis. There will be many versions of code too.  I don't want the table moving around based on the compiler/linker's whims.  So, jamming the table up against the end of memory seems like the best choice. 
    Oh, and the reason for doing it in assembly is that I can load the table with 14bit words.  C won't let me do that.  I'm using every possible resource on this chip. 
     
    I did just find one defect in my logic: It appears that the HE flash portion (0x780-0x7ff) only allows 8 bit word writes, even though the locations are 14 bits.  So that require shifting my table a bit further away from the memory boundary. 
    #15
    qhb
    Superb Member
    • Total Posts : 9998
    • Reward points : 0
    • Joined: 2016/06/05 14:55:32
    • Location: One step ahead...
    • Status: offline
    Re: error: (1347) 2019/04/17 20:34:58 (permalink)
    +2 (2)
    My understanding is that all 14 bits are there, but the upper 6 bits are just normal FLASH, not HEF.
     

    Nearly there...
    #16
    mad_c
    Super Member
    • Total Posts : 1191
    • Reward points : 0
    • Joined: 2010/12/12 17:48:27
    • Location: Brisbane, Australia
    • Status: offline
    Re: error: (1347) 2019/04/22 13:24:37 (permalink)
    +2 (2)
    AlanMcR
    Ah, should have posted that:
    PSECT colorPoints,class=CODE,local,noexec,pure,optim=,reloc=0xbf0,delta=2
    GLOBAL _colorPoints
    _colorPoints
    (followed by 0x200 words of DW data.)

     
    If I leave out the reloc=0xbf0, then the correct sized table will be linked in, just not in the correct place.  Clearly the space is available.

    You should read the User's Guide as to what all those psect flags mean. The reloc flag asks the linker to place the psect anywhere on a multiple of the address specified, but that must be a power of two. If all you want to do is link the psect at an address, then that is done via a compiler driver option.
     
    -Wl,-pcolorPoints=0BF0h
     
    for example.
     
    Jeff.
     
     
    post edited by mad_c - 2019/04/22 13:28:54
    #17
    cobusve
    Super Member
    • Total Posts : 493
    • Reward points : 0
    • Joined: 2012/04/02 16:15:40
    • Location: Chandler
    • Status: offline
    Re: error: (1347) 2019/04/22 14:26:31 (permalink)
    +1 (1)
    There are all kinds of other limitations which could be at play. For example you are allocating a single variable which is larger than 1 page of memory.
     
    If you are using C you can only do that for global variables, not local ones or the space would not be found. I would not be surprized if your problem is related to the bank size.
     

    Also take a look at https://www.microforum.cc/ - a great resource for information on PIC and AVR microcontrollers and embedded programming in general. You can also post questions to the experts there.
    #18
    AlanMcR
    New Member
    • Total Posts : 9
    • Reward points : 0
    • Joined: 2018/07/26 10:42:22
    • Location: 0
    • Status: offline
    Re: error: (1347) 2019/04/22 14:28:05 (permalink)
    0
    Jeff,
    Thanks for chiming in.  You are correct about the "multiple of two" aspect of reloc,  not sure how I skimmed over that. 
     
    I just tried your very helpful suggestion. When added as an "Additional options" for the compiler, I can see the option specified in the output, but it has no effect on psect placement. 
    When added as an "Additional options" for the linker itself, the linker errors out:
    :0:: error: (450) psect "colorPoints" was never defined, or is local
    Not sure what to make of that since the psect is defined and functioning fine as long as I don't add the option.  
     
    Now, if I define the array in C like this:
    const char __section("colorPoints") colorPoints[0x200];
    Then that same linker option works just great, but I can already do that more easily in C with this:
    const char colorPoints[0x200] __at(0x5F8); (requiring no additional linker options)
     
    My original problem is still with me.  I need to specify a psect in a particular location, 0bf0h, and load 0x200 words in that location, all in assembly (because of the 14bit problem).  That still eludes me.  There is probably something obvious that I'm missing.
    I guess I could:
    1) define in C, leaving the table empty
    2) edit .hex files to merge in a properly formed table
    3) burn the .hex files.
    That seems really clumsy and makes debugging a nightmare.
     
    Any thoughts appreciated, as always.
     
    ...Alan
    #19
    mad_c
    Super Member
    • Total Posts : 1191
    • Reward points : 0
    • Joined: 2010/12/12 17:48:27
    • Location: Brisbane, Australia
    • Status: offline
    Re: error: (1347) 2019/04/22 20:36:18 (permalink)
    +1 (1)
    AlanMcR
    I just tried your very helpful suggestion. When added as an "Additional options" for the compiler, I can see the option specified in the output, but it has no effect on psect placement.

    Correct. Added here, that option would never be passed to the linker, so have no effect.

    When added as an "Additional options" for the linker itself, the linker errors out:
    :0:: error: (450) psect "colorPoints" was never defined, or is local
    Not sure what to make of that since the psect is defined and functioning fine as long as I don't add the option.

    Again correct. You have used the local flag with the psect, so you can't link the psect using that option. Remove the local flag. I suspect you do not need it.

    Now, if I define the array in C like this:
    const char __section("colorPoints") colorPoints[0x200];
    Then that same linker option works just great, but I can already do that more easily in C with this:
    const char colorPoints[0x200] __at(0x5F8); (requiring no additional linker options)

    Defining this object in C would be a safer way to do this, but using psects can be made to work.
     
    Jeff
    #20
    Page: 12 > Showing page 1 of 2
    Jump to:
    © 2019 APG vNext Commercial Version 4.5