Complex LCF with UNION's and copy TABLE's

Christian Herget

Hi,
I try to write a application where I have to copy three different algorithms in the RAM, to safe RAM I like to use UNION's to allocate the RAM three times.

Each algo consists out of different functions, one function will be used in two algos.

I wrote the following LCF, which works:

    UNION : run=RAM
   {
        GROUP : table(__SetActiveBank_Table), load=FLASH0
        {
           .text:Fapi_setActiveFlashBank      : {} palign=8
           .text:_scaleEEFclk                 : {} palign=8
           .text:_scaleMainFclk               : {} palign=8
       }

       GROUP :
       {
           UNION :
           {
               GROUP : load=FLASH0, table(__ProgrammFlash_Table)
               {
                   .flashBytesWithEcc                 : {} palign=8
                   .text:Fapi_issueProgrammingCommand : {} palign=8
                   .text:Fapi_calculateEcc            : {} palign=8
               }

               GROUP : table(__EraseSector_Table), load=FLASH0
               {
                   .flashEraseSector                       : {} palign=8
                   .text:Fapi_issueAsyncCommandWithAddress : {} palign=8
               }
           }

           .text:_Fapi_issueFsmCommand        : {} palign=8, load=FLASH0, table(__issueFsmCommand_Table)
       }
    }

Then I tried to get rid of the copy TABLE(__issueFsmCommand_) and replaced it by table(__ProgrammFlash_Table), table(__EraseSector_Table).

Now the Linker gives me the following warnings:

"../sys_link.cmd", line 96: warning #10110-D: table(__EraseSector_Table)
   operator ignored: table(__EraseSector_Table) has already been applied to a
   section in the UNION "UNION_1" in which ".text:_Fapi_issueFsmCommand" is a
   descendant
"../sys_link.cmd", line 96: warning #10110-D: table(__ProgrammFlash_Table)
   operator ignored: table(__ProgrammFlash_Table) has already been applied to
   a section in the UNION "UNION_1" in which ".text:_Fapi_issueFsmCommand" is a
   descendant

And the resulting tables don't contain: .text:_Fapi_issueFsmCommand

Combining these would help to make the application less complex as it would save some calls of copy_in().

Is there a reason why I can't combine a GROUP member and UNION members in one COPY table, or is this a bug?

Thanks,
Christian

over 11 years ago

0 George Mock over 11 years ago

TI__Guru**** 250440 points

Every member of a UNION must have a separate copy table. The linker does not support somehow combining copy tables together.

Thanks and regards,

-George

0 Archaeologist over 11 years ago

TI__Guru* 84285 points

I took a look at this test case and I think it's a reasonable use case. However, it's not a bug, because the linker works as designed. I've submitted SDSCM00050128 as an enhancement request to add this feature.

Abbreviated, the user wants to do this:

    UNION("outer")
    {
        GROUP
        {
        }

        GROUP("X")
        {
            UNION
            {
                GROUP : table(tableB)
                {
                }

                GROUP : table(tableC)
                {
                }
            }

            .something: table(tableB), table(tableC)
        }
    }

It doesn't matter that tableB and tableC are re-used under UNION("outer"), because GROUP("X") ensures that they cannot overlap.

0 Christian Herget over 11 years ago in reply to Archaeologist

TI__Expert 6985 points

Thanks for looking into this.

As of today none of my customers is requesting this feature, but I would wonder if nobody else has or would like to do this type of function overlapping.

Best Regards,
Christian

0 Archaeologist over 11 years ago in reply to Christian Herget

TI__Guru* 84285 points

It's not extremely surprising this issue hasn't come up before. It requires both nested overlays and re-used table names; the overhead for keeping separate tables is relatively small, so the workaround is feasible.

0 Christian Herget over 11 years ago in reply to Archaeologist

TI__Expert 6985 points

Hi,

I verified the changed behavior with the TI ARM CGT 5.1.6 and 5.2.0A14136, both linker versions are now able to handle my use case correctly.

Thanks,
Christian

0 Archaeologist over 11 years ago in reply to Christian Herget

TI__Guru* 84285 points

That should not be possible. The enhancement was only added to the 5.2.0A branch, not the 5.1.x branch. Are you positive you were using 5.1.6 when you tested it?

0 Christian Herget over 11 years ago in reply to Archaeologist

TI__Expert 6985 points

Yes, I'm sure.
I was also a little bit surprised that this now works with 5.1.6.

Here is the extract from the MAP file:

******************************************************************************
TI ARM Linker PC v5.1.6
******************************************************************************
>> Linked Tue May 20 08:28:55 2014

...

__ProgrammFlash_Table @ 00008cb0 records: 4, size/record: 12, table size: 52
   .flashBytesWithEcc: load addr=00000020, load size=00000100, run addr=080016a0, run size=00000100, compression=none
   .text:Fapi_issueProgrammingCommand: load addr=00000120, load size=00000168, run addr=080017a0, run size=00000168, compression=none
   .text:Fapi_calculateEcc: load addr=00000288, load size=00000018, run addr=08001908, run size=00000018, compression=none
   .text:_Fapi_issueFsmCommand: load addr=000004e0, load size=00000040, run addr=080019c0, run size=00000040, compression=none

__EraseSector_Table @ 00008ce4 records: 3, size/record: 12, table size: 40
   .flashEraseSector: load addr=00000440, load size=00000070, run addr=08001920, run size=00000070, compression=none
   .text:Fapi_issueAsyncCommandWithAddress: load addr=000004b0, load size=00000030, run addr=08001990, run size=00000030, compression=none
   .text:_Fapi_issueFsmCommand: load addr=000004e0, load size=00000040, run addr=080019c0, run size=00000040, compression=none

Best Regards,
Christian

Code Composer Studio™︎

Code Composer Studio forum

Complex LCF with UNION's and copy TABLE's