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.

LP-AM263P: CCS project without entry point.

Part Number: LP-AM263P

Tool/software:

Hello.

I need to create project in CCS, which has some functions/data which should be called from other projects by fixed address. With other MCU/IDE I had used linker script to place these functions/data to defined memory regions and compiled project without start files options to create elf/hex file, which can be later flashed to ROM.

While trying to do the same task with CCS, I have created empty CCS project (without using SDK, as I don't need to initialize MCU and use any peripherals in this project) with using of TI Clang v3.2.2 compiler and I met following problems:

1. I didn't find way to exclude standard start files and entry point from build. I use option '-nostartfiles' option in GCC linker for this, but no anything similar for TI Clang.

2. How to order linker/compiler to not exclude certain functions/data from output during optimization? This is needed, as I don't want to use entry point in this project and compiler 'optimize' everything, so I need to define 'entry points' manually (and there can be no entry points in project, only data, which should be placed to certain address). I used KEEP word in GCC linker script, but this is not recognized by linker command file for CCS/TI Clang.

3. After compilation I don't see any *.appimage file to load into flash, only *.out and *.hex (I have enabled it), but there is no instruction how these file types can be load to flash on Launchpad devboard.

  • Hi Ivan

    . I didn't find way to exclude standard start files and entry point from build. I use option '-nostartfiles' option in GCC linker for this, but no anything similar for TI Clang.

    Please find details on excluding the entry point function: https://software-dl.ti.com/codegen/docs/tiarmclang/rel3_0_0_STS/compiler_manual/program_loading_and_running/run-time-initialization-slau1316977.html?highlight=startup#ram-model-vs-rom-model

    2. How to order linker/compiler to not exclude certain functions/data from output during optimization? This is needed, as I don't want to use entry point in this project and compiler 'optimize' everything, so I need to define 'entry points' manually (and there can be no entry points in project, only data, which should be placed to certain address). I used KEEP word in GCC linker script, but this is not recognized by linker command file for CCS/TI Clang.

    I will try to get back with more details on this by early next week.

    3. After compilation I don't see any *.appimage file to load into flash, only *.out and *.hex (I have enabled it), but there is no instruction how these file types can be load to flash on Launchpad devboard.

    Please go through this to understand the app image creation process: AM263Px MCU+ SDK: Booting Tools

  • . I didn't find way to exclude standard start files and entry point from build. I use option '-nostartfiles' option in GCC linker for this, but no anything similar for TI Clang.

    Please find details on excluding the entry point function: https://software-dl.ti.com/codegen/docs/tiarmclang/rel3_0_0_STS/compiler_manual/program_loading_and_running/run-time-initialization-slau1316977.html?highlight=startup#ram-model-vs-rom-model

    Sorry, but I cannot find answer for my question in provided document. Both RAM and ROM model provide some routine to initialize application (in runtime or load time), which should be avoided in my case. I just need to compile application without 'main' function and boot routine with different RUN and LOAD addressed and load it to flash. All data initialization and coping to RAM will be done by own custom application.

    I found that setting option '--relocatable' and neither RAM nor ROM model in linker setting allows me to remove 'main' function, but in this case compiler include all functions (some of which can be optimized out) and addresses of my symbols in .map file are all started from 0x0000xxxx, though sections RUN and LOAD addresses are correct (symbols addresses match section addresses in case of compilation with no '--relocatable' option).
    In resulting .hex file all data/text are placed to RUN address instead LOAD address, which I consider as mistake, as this files should actually be loaded to SoC.


    From .map file:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    SECTION ALLOCATION MAP
    output attributes/
    section page origin length input sections
    -------- ---- ---------- ---------- ----------------
    .text 0 60100070 00000074 RUN ADDR = 70040070
    60100070 00000014 platform_library.o (.text.convert_float_to_long)
    60100084 0000000c --HOLE-- [fill = 0]
    60100090 00000014 platform_library.o (.text.convert_float_to_ulong)
    601000a4 0000000c --HOLE-- [fill = 0]
    601000b0 00000014 platform_library.o (.text.convert_long_to_float)
    601000c4 0000000c --HOLE-- [fill = 0]
    601000d0 00000014 platform_library.o (.text.convert_ulong_to_float)
    .config_table
    * 0 60100000 00000070 RUN ADDR = 70040000
    60100000 00000070 config_table.o (.config_table)
    GLOBAL SYMBOLS: SORTED BY Symbol Address
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    From .cmd file:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    SECTIONS
    {
    .text : run = OCRAM, load = FLASH, align = 8
    .data : run = OCRAM, load = FLASH, align = 8
    .rodata : run = OCRAM, load = FLASH, align = 8
    .bss : > OCRAM, align = 8
    .config_table : run = OCRAM, load = FLASH, align = 8
    }
    MEMORY
    {
    SBL : ORIGIN = 0x70000000 , LENGTH = 0x40000
    OCRAM : ORIGIN = 0x70040000 , LENGTH = 0x40000
    FLASH : ORIGIN = 0x60100000 , LENGTH = 0x80000
    }
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    From .hex file:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    $A70040000,
    00 00 00 00 00 00 00 02 38 D1 B7 17 00 00 00 06 00 00 02 00 00 00 00 0A
    00 00 02 10 00 00 10 00 00 01 00 04 3B 03 12 6F 00 00 00 32 00 00 00 00
    00 00 00 50 00 00 00 32 00 01 70 00 00 00 00 02 3A 83 12 6F 00 00 00 06
    00 00 01 00 00 00 00 09 00 00 01 10 FF FF FF FF 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    EE 30 0A 41 EE 80 0A 20 EE BD 0A C0 EE 10 0A 10 E1 2F FF 1E 00 00 00 00
    00 00 00 00 00 00 00 00 EE 30 0A 41 EE 80 0A 20 EE BC 0A C0 EE 10 0A 10
    E1 2F FF 1E 00 00 00 00 00 00 00 00 00 00 00 00 EE 01 0A 10 EE B8 1A C1
    EE 21 0A 00 EE 30 0A 20 E1 2F FF 1E 00 00 00 00 00 00 00 00 00 00 00 00
    EE 01 0A 10 EE B8 1A 41 EE 21 0A 00 EE 30 0A 20 E1 2F FF 1E
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 3. After compilation I don't see any *.appimage file to load into flash, only *.out and *.hex (I have enabled it), but there is no instruction how these file types can be load to flash on Launchpad devboard.

    Please go through this to understand the app image creation process: AM263Px MCU+ SDK: Booting Tools

    This document describes process of multi-core image or RPRC file creation, which is not my goal. Sorry for misunderstanding.

    What I need is to load compiled *.out (or *.hex) file with some data and/or code to flash memory on Launchpad devboard. This code/data should not be runed by SBL, but read/copied (and runed by address, but it's not scope of this topic) by 'standard' application, which was created with SDK (and has generated *.appimage and *.rprc files).

    In short: how *.out or *.hex file (in intel or other format) can be loaded to flash on LM-AM263P?

  • Hi Ivan,

    Allow me sometime to get this info, as this is something not offered as part of SDK offering, I will try to get as many questions as possible but some of them are very new to me. I will try to get back by 30th Aug. Meanwhile could you please tell me what is the usecase here?

  • For 3rd question take a look at makefile_ccs_bootimage_gen file. It does the process of boot image generation which will be loaded by ROM>

    Path of file : mcu_plus_sdk\examples\drivers\boot\sbl_ospi\am243x-evm\r5fss0-0_nortos\ti-arm-clang\makefile_ccs_bootimage_gen

    I will try to get more info on Q1 and Q2

  • Sure, it's not question about SDK, it's about compiler/linker and ROM flashing tool.

    Use case: simple middleware software for flight control computer. It should run applications, developed by side-parties as separate projects, which should be compiled and loaded to ROM as individual binaries. These projects, of course, should not have any MCU initialization and standard startup code, entry points to applications are custom, so no 'main' functions are used.

  • For 3rd question take a look at makefile_ccs_bootimage_gen file. It does the process of boot image generation which will be loaded by ROM>

    Path of file : mcu_plus_sdk\examples\drivers\boot\sbl_ospi\am243x-evm\r5fss0-0_nortos\ti-arm-clang\makefile_ccs_bootimage_gen

    Thanks, that was very helpful.

    I've created image and loaded it to FLASH with offset 0xA0000. But now I see, that loaded image has data/code, which was compiled, but also huge number of information, which is useless for me, and which makes very difficult to find actual data/code start address.

    How adding additional info can be avoided?

    Here is compiled .hex file:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    $A70060000,
    00 00 00 00 00 00 00 02 38 D1 B7 17 00 00 00 06 00 00 02 00 00 00 00 0A
    00 00 02 10 00 00 10 00 00 01 00 04 3B 03 12 6F 00 00 00 32 00 00 00 00
    00 00 00 50 00 00 00 32 00 01 70 00 00 00 00 02 3A 83 12 6F 00 00 00 06
    00 00 01 00 00 00 00 09 00 00 01 10 FF FF FF FF 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    EE 30 0A 41 EE 80 0A 20 EE BD 0A C0 EE 10 0A 10 E1 2F FF 1E 00 00 00 00
    00 00 00 00 00 00 00 00 EE 30 0A 41 EE 80 0A 20 EE BC 0A C0 EE 10 0A 10
    E1 2F FF 1E 00 00 00 00 00 00 00 00 00 00 00 00 EE 01 0A 10 EE B8 1A C1
    EE 21 0A 00 EE 30 0A 20 E1 2F FF 1E 00 00 00 00 00 00 00 00 00 00 00 00
    EE 01 0A 10 EE B8 1A 41 EE 21 0A 00 EE 30 0A 20 E1 2F FF 1E
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


    And here is FLASH memory section (my actual data/code starts from address 0x600A06C8)

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    0x600A0000 C4068230 AC048230 010203A0 26140202 6C9AAA01 EDE8F90D 4E8289BC B6F4D5EE 302E56FB 2A09060D F7864886 0D01010D 81300005 300B3197 55030609 02130604 0B315355 03060930 0C080455
    0x600A004C 31435302 060F3011 07045503 654E080C 6F592077 21316B72 03061F30 0C0A0455 78655418 49207361 7274736E 6E656D75 2C2E7374 636E4920 3013312E 55030611 0A0C0B04 41544953 4D204152
    0x600A0098 0F315543 03060D30 0C030455 626C4106 31747265 061D301F 48862A09 010DF786 10160109 65626C41 67407472 69742E74 6D6F632E 0D171E30 38303432 38313732 32303334 320D175A 32393034
    0x600A00E4 34383136 5A323033 31978130 0609300B 06045503 53550213 09300B31 04550306 53020C08 30113143 5503060F 080C0704 2077654E 6B726F59 1F302131 04550306 54180C0A 73617865 736E4920
    0x600A0130 6D757274 73746E65 49202C2E 312E636E 06113013 0B045503 49530A0C 41524154 55434D20 0D300F31 04550306 41060C03 7265626C 301F3174 2A09061D F7864886 0109010D 6C411016 74726562
    0x600A017C 2E746740 632E6974 82306D6F 0D302202 862A0906 0DF78648 05010101 02820300 8230000F 82020A02 C2000102 A50A8209 FA72202F 84E7932B F6735A11 3F93D3EB A3FD96BE CFC39D7F FF3F8127
    0x600A01C8 AE14BA02 2CFC86D8 A8EF2EDF 22005A93 04DF19FD 1C39B70A D368703E 9329E6A7 ADD0173A D9CEA0EB 49A828A3 4C9CBAED FA39A9D3 8A32E51B AD393690 0BB218FF 5DC26CC2 7280DDB6 D5764F67
    0x600A0214 F8E05362 9C455B86 BECFDFA3 9A16AE0C 3B4C6352 FB1A3F17 FDF505D7 BF1A4534 477EDE62 1CA30776 79F336D2 BAFFD1BF 60ABB48B D1A91DB5 35EF348C CEDB1B75 24BE79AE F07A9935 002BBC16
    0x600A0260 33AF60C9 424ED118 FF02EFFF 8BAA6783 A4F096B9 149E6FA4 07DBEBCA C45CCBF9 018384AC C1204730 F0A019C2 071085D2 C32FBC3C 00156431 DD72C4E9 6B56E788 7AC3A2F8 FA12507E 069C88F4
    0x600A02AC 16A97566 7AF303BE CF3C4ECE B7784F78 8A95FE5A 3D3DE349 33EC38BE CAF1AF9D 023CF1EF D25BC707 75A50579 8D85AFE3 2E539C56 FA6B88F5 02F130DF 478C73A3 409B5EE5 5611E3A2 E1948808
    0x600A02F8 6D971275 960D2D1E 97D27EE6 0545B9DE D43113C8 CB374407 20A31945 67910D95 A828F840 F9709880 ED4BC81B 7B30FF0C 30EE47A6 465A38D6 60C11C1E 12D1CD3B 6DD59B79 D0F581CB 5543EB96
    0x600A0344 41538BF5 056BE032 1F12AE0F 3696AED8 335398F7 8C0B23F9 DC1E7AD4 3726A357 8D8FA4DD A2038D58 C51081A2 A59393FB 75F61E05 48CEBE17 C30E6DCC E1D354A7 FA23E624 D86D3A65 A4E0F434
    0x600A0390 48798C34 23AEAA73 45906371 92BDDEE9 13548B5B 022B0A51 01000103 040182A3 00018230 03060C30 04131D55 01033005 2230FF01 062B0906 82010401 04010126 02133015 01020101 00010210
    0x600A03DC 00700404 02020020 5C30E400 062B0906 82010401 04020126 064D304F 48866009 04036501 40040302 6457A8BE 58F185A4 FF0FF82E D8267917 2AE9C4BB FA6AE87E 767203D6 13140DFD 61333C04
    0x600A0428 D81B99EC BC85A3F3 37E227E3 9870CD03 C11B929B 75F47563 03720EEE 09061230 0401062B 01268201 30050403 01010203 09065A30 0401062B 01268201 304D0408 0040044B 00000000 00000000
    0x600A0474 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 02000000 01020101 00010200 09060D30 8648862A 01010DF7
    0x600A04C0 0300050D 00010282 73C4766A 44EC8A1C E461F7E7 E1B40762 B57C62E8 2E6695F3 83BA21C3 36C4109E C5F413A6 FD9FA103 8EB62748 1AFA7C03 F1E4BBF3 69B647AD A7D4AACC B9F9A000 21A5E542
    0x600A050C 29556881 E6E7846E 4F7D472F 61D65B7F 3C9051DF 33A5FFB1 2F607C9C 2687D5AE 21C10DEC AEE3665E 6C72F8B0 98DF4A5C 60CAC7A0 100D7F5F 5E0FF10B BB76AD08 7C5830F3 15A8B4F6 DF70C956
    0x600A0558 165754F0 1EC27235 8D6736DE 51C6F3E5 6FEE55A2 B4939C8F 5AFA801F C11260EC 715AA1D2 35B06917 BEEEBF35 D782E011 A5A8FC3E 0511592D 8C9C33D1 8904D4E9 2C47F7BB 2B412A19 86DEAE6D
    0x600A05A4 50A128D9 1BC23224 6AAA34FE 4BA9E161 940CE2D8 73AE6A20 5C00F2C5 472F17BF F174BF0A BC8C6D61 C56EB42B D9D6D710 A334F204 D30C380E 6CFE1EEB 15B41BCC 9452EFD5 CE987AAB 5546EA69
    0x600A05F0 84C83C61 013C3A8B BB1F393F 38AA0623 D887A3BF 1A14A04A 372DDED5 BF62A281 59C45526 8E46F720 5BAD71C3 DABD67AA BC5D2083 4FBFC233 9679405C 3B9132BF 62EC462D C3239744 675C36DB
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Here is line makefile, which builds image:

    Fullscreen
    1
    2
    $(OBJCOPY) --strip-all -O binary $(PROFILE)/$(OUTNAME).out $(BOOTIMAGE_BIN_NAME)
    $(BOOTIMAGE_CERT_GEN_CMD) --image-bin $(BOOTIMAGE_BIN_NAME) --core R5 --swrv 1 --loadaddr $(SBL_RUN_ADDRESS) --sign-key $(BOOTIMAGE_CERT_KEY) --out-image $(BOOTIMAGE_NAME) --debug DBG_SOC_DEFAULT
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


    And here is line from uart flashloaded *.cfg file:

    Fullscreen
    1
    --file=../../test1/Debug/test1.tiimage --operation=flash --flash-offset=0xA0000
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 1. I didn't find way to exclude standard start files and entry point from build. I use option '-nostartfiles' option in GCC linker for this, but no anything similar for TI Clang.

    2. How to order linker/compiler to not exclude certain functions/data from output during optimization? This is needed, as I don't want to use entry point in this project and compiler 'optimize' everything, so I need to define 'entry points' manually (and there can be no entry points in project, only data, which should be placed to certain address). I used KEEP word in GCC linker script, but this is not recognized by linker command file for CCS/TI Clang.

    Hi Ivan, if I understand this correctly  you build a part of the program, then program it into flash.  Lets Call this first build part A. The rest of the program is built later.  Call this later build part B.  The connection between part A and part B is not symbols, but hard coded addresses that you will choose in advance. Is my understand correct?

  • 1. I didn't find way to exclude standard start files and entry point from build. I use option '-nostartfiles' option in GCC linker for this, but no anything similar for TI Clang.

    2. How to order linker/compiler to not exclude certain functions/data from output during optimization? This is needed, as I don't want to use entry point in this project and compiler 'optimize' everything, so I need to define 'entry points' manually (and there can be no entry points in project, only data, which should be placed to certain address). I used KEEP word in GCC linker script, but this is not recognized by linker command file for CCS/TI Clang.

    Hi Ivan, if I understand this correctly  you build a part of the program, then program it into flash.  Lets Call this first build part A. The rest of the program is built later.  Call this later build part B.  The connection between part A and part B is not symbols, but hard coded addresses that you will choose in advance. Is my understand correct?

    Overall yes, that's correct.

    Just addresses are not exactly hardcoded, but loaded to Flash as 'part C' project to address, which is really hardcode (by placing to dedicated memory section in linker script). But at this scope we can consider them as hardcoded.

    But about these questions please read my answer about '--relocatable' option. I've got some results and have more certain questions now.Thera are some code examples above.

    I found that setting option '--relocatable' and neither RAM nor ROM model in linker setting allows me to remove 'main' function, but in this case compiler include all functions (some of which can be optimized out) and addresses of my symbols in .map file are all started from 0x0000xxxx, though sections RUN and LOAD addresses are correct (symbols addresses match section addresses in case of compilation with no '--relocatable' option).
    In resulting .hex file all data/text are placed to RUN address instead LOAD address, which I consider as mistake, as this files should actually be loaded to SoC.

  • Hi Ivan

    After confirming with our compiler experts, We don’t support this method of organizing and building code. My suggestion here would be to organize and build the code as per the compiler current support.  Part A is not programmed into flash.  It is organized as a library of object files.  Part B adds the part A library to it’s link.  The connection between part A and part B is by symbols.  After the final executable is created, it is programmed into flash.

  • My suggestion here would be to organize and build the code as per the compiler current support.  Part A is not programmed into flash.  It is organized as a library of object files.  Part B adds the part A library to it’s link.  The connection between part A and part B is by symbols.  After the final executable is created, it is programmed into flash.

    This solution is unacceptable in our project, as in real use case 'Part B' is developed by side-party company after we provide hardware solution with already flashed 'Part A'. So 'Part B' should be compiled/flashed (with custom loader, which will be part of 'Part A') as standalone project, which can be changed or updated without any changes to 'Part A'

    I suggest just to forget about hole picture, at least for now. Can you please answer for questions about '--relocatable' option without consideration of whole project? I can create related topics to make it easier, as this topic becomes a little messy.

  • Hi Ivan , 

    Could you please create a new thread related to relocatable question and mentioning compiler flag related details so it gets directed to our compiler experts. It would be much cleaner.