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.

2837xD linker problem error #10099-d



An error occurs even when the section would fit to the desired memory range (at blocks > 0x40, an alignment to the next 0x40 address is made):

in code:

typedef struct
{
  DT_U16 LiveCount;
  DT_U16 Revision;
  DT_U16 RevisionSWMajor;
  DT_U16 RevisionSWMinor;
  DT_U16 RevisionSWMaintenance;
  DT_U16 CpuUsage;
  DT_U16 ForFuture[58];
} CPU2_INFO_VALUES;

#pragma DATA_SECTION(MsgRamCpu2InfoValues,"cpu2_to_1_offs_info");
static volatile CPU2_INFO_VALUES MsgRamCpu2InfoValues;

Problems with linking with this:

CPU2_TO_1_MSGRAM_IM : origin = 0x0003F842, length = 0x40
->

error #10099-D: program will not fit into available memory.  run placement with alignment/blocking fails for section "cpu2_to_1_offs_info" size 0x40 page 1.  Available memory ranges:
   CPU2_TO_1_MSGRAM_IM   size: 0x40         unused: 0x40         max hole: 0x40

Problems with linking with this:

CPU2_TO_1_MSGRAM_IM : origin = 0x0003F842, length = 0x78
->

error #10099-D: program will not fit into available memory.  run placement with alignment/blocking fails for section "cpu2_to_1_offs_info" size 0x40 page 1.  Available memory ranges:
   CPU2_TO_1_MSGRAM_IM   size: 0x78         unused: 0x78         max hole: 0x78

it is ok when:

   CPU2_TO_1_MSGRAM_IM : origin = 0x0003F840, length = 0x40

it builds when:

   CPU2_TO_1_MSGRAM_IM : origin = 0x0003F842, length = 0x80

but it is mapped to address 0003f880 instead of 0003f840:

0003f880    00000040     main.obj (cpu2_to_1_offs_info)

why this alignment to a 0x40 address? I tried 3 different compiler versions (6.4.6, 6.4.9, 6.4.10), always the same problem

  • Hi,

    While placing any object in a section which starts from unaligned page boundary (64 words) and cross over to next page, compile will place that into next page aligned address. In this case your section starts at 0x42 and structure size is big enough to cross over next page hence it's placing it at next page boundary which starts at 0x80.

    If you reduce the no of elements in  "DT_U16 ForFuture[58];" so that total no. of elements in structure does not cross over the page boundary, compiler should place it at correct address.

    Regards,

    Vivek Singh

  • Hi Vivek,
    Thanks for the quick reply.
    Is it possible to telling the compiler not to align to a page?
  • Hi,
    I don't think there is option for that but I'll let some expert from compiler team to provide more detail on that hence moving this post to compiler team.

    Regards,
    Vivek Singh
  • lindi said:
    Is it possible to telling the compiler not to align to a page?

    Yes.  If you build with the flag --disable_dp_load_opt, then blocking is not used.  However, this can cause your performance to degrade and your code size to increase.  That is because it also means the compiler may need to issue more instructions to load the DP register than otherwise.

    Thanks and regards,

    -George

  • Please note that there is currently a bug in the compiler that causes the --disable_dp_load_opt flag to not disable blocking for data that is not assigned to a user-defined section.  That is, using the flag but leaving the default assignment of global data to .ebss will cause the data to still be blocked by data page.  In both cases, the flag prevents the compiler from optimizing away DP loads (DP loads will be inserted prior to each direct memory access), potentially causing a performance degradation.  Therefore, if the flag is used, data must be assigned to a user-defined section with either the #pragma DATA_SECTION or #pragma SET_DATA_SECTION pragmas.