LP-AM263P: CCS project without entry point.

Hi Ivan

Ivan Ivanenko said:

. 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

Ivan Ivanenko said:

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.

Ivan Ivanenko said:

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

Nilabh Anand said:

. 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:

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 

address   name                    
-------   ----                    
00000000  applicationConfigTable  
00000000  convert_float_to_long   
00000020  convert_float_to_ulong  
00000040  convert_long_to_float   
00000060  convert_ulong_to_float  

From .cmd file:

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 
}

From .hex file:

$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 

Nilabh Anand said:

Ivan Ivanenko said:

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.

Nilabh Anand said:

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:

$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 

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
0x600A063C	EB5FF18C	F3A37291	3086021D	A86743A1	D36ACB7A	588F4398	4621323C	BE83FCDF	BF484977	F1E4FCC7	950FE40D	14EB7093	4FDD6C9E	9B2073A0	C44DF4EC	14B8F094	4A887BB1	66888E52	4181830C
0x600A0688	AF94ED91	5E672ED6	2792E71A	BCA14EED	765E8F1F	720B72E6	9B52A734	D04BAF94	10ED8E98	E8519AB1	84108F87	9763AF71	A60525FB	A507468D	B7409B22	35ADFAA9	00000000	00000002	38D1B717
0x600A06D4	00000006	00000200	0000000A	00000210	00001000	00010004	3B03126F	00000032	00000000	00000050	00000032	00017000	00000002	3A83126F	00000006	00000100	00000009	00000110	FFFFFFFF
0x600A0720	00000000	00000000	00000000	00000000	00000000	00000000	EE300A41	EE800A20	EEBD0AC0	EE100A10	E12FFF1E	00000000	00000000	00000000	EE300A41	EE800A20	EEBC0AC0	EE100A10	E12FFF1E
0x600A076C	00000000	00000000	00000000	EE010A10	EEB81AC1	EE210A00	EE300A20	E12FFF1E	00000000	00000000	00000000	EE010A10	EEB81A41	EE210A00	EE300A20	E12FFF1E	1A1A1A1A	FFFFFFFF	FFFFFFFF

Here is line makefile, which builds image:

	$(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

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

Ivan Ivanenko said:

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?

Nilabh Anand said:

Ivan Ivanenko said:

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.

Ivan Ivanenko said:

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.

Nilabh Anand said:

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.