TMS320F28379D: Understanding the generated HEX file when ALIGN(8) present in linker command file

Wei Fan

Part Number: TMS320F28379D

Hey folks,

I generated intel hex file for my application on 28379d device.

the section paragraph in my linker command file looks like this:

SECTIONS
{
   /* Allocate program areas: */
   .cinit              : > FLASHB | FLASHC      PAGE = 0, ALIGN(8)
   .text               : >> FLASHB | FLASHC | FLASHD | FLASHE      PAGE = 0, ALIGN(8)
   codestart           : > APP_START       PAGE = 0, ALIGN(8)
   /* Allocate uninitalized data sections: */
   .stack              : > RAMM1       PAGE = 1
   .switch             : > FLASHB      PAGE = 0, ALIGN(8)
   .reset              : > RESET,      PAGE = 0, TYPE = DSECT /* not used, */

#if defined(__TI_EABI__)
   .init_array         : > FLASHB | FLASHC,       PAGE = 0,       ALIGN(8)
   .bss                : > RAMLS4LS5,       PAGE = 1
   .bss:output         : > RAMLS4LS5,       PAGE = 1
   .bss:cio            : > RAMLS4LS5,       PAGE = 1
   .data               : > RAMLS4LS5,       PAGE = 1
   .sysmem             : > RAMLS4LS5,       PAGE = 1
   /* Initalized sections go in Flash */
   .const              : > FLASHF,       PAGE = 0,       ALIGN(8)
#else
   .pinit              : > FLASHB,       PAGE = 0,       ALIGN(8)
   .ebss               : >> RAMLS4LS5 | RAMGS0 | RAMGS1,    PAGE = 1
   .esysmem            : > RAMLS4LS5,       PAGE = 1
   .cio                : > RAMLS4LS5,       PAGE = 1
   /* Initalized sections go in Flash */
   .econst             : >> FLASHF      PAGE = 0, ALIGN(8)
#endif

//   Filter_RegsFile     : > RAMGS0,	   PAGE = 1

//   SHARERAMGS0		: > RAMGS0,		PAGE = 1
//   SHARERAMGS1		: > RAMGS1,		PAGE = 1
//   SHARERAMGS2		: > RAMGS2,		PAGE = 1
//   ramgs0           : > RAMGS0,     PAGE = 1
//   ramgs1           : > RAMGS1,     PAGE = 1


#ifdef __TI_COMPILER_VERSION__
    #if __TI_COMPILER_VERSION__ >= 15009000
        #if defined(__TI_EABI__)
        GROUP
        {
            .TI.ramfunc
            {
            -l sfra_f32_tmu_eabi.lib   
            }
            ramfuncs
            isrcodefuncs
        }                        LOAD = FLASHD,
                                 RUN = RAMLS0LS1LS2LS3,
                                 LOAD_START(RamfuncsLoadStart),
                                 LOAD_SIZE(RamfuncsLoadSize),
                                 LOAD_END(RamfuncsLoadEnd),
                                 RUN_START(RamfuncsRunStart),
                                 RUN_SIZE(RamfuncsRunSize),
                                 RUN_END(RamfuncsRunEnd),
                                 PAGE = 0, ALIGN(8)
        #else
            .TI.ramfunc : {} LOAD = FLASHD,
                             RUN = RAMLS0LS1LS2LS3,
                             LOAD_START(_RamfuncsLoadStart),
                             LOAD_SIZE(_RamfuncsLoadSize),
                             LOAD_END(_RamfuncsLoadEnd),
                             RUN_START(_RamfuncsRunStart),
                             RUN_SIZE(_RamfuncsRunSize),
                             RUN_END(_RamfuncsRunEnd),
                             PAGE = 0, ALIGN(8)
        #endif
    #else
   ramfuncs            : LOAD = FLASHD,
                         RUN = RAMLS0,
                         LOAD_START(_RamfuncsLoadStart),
                         LOAD_SIZE(_RamfuncsLoadSize),
                         LOAD_END(_RamfuncsLoadEnd),
                         RUN_START(_RamfuncsRunStart),
                         RUN_SIZE(_RamfuncsRunSize),
                         RUN_END(_RamfuncsRunEnd),
                         PAGE = 0, ALIGN(8)
    #endif

#endif

...

}

As can be seen, ALIGN(8) is used for every appearance of allocations in FLASH.

And I used the hex utility to let CCS12 auto generate the hex output, use intel format

but when I check the intel hex files generated, for example my app.hex, it shows like:

:020000040008F2 (first line, significant of starting address is 0x0008)

...

:2064B60076FFE200E200E201E202E203E204E205E206E207E606FE2956290276025600FFE2

so, according to the intel format definision, it indicates starting at adress of 000864B6, the hex image data is 76.... etc.

The address 000864B6 is in the FLASH section D. Apparently this start address is not aligned to 128bit boundary. But I assure that the FLASHD is set to be ALIGN(8) everywhere in the .cmd file.

According to the spnu629a documentation,

My understanding is with the ALIGN(4) or (8), the content in the flash section should be aligned to 64-bit or 128-bit segments, respectively, which is to say, with ALIGN(8), the address of the generated image hex should always start at xxx8 or xxx0 in the flash memory, but I doubt my understanding based on this observation.

Could you provide some advice on what I am missing? or is there a way to force the hex file generated to be always starting at xxx8 / xxx0 which is 128 bit aligned, for the simpleness of flash operation.

Appreciate for the help.

Regards,

Wei

6 months ago

0 Ki 5 months ago

TI__Guru**** 435311 points

Hello,

I will bring this thread to the attention of the compiler experts. They will be able to assist further.

Thanks

0 George Mock 5 months ago

TI__Guru**** 239995 points

Every line in the Intel format hex output contains the address for the data on that line. But that does not mean the line corresponds to the start of a section. In fact, only a few lines in the hex output correspond to the start of a section. The rest do not.

To see the start address for each section, inspect the linker map file.

Wei Fan said:
is there a way to force the hex file generated to be always starting at xxx8 / xxx0 which is 128 bit aligned

No. This post has shown why that is not necessary.

Thanks and regards,

-George

0 Wei Fan 5 months ago in reply to George Mock

Prodigy 160 points

I agree that only a few lines in the hex corresponds to start of section which is apparent.

I think my observation descirbed in my ticket is, in the intel hex output, majority of the line start address is 128-bit aligned, wihich is to say, it starts at address of xxx8 or xxx0, but not always.

And for the lines starting at a non-128bit-align address, if look closely in the memory map, it can be seen that actually there is no discontinuity in the memory, which raise a question why for me.

Here are some pictures to better illustrate:

lines from intel hex file:

actually all the lines from line 1 to above the one I highlighted (64B6), the start address of them are xxx0 (or xxx8 in some case not able to be shown here). While in line 695, it has a start address of 64B6 which is not 128-bit aligned.

and the corresponding memory map at this address is:

apparently, there is no discountinuity in the memory here.

For sure I believe there is certain reason or rule for the intel hex generation, that may be far beyond what I need to know to work on my application. It just makes me curious that, why the intel hex file generator has to do this -- considering the hex file is to describe the memory map, and there are different options to do it. in this case, why the generator choose to "leave the 64B0 line not full, while purposely start a new line, starting at 64B6, to continue put the hex numbers after", even there is no discontinuity in the memoy map. Why not just "put 64B0 a full line of hex numbers, and continue on 64C0", as the lines above mostly follow this pattern.

Look forward to further advice.

Regards,

Wei

0 George Mock 5 months ago in reply to Wei Fan

TI__Guru**** 239995 points

Please attach the linker map file, not a screenshot, to your next post. So that the forum accepts it, please add the file extension .txt to it.

Thanks and regards,

-George

C2000™︎ microcontrollers

C2000 microcontrollers forum

TMS320F28379D: Understanding the generated HEX file when ALIGN(8) present in linker command file