Compiler/TMS320F28377D: hex tool seems to misalign Flash memory mapping

ron

Part Number: TMS320F28377D
Other Parts Discussed in Thread: CONTROLSUITE

Tool/software: TI C/C++ Compiler

I have written a bootloader for the f28377D DSP shortly after release which would take the ASCII-hex generated by the CCS toolchain with options "--boot --sci8" and write it to flash with the FlashAPI supplied by TI. Now, all of a sudden I am unable to write specific Flash ranges.

I made sure that the width of each bank is respected during write, but at some point, and its always within the address-range of Flash sector F irrelevant of image that is being uploaded the flash API returns "Fapi_Error_AsyncIncorrectDataBufferLength" and fails to write the location but the location +4 words is written again, and then +8 words not.

eg.

0x0091FFE : 0000 0000 0000 0000 //FAILS

0x0092002 : 0123 4567 89AB CDEF //Succeeds

0x0092006 : 0000 0000 0000 0000 //FAILS

0x009200A : 0123 4567 89AB CDEF //Succeeds

This indicates to me that the data that is being written is misaligned.(?)

I have verified data coming from the custom SCI frontend to the device. I have verified parsing of the hex-file.

I have tried it on multiple other boards its is always reproducible!

Short of rewriting the frontend to parse the file and pre-sectioning it into the banks and add padding, I thought asking here if anyone might know what is going on here/has experienced this/has a suggestion?

Best,

Ron.

over 8 years ago

0 Vamsi Gudivada over 8 years ago

TI__Guru* 87155 points

Ron,

The starting address to program plus the length (number of 16-bit words) should not exceed 128-bit aligned memory.

For example:

1. 0x0091FFE : 0000 0000 0000 0000 //FAILS

In this case, 0x0091FF8 to 0x0091FFF is the 128-bit aligned address range. When you try to program 4 16-bit words starting at 0x0091FFE, it fails since you are trying to program 4 words when there is space for only 2 words (0x0091FFE and 0x0091FFF) in that 128-bit aligned memory.

2. 0x0092002 : 0123 4567 89AB CDEF //Succeeds

In this case, 0x0092000 to 0x0092007 is the 128-bit aligned address range. When you try to program 4 16-bit words starting at 0x0092002, it succeeds since you are trying to program 4 words when there is space for 6 more words (0x0092002 to 0x0092007) in that 128-bit aligned memory.

Please refer to SPNU629 document for more details.

Thanks and regards,
Vamsi

0 ron over 8 years ago in reply to Vamsi Gudivada

Prodigy 95 points

Vamsi.

>The starting address to program plus the length (number of 16-bit words) should not exceed 128-bit aligned memory.

Yes I know that. The main problem is, that I assumed the TI toolchain would align data as needed, and as I always write 4 words, from 0-offset of the memory section, it should always be 64 bit top part of memory and then 64bit bottom of the 128bit alignment. There seem to be an additional 2 words added during linking or hex generation.

My issue is that at some point (somewhere before the example ) there seems to be an alignment issue within the HEX image that can obviously be seen because of the program wanting to write 4 words to 0x0091FFE.
As an additional test, I used the CopyData() function from the controlSuite examples - but it had the same issue.
This is my reasoning for the problem being somewhere in the ASCII-hex generation or during the mapping process during linking.

Thus the question if someone ever has come across this - if not, I will have to parse the hex file and add padding correction where needed.

Regard

Ron

0 Vamsi Gudivada over 8 years ago in reply to ron

TI__Guru* 87155 points

Ron,

Ok, I got it. Did you align all the sections in the linker command file on a 64-bit boundary using ALIGN(4)?

Thanks and regards,
Vamsi

0 ron over 8 years ago in reply to Vamsi Gudivada

Prodigy 95 points

Vamsi.

Just so that you know, we have a bit of a time-shift as I am based in Austria.

Regarding the ALIGN(4), yes its all aligned.

Regards
Ron

0 Sal Pezzino over 8 years ago in reply to ron

TI__Mastermind 32995 points

The hex tool will not align the memory or pad the memory. This needs to be done at link time. The hex tool cannot re-link the code and symbols which would need to be done in order to align or pad memory. The hex tool simply converts the .out to a hex file format.

Regards,
sal

0 ron over 8 years ago in reply to Sal Pezzino

Prodigy 95 points

So I can assume that whatever the COFF contains, the hex tool just blindly converts it to whatever hex format?

Thus the the problem originates during link-time?

I spent the entire day checking all our linker configurations all cmd files short of going through the COFF line-by-line, I have verified that all configurations as well as the .map file are correct.

As I am currently using the latest version of the CCS toolchain, I will try the older CCS v6 toolchain as a last resort.

Regards
Ron

0 Vamsi Gudivada over 8 years ago in reply to ron

TI__Guru* 87155 points

Ron,

I asked our compiler team to help you further. They will probably need to look at your linker command file and map file.

Thanks and regards,
Vamsi

0 ron over 8 years ago in reply to Vamsi Gudivada

Prodigy 95 points

Vamsi,

Thanks. I have invested quite some time to go through all our configs and settings as well as all linker options.

I will have to clean our linker command file before posting it here.

Thanks

Ron

0 Vamsi Gudivada over 8 years ago in reply to ron

TI__Guru* 87155 points

Ron,

That's fine. Our compiler team will take a look at it when you post it here.

Thanks and regards,
Vamsi

0 ron over 8 years ago in reply to Vamsi Gudivada

Prodigy 95 points

Vamsi, Compiler team,

Please find attached the .cmd we use for linking and the resulting .map file.

regards

Ron

uCOS-II_F2837xD.map.txt

Fullscreen F28377D_uCOS_link.cmd.txt Download

MEMORY {

/*
*********************************************************************************************************
*                                           -| MEMORY REGIONS
*											  -| FLASH Mode
*********************************************************************************************************
*/
	PAGE 0:
		RAMM0           	: origin = 0x000122, length = 0x0002DE
  		RAMD0           	: origin = 0x00B000, length = 0x000800
   		RAMLS0          	: origin = 0x008000, length = 0x000800



		BEGIN           	: origin = 0x080000, length = 0x000002
		FLASHA           	: origin = 0x080002, length = 0x001FFE	/* on-chip Flash */
   		FLASHB_H           	: origin = 0x082000, length = 0x026000	/* on-chip Flash */
		FLASHI				: origin = 0x0A8000, length = 0x008000	/* on-chip Flash */
		FLASHJ				: origin = 0x0B0000, length = 0x008000	/* on-chip Flash */
		FLASHK				: origin = 0x0B8000, length = 0x002000	/* on-chip Flash */
		FLASHL				: origin = 0x0BA000, length = 0x002000	/* on-chip Flash */
		FLASHM				: origin = 0x0BC000, length = 0x002000	/* on-chip Flash */
		FLASHN				: origin = 0x0BE000, length = 0x002000	/* on-chip Flash */

        CSM_RSVD   			: origin = 0x33FF80, length = 0x000076

        CSM_PWL    			: origin = 0x33FFF8, length = 0x000008
        ADC_CAL    			: origin = 0x380080, length = 0x000009

        BOOTROM    			: origin = 0x3FF27C, length = 0x000D44
        VECTORS    			: origin = 0x3FFFC0, length = 0x000040

	 PAGE 1:

		BOOT_RSVD	    	: origin = 0x000002, length = 0x000120     /* Part of M0, BOOT rom will use this for stack */
   		RAMLS1          	: origin = 0x008800, length = 0x000800
		RAMM1				: origin = 0x000400, length = 0x000400
   		RAMLS_STACK      	: origin = 0x009000, length = 0x001800		/* LS2, LS3, LS4 */
		RAMD1				: origin = 0x00B800, length = 0x000800

		RAMLS5				: origin = 0x00A800, length = 0x000800

		RAMGS_BIG			: origin = 0x00C000, length = 0x010000		/* multiple RAM blocks in one definition, so a structure may be allocated crossing the boundaries */


		CPU2TOCPU1RAM   : origin = 0x03F800, length = 0x000400
		CPU1TOCPU2RAM   : origin = 0x03FC00, length = 0x000400
}

SECTIONS
{

/*
*********************************************************************************************************
*                                           -| LINKER SECTIONS
*											  -| FLASH Mode
*********************************************************************************************************
*/

//wrapper allignment for ram_start initialiser for OS
	ram_start  			: > BEGIN,           PAGE = 0, ALIGN(4)
	codestart           : > FLASHA       PAGE = 0, ALIGN(4)

    ramfuncs            :	LOAD = FLASHA,
                         	RUN = RAMLS0,
                         	LOAD_START(_RamfuncsLoadStart),
                         	LOAD_SIZE(_RamfuncsLoadSize),
                         	LOAD_END(_RamfuncsLoadEnd),
                         	RUN_START(_RamfuncsRunStart),
                         	RUN_SIZE(_RamfuncsRunSize),
                         	RUN_END(_RamfuncsRunEnd),
							PAGE = 0, ALIGN(4)

    .text      			: >> FLASHB_H,         	PAGE = 0, ALIGN(4)
    .cinit     			: > FLASHB_H,          	PAGE = 0, ALIGN(4)
    .pinit     			: > FLASHB_H,          	PAGE = 0, ALIGN(4)
    .switch    			: > FLASHB_H,          	PAGE = 0, ALIGN(4)
    .econst    			: > FLASHB_H,          	PAGE = 0, ALIGN(4)                                                           /* Default reset handler. Not used.                     */
    .reset     			: > VECTORS,         	PAGE = 0, TYPE = DSECT

    pie_vram   			: > RAMLS1,        	PAGE = 1

    .stack     			: > RAMM1,           PAGE = 1
    .ebss      			: > RAMGS_BIG,      PAGE = 1
    .esysmem   			: > RAMGS_BIG,       PAGE = 1
    task_stack			: > RAMLS_STACK, 	 PAGE = 1
    dma_region			: > CPU1TOCPU2RAM,	 PAGE = 1

	.switch             : > FLASHB_H,     PAGE = 0, ALIGN(4)


                                                                /* 128-bit CSM Password. Not used.                      */
	csm_rsvd   			: > CSM_RSVD,        PAGE = 0, TYPE = DSECT
	csmpasswds 			: > CSM_PWL,         PAGE = 0, TYPE = DSECT
                                                                /* ADC Calibration.                                     */
	.adc_cal   			: load = ADC_CAL,    PAGE = 0, TYPE = NOLOAD



	GROUP : > CPU1TOCPU2RAM, PAGE = 1
	{
		PUTBUFFER
		PUTWRITEIDX
		GETREADIDX
	}

	GROUP : > CPU2TOCPU1RAM, PAGE = 1
	{
		GETBUFFER
		GETWRITEIDX
		PUTREADIDX
	}
}

0 Vamsi Gudivada over 8 years ago in reply to ron

TI__Guru* 87155 points

Ron,

Can you try PALIGN(4) instead of ALIGN(4) in your linker cmd file? This will pad any incomplete 64-bits.

Our compiler team is looking at it today.

Thanks and regards,
Vamsi

0 ron over 8 years ago in reply to Vamsi Gudivada

Prodigy 95 points

Vamsi,

I will try this once I'm back in the office.

EDIT: I tried it. There is no difference same exact behaviour. Is this Keyword even supported by the C2000 platform? I can only find documentation on it in the ARM-based platforms?

Thanks & Regards,
Ron

0 George Mock over 8 years ago in reply to ron

TI__Guru**** 251710 points

Unfortunately, I don't understand what is going on.

I'd appreciate if you would send in the .out file produced by the linker. Zip it up and attach it to your next post. Also show exactly how the hex utility is invoked by copy-n-paste from the CCS console view. Then show the first line in the hex utility output that is misaligned. Explain why it is misaligned.

ron said:
Is this Keyword even supported by the C2000 platform?

The palign feature is supported by the C2000 linker. Please see the section titled Alignment With Padding in the C28x assembly tools manual.

Thanks and regards,

-George

0 ron over 8 years ago in reply to George Mock

Prodigy 95 points

George,

I can't release the binary without an NDA or similar.

I don't know as of which address the misalignment happens, it seems completely arbitrary.

Give me a few days to compile the information for you.

> palign

Thank you - should have updated my local version

regards

Ron

0 George Mock over 8 years ago in reply to ron

TI__Guru**** 251710 points

Since it has been a while, I presume you resolved the issue. I'd appreciate hearing how you resolved it.

Thanks and regards,

-George

0 ron over 8 years ago in reply to George Mock

Prodigy 95 points

George,

Sorry for the delay, I was on holiday an had no access to the internet!

I have not resolved it.

I have decided it is easier and more time efficient to rewrite the frontend that parses the file to do an adaptive padding to fix the missalignment as this problem is a "show stopper" for your product.

Once I am done, I will send you a PM with the collected data so you can investigate if it is an issue of the toolchain.

In other words I will mark this thread as resolved.

Thanks for all the help,

regards

Ron

C2000™︎ microcontrollers

C2000 microcontrollers forum

Compiler/TMS320F28377D: hex tool seems to misalign Flash memory mapping