• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 31 subscribers
  • Views 723 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS570LC4357: Is linker generated CRC different depending on location of the section in the flash?

Simon W
Prodigy 110 points
Part Number: TMS570LC4357
Other Parts Discussed in Thread: HALCOGEN,

Hello all,

I am using the linker generated CRC-table feature to compute the CRCs for multiple sections during link time and verify the contents during boot time.
My goal is to have the application installed twice in the flash memory and do the verification of each application in the bootloader.

Currently I use CCS to build and program it to different memory locations (e.g. FLASH_APP_0_PARTITION and FLASH_APP_1_PARTITION). That works fine and also the verification of the code works as expected.

However, when linking the application to different memory locations I noticed that the CRCs that were computed by the linker are not always the same. From my point of view, the CRC of a section should always be the same, no matter where it is located in the memory.

What I tried to find out what is going on:

  1. Put a random function into its own section and compute the CRC for that section.
    Result: When linking it to different locations, the CRC is always the same, no matter where it is located.
  2. I assumed that it might be a padding-issue, so I put each section into a group and added some padding-bytes at the end:
    GROUP
    {
        .text : {} align(8), crc_table(_my_crc_table, algorithm=TMS570_CRC64_ISO)
        .dummy : {.+=7;} fill=0x00000000
    } > FLASH_APP_0_PARTITION

    Result: Still the same. The computed CRCs of the section .text differ depending on the location of FLASH_APP_0_PARTITION

From my understanding, the code of a section is always the same, no matter where it is located. Additionally I would assume that the CRC of that section doesn't change depending on the location, but obviously it does.

Can someone explain why I see that behavior?

Thank you for your help,
Simon

  • 0
    Guru 92251 points

    Simon W said:
    From my understanding, the code of a section is always the same, no matter where it is located.

    I think the problem is that the TI ARM doesn't support creating position independent code (PIC). Thus, the linker may generate some output where the generated contents varies according to the absolute link address.

    I realise my terminology is bit vague, but I haven't yet looked at which source code constructs would cause linker output to vary according to the link address.

    Perhaps running the objdiff utility from the Code Generation Tools XML Processing Utilities to compare the out files generated with the application linked at FLASH_APP_0_PARTITION and FLASH_APP_1_PARTITION would reveal what causes the differences.

  • 0 in reply to Chester Gillon
    TI__Guru**** 192486 points

    Hello,

    If the content of two sections are same, and both sections have same size and are aligned on 8 bytes boundary, their CRC values will be same.

  • 0
    Guru 92251 points

    Simon W said:
    From my understanding, the code of a section is always the same, no matter where it is located.

    Looking at the example of the HalCoGen generated HL_sys_vim.c source file shows that the TI compiler generates R_ARM_ABS32 relocations for:

    a. Taking the address of the s_vim_init constant array.

    b. The function pointers inside the s_vim_init array.

    Where the R_ARM_ABS32 relocations in the .const or .text sections which change the contents depending upon the address the linker places the code in flash.

    The TI ARM code generation tools don't support creating position independent code, so don't support having one application image which can be placed in flash at two different addresses.

    The GCC ARM compiler does in theory allow position independent executables to be created, but it not a simple matter to just change from the TI to GCC compiler to allow a boot loader to store multiple position independent executables in flash due to:

    1. The GCC compiler supplied by TI doesn't come with big-endian run time libraries for the TMS570LC4357 and you have to re-build GCC; see CCS/TMS570LC4357: HalCoGen code cannot be compiled with GCC.
    2. If the application code is re-compiled as position independent, I think the GCC Cortex-R run time libraries would also have to be re-built with position independent versions.
    3. There are some HalCoGen generated assembler files such as HL_sys_mpu.s which look they would need to be modified to be position-independent.
    4. To allow a position independent program to run the boot loader and/or start up code would need to be modified to perform re-locations. At the moment the HalCoGen generated _c_int00 entry point function in HL_sys_startup.c doesn't call the _start() GCC run-time library initialisation function.
    5. For the use case of a microcontroller where the boot loader selects one of two application images in flash to run, the position independence is only required for code and not data (i.e. references to global data could still absolute addresses set at link time). However, from GCC 7 or 9 I can't see a method to only use position independence for code. Position independence involves an extra overhead of applying an offset to calculate addresses.

     

  • 0 in reply to Chester Gillon
    Prodigy 110 points

    Thank you so much for taking the time and effort to investigate that issue. The information you provided is very helpful.

    I have two more questions related to my problem:

    1. Is it common knowledge that the TI ARM code generation tools don't support position independent code? Unfortunately I couldn't find any information about that in the user guides provided by TI.
    2. I want to understand the R_ARM_ABS32 relocations. I guess I should use the object file utilities (arm-none-eabi-objdump) to find the relevant information. But all I get is the message "file truncated" when using my out-file as an input. I get the same result for the ti-cgt-arm_18.12.5.LTS as well as ti-cgt-arm_18.12.6.LTS. Can you give some advice?

    Thank you for your help.

  • 0 in reply to Simon W
    Guru 92251 points

    Simon W said:
    Is it common knowledge that the TI ARM code generation tools don't support position independent code? Unfortunately I couldn't find any information about that in the user guides provided by TI.

    I found replies such as https://e2e.ti.com/support/microcontrollers/msp430/f/166/p/641982/2369727#2369727, and the PIC options only being documented for the TI C6000 compiler.

    Simon W said:
    I want to understand the R_ARM_ABS32 relocations. I guess I should use the object file utilities (arm-none-eabi-objdump) to find the relevant information.

    By default the linker creates the out file as an Absolute Output Module which contains norelocation information. See the description of the --absolute_exe option in the ARM Assembly Language Tools v18.1.0.LTS User's Guide. An Absolute Output Module is suitable for programming into FLASH.

    If you use the --relocatable linker option the out file will contain relocations which you can look at. Note that a Relocatable Output Module is not suitable for programming into FLASH. I found out that that the CCS debugger will program a Relocatable Output Module into FLASH with no error reported, but the resulting program doesn't run due to no relocations being applied.

  • 0 in reply to Chester Gillon
    Prodigy 110 points

    Thank you for your hints.

    Finally I found out that I need to use code generation tools version 20.2.1. Otherwise I get the "file truncated" message. I guess that the earlier versions don't support the architecture of the TMS570LC43x processor.