• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 56 subscribers
  • Views 2328 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

.cinit entry for a const array in DDR

Vitaliy V.
Prodigy 135 points


Hello,

I'm working on an application for C6678 DSP using the c6000_7.4.2 code generation tools. The application works on a set of data which should be preloaded to the platform. In my case the input data is defined in a header file "input.h" that is included in main.c

the content of "input.h" is:

-----------------------------------------------------------------------------------------
#pragma DATA_SECTION(InputTable, ".dataDDR")
const float InputTable[273600] ={ .............  };
-----------------------------------------------------------------------------------------

This way the data should be stored in the external DDR3 memory of the board

However, when I try to compile the application I get the following linker error:

-----------------------------------------------------------------------------------------
"./configPkg/linker.cmd", line 150: error #10099-D: program will not fit into
   available memory.  placement with alignment fails for section ".cinit" size
   0x10cdf3 .  Available memory ranges:
   LL2SRAM      size: 0x80000      unused: 0x795e6      max hole: 0x794e0  
-----------------------------------------------------------------------------------------

My question is now: why is this array initialized in .cinit? I thought that declaring it "const" would remove its initialization through the .cinit section.

Is there any other way of declaring a const array?


Regards,
Vitaliy


  • 0
    Genius 4590 points

    Hi Vitaliy,

    Do you want to place InputTable in DDR? then make sure that ".dataDDR" points to a DDR section. In your case, it is pointing to LL2SRAM.

  • 0
    Mastermind 6670 points

    Hi,

    Are you using ELF "--rom_model" ?  In this case the compiler have to generates the cinit for the run-time initialization of your data (copy from the rom to the ram).

    You can use the "--ram_model" to remove it and initialize ad load time, that is someone else, for instance CCS when you load or your ELF boot-loader, have to copy the data from the ELF image to the RAM.

    See compiler manual about rom and ram_model.

  • 0 in reply to Alberto Chessa
    Prodigy 135 points

    Hi Alberto,

    Yes I was using "--rom_model". When I switch to the "--ram_model" as you suggested then I can compile.
    Is the ".cinit" always created for "--rom_model"?

    The other solution that I tried, was to move the .cinit section to DDR3. Do you know if there is a considerable performance impact doing so?

    Regards

  • 0 in reply to Vitaliy V.
    Mastermind 6670 points

    Hi,

    Choosing the model depends mainly on how you want to boot your application and where you setup the DDR (and maybe enable cache on it).

    If the cache on the DDR is enable (before the call to the application entry point _c_int00), IMHO placing .cinit into DDR, respect to L2SRAM,  is slower but the impact should not be so considerable, since the .cinit is usually compressed.

    Anyway this depened on the size and compression ratio. If the ratio is low, I suppose it is better to use the ram model.

  • 0 in reply to Alberto Chessa
    TI__Guru* 84285 points

    .cinit is intended to be read once, at boot time, so it is an excellent candidate for placing in slow memory.

  • 0 in reply to Archaeologist
    TI__Guru* 84285 points

    I'm a bit confused here; the compiler ought not to be generating a .cinit record for a const data structure, whether or not --rom_model or --ram_model are used.  Could you please generate and post the linker map file (--map_file)?  Also, are you using EABI (--abi=eabi)?

  • 0 in reply to Archaeologist
    Prodigy 135 points

    Hi,

    my linking command is:

    -mv6600 --abi=eabi -O3 -g --gcc --display_error_number --diag_warning=225 -z -m"app_seq.map" -i"ccsv5/tools/compiler/c6000_7.4.2/lib" -i"ccsv5/tools/compiler/c6000_7.4.2/include" --reread_libs --warn_sections --display_error_number --rom_model

    The map file is attached:

    4722.app_seq.map.txt

  • 0 in reply to Vitaliy V.
    TI__Guru* 84285 points

    Somehow, you've got a data section ".dataDDR" which contains both initialized and uninitialized data, which is not a good thing, as you've seen. If you break those up into subsections, you won't have that problem. For instance, use

    #pragma DATA_SECTION(InputTable, ".dataDDR:InputTable").

    Judging by the size of .dataDDR:init, your .cinit record is not coming from the variable InputTable, but some other variable you've placed in .dataDDR

    Here is the interesting part of the map file:

    .dataDDR   0    80000000    012a8520     
                  80000000    0119d220     main.obj (.dataDDR:uninit) [fill = 0]
                  8119d220    0010b300     main.obj (.dataDDR:init)


LINKER GENERATED COPY TABLES

__TI_cinit_table @ 0010c418 records: 5, size/record: 8, table size: 40
	.dataDDR: load addr=00000000, load size=0010bdef bytes, run addr=80000000, run size=012a8520 bytes, compression=rle
  • 0 in reply to Archaeologist
    Prodigy 135 points

    Thanks for the quick reply.

    Yes, I had some other not const and not initialized arrays in that section, too.
    Now I used a section only for the InputTable and the linking worked.

    So, is it generally not allowed to have const and uninitialized non-const data in the same section?

    Regards,

  • 0 in reply to Vitaliy V.
    TI__Guru* 84285 points

    It's allowed, but it is not a good idea, because you'll usually get a larger .cinit than you really need, which is a waste of memory.