hex6x utility invoked with the -image option does not seem to generate an 'exact image' of the program codes!

CMA said:

I find the output file still contains the entry_point, section size and section destination codes in it!

I'm not sure what you mean.  How do you know this is occurring?  Please post a small portion of your output which illustrates this problem.

Thanks and regards,

-George

  Hi George, I checked the contents of the *.bo output of the hex6x routine against the *.map file to come to this conclusion.

Below are clips of the *.bo, *.map and my command files for the hex6x: I have underlined and bolded the relevant evidences.

===== The hex6x output *.bo file:

%4E6CC890000000002A0202006A0248002802020068020008C0008036A60290002B031600000000
%4E61689000002029410084006A0300D8FA00040000000036360290FE922FFF80000000002A0020

%4E63A8900003E00000000000000000000000000000000000000000000000000000000000000000
%4E687890000400400000010200000004000000002A01A000EA01800362000C0000000000000000
%4E6328900004200000000000000000000000000012000000000000000000000000000000000000

%4E63F8900005E00000000000000000000000000012000000000000000000000000000000000000
%4E6AA8900006000000000000000000000000003DA0000106000000005A07BF42D4023C20000000
%4E6FE8900006204286023CC22A02C200EA02802000000009A2021102B60214200000004286023C

%4E6648900FFFE00000000000000000000000000000000000000000000000000000000000000000
%0E823800014000

===== The *.map file:

******************************************************************************
          TMS320C6x COFF Linker PC v6.0.8                     
******************************************************************************
>> Linked Sun Feb 13 13:39:24 2011

OUTPUT FILE NAME:   <cch.out>
ENTRY POINT SYMBOL: "_c_int00"  address: 00014000

MEMORY CONFIGURATION

SECTION ALLOCATION MAP

 output                                  attributes/
section   page    origin      length       input sections
--------  ----  ----------  ----------   ----------------
.bootload
*          0    00000000    00000060    
                  00000000    00000060     intvecs_bootload_cch.obj (.bootload)

.intvecs   0    00000400    00000200    
                  00000400    00000200     intvecs_bootload_cch.obj (.intvecs)

.text      0    00000600    00013da0    
                  00000600    00005fc0     Main_cch_Link2PaRAMNull_test2_latest_read32words_burn2flash_bootload.obj (.text)
                  000065c0    00000e40     FBTCBurnDSK6713_16bit_cch_will_message.obj (.text)

===== The *.bat make-file:

..\C6713_EXE\hex6x HC11Feb15.cmd

===== The HC11Feb15.cmd hex6x commands file:

/* 2011 Jan 23, cchma. Below are in accordance to p.247, Chapter 11, of
   the TI Assembly Language Users Guide - spru186s.pdf */

cch.out   /* Source COFF (*.out) filename */
-memwidth 16  /* 2011 Jan 23, cchma. Specify the total data bus width of the boot-ROM memory implemented. */
-romwidth 16  /* 2011 Jan 23, cchma. Specify the data bus width of the individual memory chip used */
-order L  /* 2011 Jan 23, cchma. Specify little-endian ordering */

-boot   /* Convert all initialized sections into bootable form */

-image    /* 2011 Jan 31, cchma. Generate a hex image file */

-bootorg 0x90000400   /* Place the boot table starting from this address */

-bootsection .bootload 0x90000000  /* Specify that '.bootload' section contains the bootload routine */

ROMS   /* Below specifies the physical ROM memory configuration(s). */
{
PROM_CE1:  /* c6713b board only contains one AM29LV800 flash ROM device configured as follows */
origin = 0x90000000, /* The AM29LV800 device is selected by the CE1\ pin of the c6713b DSP */
length = 0x00100000, /* The number of 16bit half-words of the AM29LV800 device */
files = {cch.b0} /* Specify the filename to output the data converted for this ROM space */
}

/* 2011 Jan 23, cchma. Above are in accordance to p.247, Chapter 11, of
   the TI Assembly Language Users Guide - spru186s.pdf */

I don't see anything unusual in this hex6x output.  This output format is described in the section titled Extended Tektronix Object Format of the C6000 Assembly Language Tools User's Guide.  Let's take this line as an example.

CMA said:

%4E687890000400400000010200000004000000002A01A000EA01800362000C0000000000000000

The first 7 characters %4E6878 encode information required by this format.  The next 8 characters 90000400 form a 32-bit address for where this data (or code) resides in memory.  It is normal for one such record to match the -bootorg address.  That said, this record is the only one which matches any of the addresses shown in your map file excerpt.

For all of the other map file hex strings in bold, I can find no match in the hex6x output.  Except for the starting address of the .intvecs section 00000400.  But it turns out that even this is not a true match.  While that string does appear in the record I quote above, careful examination shows it does not fall on a 32-bit boundary.  A 32-bit boundary falls right in the middle.  Thus it cannot be a match.  Even if it were match, it would not be a surprise to see the base address of the interrupt vectors referenced somewhere in the code or data.

Thanks and regards,

-George