This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Difference between 'load time' & 'run time'



The linker that ships with CCSv4 has an option that causes
variables to be initialized either at 'load time' or at 'run
time.' I have yet to find an explanation of the difference
between these points in time, but using the words themselves
I come up with:

- Run time:  When the processor executes the power-up
             vector, or the same time the system is turned
             on.
- Load time: When load module is transferred into the
             processor.  In an embedded product, this can
             only happen once, in the factory, during the
             programming step.

So I must conclude the manuals really use 'load time' to
refer to the point when the debugger connects to the target
system during testing.  That would mean a segment of my code
never gets exercised until I switch back to 'run time' prior
to release.

This seems like a pure disadvantage to me. What am I
missing?
============================================================
Gary Lynch

  • A description of the initialization models is contained in a section titled System Initialization in the compiler book for your target.  Links to all of those books are located here http://processors.wiki.ti.com/index.php/Before_asking_for_CGT_support#Compiler_User_Guides .  

    Most systems use the run time initialization model.  But there are some systems which include a loader capable of handling the initialization, and those systems use the load time initialization model.  Such systems use less memory, because no memory is required for the initialization tables.  They also save cycles in the boot code, which doesn't have to process the initialization tables.

    Thanks and regards,

    -George

  • I had read all the suggested resources prior to posting.
    This still does not address my fundamental query, so I will
    phrase it another way.

    (I use the TMSC320F2812 and have all the appropriate manuals
    cited.)

    An embedded system ships with volatile memory (RAM) and non-
    volatile memory (which I will lump together as ROM, even as I
    acknowledge the concept is much more complex). Let's say my
    application needs an array of co-efficients to a Taylor
    series approximation of some transcendental function to
    perform its task.
    - I can't store it in the RAM, because the device is
      unpowered during shipment.
    - I am used to environments that put this table in ROM, and
      copy it over at power-up (section 7.8.5 of _TMS320C28x_
       _Optimizing_C/C++_Compiler_v5.0.0_User's_Guide_,
      "Autoinitialization of Variables at Run Time"), and the
      language therein makes perfect sense.

    The next section, 7.8.6, "Initialization of Variables at
    Load Time", explicitly states that "no initialization is
    performed at boot time" and that "A loader (which is not
    part of the compiler package)" must copy my table into RAM.

    To me the "loader" would be indistinguishable from the
    programmer we used to program the device.  It would be able
    to copy co-efficients into the RAM in the factory. When we
    shut it down to ship to the customer, all this is lost, and
    the system arrives at the customer with no table at all
    (unless this loader knows something about the fundamental
    state of matter that I missed in semiconductor theory
    class).

    So I'm afraid as it stands, this option still makes no sense
    to me.
    ============================================================
    Gary Lynch        printf("lynchg%cstacoenergy%ccom", 64, 46)
    ============================================================

  • George,

    We have a TMS320C6726 project is running out of memory (256K IRAM).  I would like to link it with -cr (load time initialization).  We are currently using TI protocol_implement() to load from SPI Flash.

    I build the -cr code.  It runs with load .out file using CCS v4.2.  But when burned into flash, it doesn't run.

    What might be the problem?

    Thanks.

    Regards,

    Steve

  • Gary Lynch said:
    To me the "loader" would be indistinguishable from the
    programmer we used to program the device.

    This is incorrect.  If you link with --ram_model (or -cr), then the presumption is that, at system start time, two things are present: 1)The final .out file exactly as produced by the linker 2) A loader which knows how process that .out file, and the .cinit records contained within it.  This is the case when a system is being developed under CCS.  The CCS loader is the loader mentioned in #2.  However, it not the case in your system.  Few field deployed systems include such a loader.  This is why most systems are linked with --rom_model (or -c).

    Thanks and regards,

    -George

  • Hi George,

    Thanks for the reply.  But it did not answer my question.

    Can our system use "load time initialization" with code burned into FLASH?  If yes, how to do it?

    Thank you.

    Regards,

    Steve

  • I solve also problem with using of load-time initialization in my application. But in my application my itself loader use as input file Intel 86 format generated from .out file by hex2000 utility. But I have suspicion, that output hex file generated by hex2000 never contains CINIT section if input .out file is linked in -cr option. In listing below can be seen that .CINIT section is not translated.

    C:\work\loko_sUIC\proces\work\loko\v8_x_Ram_Debug>hex2000 -i -romwidth 16 loko.out

    Translating to Intel format...

       "loko.out"   ==> internalMemFuncs

       "loko.out"   ==> codestart

       "loko.out"   ==> .hwi_vec

       "loko.out"   ==> .text

       "loko.out"   ==> .econst

       "loko.out"   ==> .bios

       "loko.out"   ==> secureRamFuncs

       "loko.out"   ==> .rtdx_text

       "loko.out"   ==> .sysinit

       "loko.out"   ==> .switch

       "loko.out"   ==> .gblinit

       "loko.out"   ==> .pinit

       "loko.out"   ==> .trcdata

       "loko.out"   ==> .trace

       "loko.out"   ==> .args

    I tried it also with -boot option, but problem is the same, see below.

    C:\work\loko_sUIC\proces\work\loko\v8_x_Ram_Debug>hex2000 -i -boot -romwidth 16 loko.out

    Translating to Intel format...

       "loko.out"   ==> codestart       (BOOT LOAD)

       "loko.out"   ==> internalMemFuncs    (BOOT LOAD)

       "loko.out"   ==> secureRamFuncs        (BOOT LOAD)

       "loko.out"   ==> .args                 (BOOT LOAD)

       "loko.out"   ==> .trace               (BOOT LOAD)

       "loko.out"   ==> .trcdata           (BOOT LOAD)

       "loko.out"   ==> .hwi_vec        (BOOT LOAD)

       "loko.out"   ==> .bios                 (BOOT LOAD)

       "loko.out"   ==> .pinit                (BOOT LOAD)

       "loko.out"   ==> .text                 (BOOT LOAD)

       "loko.out"   ==> .switch            (BOOT LOAD)

       "loko.out"   ==> .gblinit             (BOOT LOAD)

       "loko.out"   ==> .sysinit             (BOOT LOAD)

       "loko.out"   ==> .rtdx_text      (BOOT LOAD)

       "loko.out"   ==> .econst            (BOOT LOAD)

    So is it useable HEX2000 utility, if I  use -cr option during linking proces ?

  • I am going to take one more stab at this debate.

    1.  On a PC/minicomputer/mainframe you have access to:
        - An operating system,
        - A disk drive.

    2.  Tasks/applications loiter on the disk drive until they
        are needed.  As such time, the OS copies them from the
        disk drive to the program memory (which is all RAM: no
        ROM, no flash).  That operation is called 'loading a
        program.'

        At load time, the OS would be able to initialize all
        global variables from tables stored on the disk drive,
        such that it happens invisibly to the compiler/linker
        toolchain.

    Is it possible that people on this forum are using Code
    Composer to build apps for such an environment, and that
    this option is for them alone?

    I never thought of this before because if you have access to
    a disk drive you have a 'memory' 2-3 orders of magnitude
    larger than your program or data space. (Conservation becomes
    much less of an issue.)

    It would also NEVER occur to me to call such a configuration
    an 'embedded system.'

  • SGQ said:
    Can our system use "load time initialization" with code burned into FLASH?

    No.

    Thanks and regards,

    -George