[FAQ]MPLink and cinit

Author
HarriL
Senior Member
  • Total Posts : 173
  • Reward points : 0
  • Joined: 2003/11/07 12:38:57
  • Location: Ulvila, Finland
  • Status: offline
2005/07/22 08:12:26 (permalink)
0

MPLink and cinit

Any suggestion how to get rigid of .cinit space reservation in *.map file when I'm not using any idata variables. MPLAB 7.20 and 16F PIC's.

best regards:
Harri
#1

11 Replies Related Threads

    jspaarg
    Super Member
    • Total Posts : 2926
    • Reward points : 0
    • Joined: 2005/05/25 16:47:08
    • Location: PA, now MN via NJ,AZ,OR,CA
    • Status: offline
    RE: MPLink and cinit 2005/07/22 09:37:35 (permalink)
    0
    I could be completely wrong on this, but I believe that cinit requires a minimum of two program memory locations regardless of whether you have any initialized memory.

    Why do you need to get rid of that allocation?
    #2
    HarriL
    Senior Member
    • Total Posts : 173
    • Reward points : 0
    • Joined: 2003/11/07 12:38:57
    • Location: Ulvila, Finland
    • Status: offline
    RE: MPLink and cinit 2005/07/22 09:54:02 (permalink)
    0
    Okay, the last case was 16F877 with short program, .cinit reserves the space from 0x1800...0x1807.

    The programming cycle is much longer because now the ICD2 must go through the memory until 0x1807.

    This is more like an annoying case.

    best regards:
    Harri
    #3
    jspaarg
    Super Member
    • Total Posts : 2926
    • Reward points : 0
    • Joined: 2005/05/25 16:47:08
    • Location: PA, now MN via NJ,AZ,OR,CA
    • Status: offline
    RE: MPLink and cinit 2005/07/22 12:24:09 (permalink)
    0
    Two things:

    I am not familiar with a 16F compiler, only the mcc18 from Microchip.
    What compiler are you using?

    If you are only concerned about the time to program a chip, perhaps you can relocate the cinit section in your linker script file.

    I believe that most compilers put the cinit section into the beginning locations of the first non-protected code area (although I could be wrong).
    #4
    HarriL
    Senior Member
    • Total Posts : 173
    • Reward points : 0
    • Joined: 2003/11/07 12:38:57
    • Location: Ulvila, Finland
    • Status: offline
    RE: MPLink and cinit 2005/07/22 21:17:34 (permalink)
    0
    Sorry, my mistake. If I remove idata type variables from the source also the linker space reservation on area 0x1800 is removed.

    On 0x2000 stays one .cinit (4bytes) for mcu ID-memory variable which is quite correct, it was only confusing me.

    best regards:
    Harri
    #5
    Basstudio
    New Member
    • Total Posts : 19
    • Reward points : 0
    • Joined: 2005/05/24 14:26:05
    • Status: offline
    RE: MPLink and cinit 2006/01/03 15:48:50 (permalink)
    0
    After inspecting the map file for a project I am working on I have just discovered 4-bytes (2-opcodes) allocated as ROMDATA called cinit allocated at the beginning of the first program page. I checked the program memory and found two 'RETLW 0x00'. I have been trying to work out why the linker had created this considering that I have no initialised data sections, therefore I came across this thread.

    Does anyone know why MPLAB/Linker does this?
    Is it a bug/feature in the linker?

    If so it seems strange that Microchip hasn't fixed this problem as uncontrolled memory allocation by the compiler/linker doesn't inspire much confidence.

    I am using a PIC12f683, MPLAB v7.30, relocatable code.
    #6
    Olin Lathrop
    Super Member
    • Total Posts : 7463
    • Reward points : 0
    • Joined: 2004/02/26 17:59:01
    • Location: Littleton Massachusetts
    • Status: offline
    RE: MPLink and cinit 2006/01/03 16:15:29 (permalink)
    0
    Does anyone know why MPLAB/Linker does this? Is it a bug/feature in the linker?

    Yes, this is a well known bug and someone asks about it here every month or so. Think linker creates a two word .CINIT section even when you don't use initialized variables.

    Most of the time it's just an annoyance. If you really need the extra 2 words, for the .CINIT section to some bogus address in the linker file, the post-process the HEX file to get rid of data at that address.

    This has been going on for years, and I don't understand why Microchip hasn't fixed this yet either.
    #7
    xiaofan
    Super Member
    • Total Posts : 6247
    • Reward points : 0
    • Joined: 2005/04/14 07:05:25
    • Location: Singapore
    • Status: offline
    RE: MPLink and cinit 2006/01/13 21:09:17 (permalink)
    0
    Is it really a bug? I do not think it is really a problem.
     
    That being said, the alternative assembler from gputils (gpasm/gplink) does not
    generate the .cinit section. And it is quite usable for PIC12F/16F. For the PIC18F,
    it does not support the new CONFIG directive yet, only the old __CONFIG directive
    is supported.
     
    Regards,
    Xiaofan
    #8
    Guest
    Super Member
    • Total Posts : 80499
    • Reward points : 0
    • Joined: 2003/01/01 00:00:00
    • Location: 0
    • Status: online
    RE: MPLink and cinit 2006/02/21 11:44:39 (permalink)
    0
    If you don't use all four bytes of the reset vector space you could change your linker file to something like this:

    CODEPAGE    NAME=vectors    START=0x0      END=0x1      PROTECTED
    CODEPAGE    NAME=pagex      START=0x2      END=0x3

    SECTION      NAME=PROGX      ROM=pagex                      // Place to put .cinit

    In this example, for a 16F690, the linker will place the .cinit bytes in the 'PROGX/pagex' section, just before the Interrupt vector.

    Cheers,
    Dave
    #9
    MartynJ
    Super Member
    • Total Posts : 290
    • Reward points : 0
    • Joined: 2004/09/08 04:16:16
    • Location: Swindon England
    • Status: offline
    RE: MPLink and cinit 2006/10/30 04:04:20 (permalink)
    0
    The linker generates and populates a table (the '_cinit table') that contains an entry for each initialised data element.

    The table begins with a 16-bit number num_init that stores the number of initialised data element.

    Each table entry has three 32-bit integers that store...

    The from address in ROM
    The to address in idata RAM
    The Size in bytes of the data element.

    (So if there is no IDATA num_init is 16bit 0 )

    Martyn
    #10
    Olin Lathrop
    Super Member
    • Total Posts : 7463
    • Reward points : 0
    • Joined: 2004/02/26 17:59:01
    • Location: Littleton Massachusetts
    • Status: offline
    RE: MPLink and cinit 2006/10/30 05:53:23 (permalink)
    0
    The linker generates and populates a table (the '_cinit table') that contains an entry for each initialised data element.

    Yes, we know why it's there.  The question was how to get rid of it when you're not using initialized variables.
    #11
    MartynJ
    Super Member
    • Total Posts : 290
    • Reward points : 0
    • Joined: 2004/09/08 04:16:16
    • Location: Swindon England
    • Status: offline
    RE: MPLink and cinit 2006/10/30 05:55:14 (permalink)
    0
    I didn't !

    Just making it available to a search on cinit to others not yet in the know


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