• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 1013 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.

Compiler/TMS320F28386D: Hex2000 output file address not fit alignment 128-bits

Frederick LIN
Intellectual 570 points
Part Number: TMS320F28386D

Tool/software: TI C/C++ Compiler

Hi,

I use hex2000 to convert my .out to .b00.

hex2000.exe path is "C:\ti\ccs930\ccs\tools\compiler\ti-cgt-c2000_18.12.5.LTS\bin"

This is my command:  hex2000.exe "inputFileName" -boot -sci8 -b

I set all FLASH by ALIGN(8) in 2838x_flash_lnk_cpu1.cmd.

Attach my cpu1 .cmd file

2838x_flash_lnk_cpu1_toTi.txt 
MEMORY
{
	/* BEGIN is used for the "boot to Flash" bootloader mode   */
	BEGIN			: origin = 0x088000, length = 0x000002
	BOOT_RSVD		: origin = 0x000002, length = 0x0001AF     /* Part of M0, BOOT rom will use this for stack */
	RAMM0			: origin = 0x0001B1, length = 0x00024F
	RAMM1			: origin = 0x000400, length = 0x0003F8     /* on-chip RAM block M1 */
//	RAMM1_RSVD		: origin = 0x0007F8, length = 0x000008     /* Reserve and do not use for code as per the errata advisory "Memory: Prefetching Beyond Valid Memory" */

/*	RAMD0			: origin = 0x00C000, length = 0x000800 */
/*	RAMD1			: origin = 0x00C800, length = 0x000800 */
	// This section is set for Ramfunc2
	RAMD0D1			: origin = 0x00C000, length = 0x001000

	/* ===== Ram sectors ===== */
/*	RAMLS0			: origin = 0x008000, length = 0x000800 */
/*	RAMLS1			: origin = 0x008800, length = 0x000800 */
/*	RAMLS2			: origin = 0x009000, length = 0x000800 */
/*	RAMLS3			: origin = 0x009800, length = 0x000800 */
/*	RAMLS4			: origin = 0x00A000, length = 0x000800 */
/*	RAMLS5			: origin = 0x00A800, length = 0x000800 */
/*	RAMLS6			: origin = 0x00B000, length = 0x000800 */
	// This section is set to CLA program
	RAMLS0LS6		: origin = 0x008000, length = 0x003800
	// This section is set to CLA data
	RAMLS7			: origin = 0x00B800, length = 0x000800


/*	RAMGS0			: origin = 0x00D000, length = 0x001000 */
/*	RAMGS1			: origin = 0x00E000, length = 0x001000 */
/*	RAMGS2			: origin = 0x00F000, length = 0x001000 */
	CPU1RAMGS0GS1A	: origin = 0x00D000, length = 0x001D00
	CPU1RAMGS1BGS2	: origin = 0x00ED00, length = 0x001400

/*	RAMGS3			: origin = 0x010000, length = 0x001000 */
/*	RAMGS4			: origin = 0x011000, length = 0x001000 */
/*	RAMGS5			: origin = 0x012000, length = 0x001000 */
/*	RAMGS6			: origin = 0x013000, length = 0x001000 */
	CPU1RAMGS3GS7A	: origin = 0x010100, length = 0x004500

/*	RAMGS7			: origin = 0x014000, length = 0x001000 */
/*	RAMGS8			: origin = 0x015000, length = 0x001000 */
/*	RAMGS9			: origin = 0x016000, length = 0x001000 */
	CPU1RAMGS7BGS9	: origin = 0x014600, length = 0x002A00

/*	RAMGS10			: origin = 0x017000, length = 0x001000 */
/*	RAMGS11			: origin = 0x018000, length = 0x001000 */
/*	RAMGS12			: origin = 0x019000, length = 0x001000 */
	CPU2RAMGS10GS13A	: origin = 0x017000, length = 0x003800

/*	RAMGS13			: origin = 0x01A000, length = 0x001000 */
/*	RAMGS14			: origin = 0x01B000, length = 0x001000 */
/*	RAMGS15			: origin = 0x01C000, length = 0x000FF8 */
	CPU2RAMGS13BGS15	: origin = 0x01A800, length = 0x0027F8
//	RAMGS15_RSVD	: origin = 0x01CFF8, length = 0x000008     /* Reserve and do not use for code as per the errata advisory "Memory: Prefetching Beyond Valid Memory" */

	/* Flash sectors */
	/* Start : Bootloader */
/*	FLASH0			: origin = 0x080002, length = 0x001FFE  on-chip Flash */
/*	FLASH1			: origin = 0x082000, length = 0x002000  on-chip Flash */
/*	FLASH2			: origin = 0x084000, length = 0x002000  on-chip Flash */
/*	FLASH3			: origin = 0x086000, length = 0x002000  on-chip Flash */
	/* End : Bootloader */
/*	FLASH4			: origin = 0x088000, length = 0x008000  on-chip Flash */
/*	FLASH5			: origin = 0x090000, length = 0x008000  on-chip Flash */
/*	FLASH6			: origin = 0x098000, length = 0x008000  on-chip Flash */
/*	FLASH7			: origin = 0x0A0000, length = 0x008000  on-chip Flash */
/*	FLASH8			: origin = 0x0A8000, length = 0x008000  on-chip Flash */
/*	FLASH9			: origin = 0x0B0000, length = 0x008000  on-chip Flash */
/*	FLASH10			: origin = 0x0B8000, length = 0x002000  on-chip Flash */
/*	FLASH11			: origin = 0x0BA000, length = 0x002000  on-chip Flash */
/*	FLASH12			: origin = 0x0BC000, length = 0x002000  on-chip Flash */
/*	FLASH13			: origin = 0x0BE000, length = 0x002000  on-chip Flash */
	FLASHEN1		: origin = 0x088008, length = 0x037FB8  /* on-chip Flash */
	/* Can not change this memory setting (Bootloader) */
	FLASHN_APPINFO	: origin = 0x0BFFC0, length = 0x000030  /* on-chip Flash */
//	FLASH13_RSVD	: origin = 0x0BFFF0, length = 0x000010  /* Reserve and do not use for code as per the errata advisory "Memory: Prefetching Beyond Valid Memory" */

/*	CPU1TOCPU2RAM   : origin = 0x03A000, length = 0x000800 */
	CPU1TOCPU2RAM1	: origin = 0x03A000, length = 0x000300
	CPU1TOCPU2RAM2	: origin = 0x03A300, length = 0x000100
	CPU1TOCPU2RAM3	: origin = 0x03A400, length = 0x000400  /* Reserved */
	
/*	CPU2TOCPU1RAM   : origin = 0x03B000, length = 0x000800 */
	CPU2TOCPU1RAM1	: origin = 0x03B000, length = 0x000300
	CPU2TOCPU1RAM2	: origin = 0x03B300, length = 0x000100
	CPU2TOCPU1RAM3	: origin = 0x03B400, length = 0x000400

/*	CMTOCPURAM		: origin = 0x038000, length = 0x000800 */
	CMTOCPU1RAM1	: origin = 0x038000, length = 0x000300
	CMTOCPU1RAM2	: origin = 0x038300, length = 0x000500  /* Reserved */

/*	CPUTOCMRAM		: origin = 0x039000, length = 0x000800 */
	CPU1TOCMRAM1	: origin = 0x039000, length = 0x000300
	CPU1TOCMRAM2	: origin = 0x039300, length = 0x000500  /* Reserved */

	CANA_MSG_RAM	: origin = 0x049000, length = 0x000800
	CANB_MSG_RAM	: origin = 0x04B000, length = 0x000800

	RESET			: origin = 0x3FFFC0, length = 0x000002
}

SECTIONS
{
	codestart			: > BEGIN, ALIGN(8)
	.text				: > FLASHEN1, ALIGN(8)
	.cinit				: > FLASHEN1, ALIGN(8)
	.switch				: > FLASHEN1, ALIGN(8)
	.reset				: > RESET, TYPE = DSECT /* not used, */
	.stack				: > RAMM0				/* There is stack size set in Properties->C2000 Linker->Basic Options-> -Stack */


#if defined(__TI_EABI__)
	.init_array			: > FLASHEN1, ALIGN(8)
	.bss				: > CPU1RAMGS3GS7A
	.data				: > CPU1RAMGS3GS7A
	.sysmem				: > RAMM0
	/* Initalized sections go in Flash */
	.const				: > FLASHEN1, ALIGN(8)
#else
	.pinit				: > FLASHEN1, ALIGN(8)
	.ebss				: > CPU1RAMGS3GS7A
	.esysmem			: > RAMM0
	/* Initalized sections go in Flash */
	.econst				: > FLASHEN1, ALIGN(8)
#endif

	// EABI Format with no head "_"
	ramfuncs :		LOAD = FLASHEN1,
					RUN = CPU1RAMGS7BGS9,
					LOAD_START(RamfuncsLoadStart),
					LOAD_SIZE(RamfuncsLoadSize),
					LOAD_END(RamfuncsLoadEnd),
					RUN_START(RamfuncsRunStart),
					RUN_SIZE(RamfuncsRunSize),
					RUN_END(RamfuncsRunEnd),
					ALIGN(8)

	ramfuncs2 :		LOAD = FLASHEN1,
					RUN = RAMD0D1,
					LOAD_START(Ramfuncs2LoadStart),
					LOAD_SIZE(Ramfuncs2LoadSize),
					LOAD_END(Ramfuncs2LoadEnd),
					RUN_START(Ramfuncs2RunStart),
					RUN_SIZE(Ramfuncs2RunSize),
					RUN_END(Ramfuncs2RunEnd),
					ALIGN(8)

	/* CLA specific sections */
	Cla1Prog			: LOAD = FLASHEN1,
						  RUN = RAMLS0LS6,
						  RUN_START(Cla1funcsRunStart),
						  LOAD_START(Cla1funcsLoadStart),
						  LOAD_SIZE(Cla1funcsLoadSize),
						  ALIGN(8)

	CLADataLS0			: > RAMLS7
	CLADataLS1			: > RAMLS7

#ifdef CLA_C
	/* CLA C compiler sections */
	//
	// Must be allocated to memory the CLA has write access to
	//
	.scratchpad			: > RAMLS7

	.bss_cla			: > RAMLS7

	.const_cla			: LOAD = FLASHEN1
						  RUN = RAMLS7,
						  RUN_START(Cla1ConstRunStart),
						  LOAD_START(Cla1ConstLoadStart),
						  LOAD_SIZE(Cla1ConstLoadSize),
						  ALIGN(8)
#endif //CLA_C

	/* AppInfo */
	AppInfoFiles : > FLASHN_APPINFO,     ALIGN(8)

}

/*
//===========================================================================
// End of file.
//===========================================================================
*/

However, in hex2000 output file, my 1st block start at address 0x88008 and size 0xFFFE.

The 2nd block start at address 0x98006(0x88008 + 0xFFFE) and is not fit 128-bits alignment.

This cause my bootloader cannot write data at 0x98006 with the FLASHAPI.

How can I figure it out?

  • 0
    TI__Guru**** 241115 points

    Thank you for notifying us of this problem.  I can reproduce the problem behavior.  I have started an internal discussion on what should happen next.  Please be patient.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 570 points

    Hi George,

    Can you provide a special fixed test version hex2000 as soon as you fix this problem?

    Thank you.

  • 0 in reply to Frederick LIN
    TI__Guru**** 241115 points

    Frederick LIN said:
    Can you provide a special fixed test version hex2000 as soon as you fix this problem?

    I'm confident we can find a practical workaround.  And if we can, that means you can move past this problem immediately.

    To help me find that workaround, please submit the linker map file. Please attach it to your next post.  So the forum accepts it, please add the file extension .txt to it.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 570 points

    Hi George,

    Confidential considerations, Can I send the map file by email or private message?

    We think that the forum is too public.

    If I can, which is your prefer, email or private message?

    Thanks and regards

  • 0 in reply to Frederick LIN
    TI__Guru**** 241115 points

    Please send me the map file by private message.  Hover your mouse over my screen name or avatar. A box will pop up. Click on Send a private message. In the message compose interface which comes up, use the paper clip icon to attach the map file. So the forum will accept it, add the file extension .txt.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 570 points

    Hi George,

    I have send a private message for .cmd and .map.

    Thank you

  • 0 in reply to Frederick LIN
    TI__Guru**** 241115 points

    Thank you for submitting the linker command file and the linker map file.  That allowed me to devise a workaround.  I'm confident this workaround will allow you to avoid the problem.  However, because I don't have everything, my ability to test it is limited.  I may have missed something.

    For others who are reading this thread ... Please understand the workaround described here is very specific to this customer's linker command file.

    Please get some background by reading the first half of the article Linker Command File Primer.

    When the hex utility lays out the initialized sections for boot loading, if a section is larger than 0xfffe words, it is split up.  If the section being split has an alignment requirement, the address of the second part of the split should also be aligned the same way.  The error is this second alignment is ignored.  The workaround is to use a feature of the linker called section splitting to prevent the hex utility from seeing any section that is larger than 0xfffe words.

    All the changes are implemented in the linker command file.  The hex utility invocation is exactly the same.

    In your particular program, only the .text section is larger than 0xfffe words.  So that is the only section which must be split early.  To do that requires splitting up the memory range where .text is allocated.  This affects all the other sections which are allocated to the same memory range.

    This is the memory range ...

    	FLASHEN1		: origin = 0x088008, length = 0x037FB8  /* on-chip Flash */

    Change it into a set of memory ranges that are contiguous, and span the same range of memory ...

    	OCF1                    : origin = 0x088008, length = 0x00FFF8
	OCF2                    : origin = 0x098000, length = 0x00FFF8
	OCF3                    : origin = 0x0A7FF8, length = 0x00FFF8
	OCF4                    : origin = 0x0B7FF0, length = 0x007FD0

    OCF stands for on-chip flash.  The length of 0xfff8 words is chosen because it the largest number, less than 0xfffe words, which causes the next range to start on an address that is 8-word aligned.  

    Here is how to split .text ...

    .text				: >> OCF1 | OCF2 | OCF3 | OCF4, ALIGN(8)

    The operator >> is the syntax for splitting the output section.  When an output section is too large for the first memory range, it is split and allocation continues into the second memory range.  The splitting always occurs on input section boundaries.  Therefore, a single function is never split.  

    All the other output sections which are allocated to FLASHEN1 have to be changed to something similar to ...

    	.cinit				: > OCF1 | OCF2 | OCF3 | OCF4, ALIGN(8)

    Note how this uses > and not >>.  Thus, no section splitting occurs.  The output section is allocated into the first of that set of memory ranges which can completely contain it.

    For the output sections that have different load and run allocations, the change is similar ...

    	ramfuncs :		LOAD = OCF1 | OCF2 | OCF3 | OCF4,
					RUN = CPU1RAMGS7BGS9,
					LOAD_START(RamfuncsLoadStart),
					LOAD_SIZE(RamfuncsLoadSize),
					LOAD_END(RamfuncsLoadEnd),
					RUN_START(RamfuncsRunStart),
					RUN_SIZE(RamfuncsRunSize),
					RUN_END(RamfuncsRunEnd),
					ALIGN(8)

    Please let me know if this workaround avoids the problem.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 570 points

    Hi George,

    It works!!

    I can burn in cpu1 & cpu2  successfully by FlashAPI and run as expected.

    Will you fix the size split bug in Hex2000? 

    Can I click "resolved" after you fix Hex2000 and release new version?

    Thanks and regards,

    Frederick

  • 0 in reply to Frederick LIN
    TI__Guru**** 241115 points

    Frederick LIN said:
    Will you fix the size split bug in Hex2000? 

    I filed EXT_EP-10175 to have this problem addressed.  You are welcome to follow it at that link.

    Frederick LIN said:
    Can I click "resolved" after you fix Hex2000 and release new version?

    By filing an issue, it is now handed off to the engineering team to address.  Thus, this thread is marked TI Thinks Resolved.  From a support standpoint, the thread is closed and no further action is expected. Marking the thread as TI thinks Resolved is a way of communicating this. Note that by no means do we think the issue is closed overall.

    Thanks and regards,

    -George