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/TMS320F28069M: .bin file contents

Part Number: TMS320F28069M


Tool/software: TI C/C++ Compiler

Hello,

I am implementing the bootloader with firmware update capability. I have downloaded the CRC table and application image to Flash.

The contents of CRC table as seen is .map is  But my .bin file has the CRC data as shown below

0800 0800 0000 0000 00C1 3D00 AB20 0000 75F7 6035 0000 0000 10E3 3D00 4E09 0000 82B3 B1EA 0000 0000 5EEC 3D00 1000 0000 5DFB F931 0000 0000 70EC 3D00 0A00 0000 E0C7 0E35 0000 0000 7AEC 3D00 0200 0000 D413 EC83 0000 0000 7CEC 3D00 55B2 0000 9401 1CEB 0000 0000 D29E 3E00 7C2E 0000 2336 E603 0000 0000 4ECD 3E00 6800 0000 6937 4F6B 0000 0000

The highlighted portion is load address (0x 003D C100)for ram funs and size  = 0x000020AB.

As you can see that address and the size seems to flipped(3D00 00C1, this is the value seen in debugger as well). I am suspecting it is because of endianess.

I am generating bin files using the below command

"${CCE_INSTALL_ROOT}/utils/tiobj2bin/tiobj2bin" "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.bin" "${CG_TOOL_ROOT}/bin/ofd2000" "${CG_TOOL_ROOT}/bin/hex2000" "${CCE_INSTALL_ROOT}/utils/tiobj2bin/mkhex4bin" 

Can somebody help me resolve this issue.

PS. I am attaching linker file

/*
//###########################################################################
//
// FILE:    F28069.cmd
//
// TITLE:   Linker Command File For F28069 Device
//
//###########################################################################
// $TI Release: F2806x C/C++ Header Files and Peripheral Examples V135 $
// $Release Date: Sep 8, 2012 $
//###########################################################################
*/

/* ======================================================
// For Code Composer Studio V2.2 and later
// ---------------------------------------
// In addition to this memory linker command file,
// add the header linker command file directly to the project.
// The header linker command file is required to link the
// peripheral structures to the proper locations within
// the memory map.
//
// The header linker files are found in <base>\F2806x_headers\cmd
//
// For BIOS applications add:      F2806x_Headers_BIOS.cmd
// For nonBIOS applications add:   F2806x_Headers_nonBIOS.cmd
========================================================= */

/* ======================================================
// For Code Composer Studio prior to V2.2
// --------------------------------------
// 1) Use one of the following -l statements to include the
// header linker command file in the project. The header linker
// file is required to link the peripheral structures to the proper
// locations within the memory map                                    */

/* Uncomment this line to include file only for non-BIOS applications */
/* -l F2806x_Headers_nonBIOS.cmd */

/* Uncomment this line to include file only for BIOS applications */
/* -l F2806x_Headers_BIOS.cmd */

/* 2) In your project add the path to <base>\F2806x_headers\cmd to the
   library search path under project->build options, linker tab,
   library search path (-i).
/*========================================================= */

/* Define the memory block start/length for the F2806x
   PAGE 0 will be used to organize program sections
   PAGE 1 will be used to organize data sections

   Notes:
         Memory blocks on F28069 are uniform (ie same
         physical memory) in both PAGE 0 and PAGE 1.
         That is the same memory region should not be
         defined for both PAGE 0 and PAGE 1.
         Doing so will result in corruption of program
         and/or data.

         Contiguous SARAM memory blocks can be combined
         if required to create a larger memory block.
*/

MEMORY
{
PAGE 0 :   /* Program Memory */
           /* Memory (RAM/FLASH/OTP) blocks can be moved to PAGE1 for data allocation */
   OTP         : origin = 0x3D7800, length = 0x000400     /* on-chip OTP */
   BL_FH       : origin = 0x3D8000, length = 0x004000     /* on-chip FLASH for bootloader*/
   CRC         : origin = 0x3DC000, length = 0x000100
   APP_FLASH   : origin = 0x3DC100, length = 0x01BE80     /* on-chip FLASH for application*/
   CSM_RSVD    : origin = 0x3F7F80, length = 0x000076     /* Part of FLASHA.  Program with all 0x0000 when CSM is in use. */
   BEGIN       : origin = 0x3F7FF6, length = 0x000002     /* Part of FLASHA.  Used for "boot to Flash" bootloader mode. */
   CSM_PWL_P0  : origin = 0x3F7FF8, length = 0x000008     /* Part of FLASHA.  CSM password locations in FLASHA */

   FPUTABLES   : origin = 0x3FD590, length = 0x0006A0	 /* FPU Tables in Boot ROM */
   IQTABLES    : origin = 0x3FDC30, length = 0x000B50    /* IQ Math Tables in Boot ROM */
   IQTABLES2   : origin = 0x3FE780, length = 0x00008C    /* IQ Math Tables in Boot ROM */
   IQTABLES3   : origin = 0x3FE80C, length = 0x0000AA	 /* IQ Math Tables in Boot ROM */

   ROM         : origin = 0x3FF3B0, length = 0x000C10     /* Boot ROM */
   RESET       : origin = 0x3FFFC0, length = 0x000002     /* part of boot ROM  */
   VECTORS     : origin = 0x3FFFC2, length = 0x00003E     /* part of boot ROM  */

PAGE 1 :   /* Data Memory */
           /* Memory (RAM/FLASH/OTP) blocks can be moved to PAGE0 for program allocation */
           /* Registers remain on PAGE1                                                  */

   BOOT_RSVD   : origin = 0x000000, length = 0x000050     /* Part of M0, BOOT rom will use this for stack */
   PIEVECT     : origin = 0xD00,    length = 0x100
   RAMM0_1     : origin = 0x000050, length = 0x0007B0     /* on-chip RAM block M0 */
   RAM_FUNCS   : origin = 0x008000, length = 0x002100
   RAM         : origin = 0x00a100, length = 0x007F00     /* on-chip RAM */
   USB_RAM     : origin = 0x040000, length = 0x000800     /* USB RAM		  */
}

/* Allocate sections to memory blocks.
   Note:
         codestart user defined section in DSP28_CodeStartBranch.asm used to redirect code
                   execution when booting to flash
         ramfuncs  user defined section to store functions that will be copied from Flash into RAM
*/


SECTIONS
{
   bl_table            : > 0x3D8000,   PAGE = 0, type = DSECT
   app_table           : > CRC,   PAGE = 0

   /* Allocate program areas: */
   .TI.ramfunc         : {} LOAD=APP_FLASH PAGE = 0,
                            RUN=RAM_FUNCS    PAGE = 1,
                            crc_table(_CRCTestVector),
                            TABLE(BINIT)


   /* Allocate program areas: */
   GROUP               : > APP_FLASH,     PAGE = 0, crc_table(_CRCTestVector)
   {
       .cinit
       .pinit
       .binit
       codestart
       .text
       /* Initalized sections to go in Flash */
       /* For SDFlash to program these, they must be allocated to page 0 */
       .econst
       .switch
   }


   .TI.crctab          : > CRC
   csmpasswds          : > CSM_PWL_P0, PAGE = 0
   csm_rsvd            : > CSM_RSVD,   PAGE = 0
   //.cinit              : > APP_FLASH,           PAGE = 0
   //.binit              : {} > APP_FLASH,        PAGE = 0
   //.pinit              : > APP_FLASH,           PAGE = 0
   //.text               : > APP_FLASH,           PAGE = 0
   //codestart           : > BEGIN,           PAGE = 0
   //.TI.ramfunc         : {} LOAD=APP_FLASH      PAGE = 0,
                           // RUN=RAM_FUNCS   PAGE = 1,
                           // TABLE(BINIT)
   csmpasswds          : > CSM_PWL_P0,      PAGE = 0
   csm_rsvd            : > CSM_RSVD,        PAGE = 0

   /* Allocate uninitalized data sections: */
   .stack              : > RAM,              PAGE = 1
   // Give ebss more RAM(task stacks)
   .ebss               : > RAM | RAMM0_1,    PAGE = 1
   .esysmem            : > RAM,              PAGE = 1
   // .cio buf is used by OS no real way around it
   .cio                : > RAMM0_1,          PAGE = 1


   /* Allocate IQ math areas: */
   IQmath              : > APP_FLASH,   PAGE = 0            /* Math Code */
   IQmathTables        : > IQTABLES,     PAGE = 0, TYPE = NOLOAD

   /* Allocate FPU math areas: */
   FPUmathTables       : > FPUTABLES,  PAGE = 0, TYPE = NOLOAD

  /* Uncomment the section below if calling the IQNexp() or IQexp()
      functions from the IQMath.lib library in order to utilize the
      relevant IQ Math table in Boot ROM (This saves space and Boot ROM
      is 1 wait-state). If this section is not uncommented, IQmathTables2
      will be loaded into other memory (SARAM, Flash, etc.) and will take
      up space, but 0 wait-state is possible.
   */
	/*
   IQmathTables2    : > IQTABLES2, PAGE = 0, TYPE = NOLOAD
   {

              IQmath.lib<IQNexpTable.obj> (IQmathTablesRam)

   }
	*/
   /* Uncomment the section below if calling the IQNasin() or IQasin()
      functions from the IQMath.lib library in order to utilize the
      relevant IQ Math table in Boot ROM (This saves space and Boot ROM
      is 1 wait-state). If this section is not uncommented, IQmathTables2
      will be loaded into other memory (SARAM, Flash, etc.) and will take
      up space, but 0 wait-state is possible.
   */
   /*
   IQmathTables3    : > IQTABLES3, PAGE = 0, TYPE = NOLOAD
   {

              IQmath.lib<IQNasinTable.obj> (IQmathTablesRam)

   }
   */

   /* .reset is a standard section used by the compiler.  It contains the */
   /* the address of the start of _c_int00 for C Code.   /*
   /* When using the boot ROM this section and the CPU vector */
   /* table is not needed.  Thus the default type is set here to  */
   /* DSECT  */
   .reset              : > RESET,      PAGE = 0, TYPE = DSECT
   vectors             : > VECTORS,    PAGE = 0, TYPE = DSECT

}

/*
//===========================================================================
// End of file.
//===========================================================================
*/
and .map file 3223.motor_controller_map.txtand .bin file motor_controller_bin.txtfor reference here. I have used Hex Fiend to see the content of binary file.

Thanks

Nandini

  • Hello

    An engineer has been assigned to assist.

    Best regards

    Chris

  • The linker and tiobj2bin have not done anything wrong.  That really is how the C28x CPU expects those values to be encoded in memory.  I'll demonstrate with an example.

    Start with this assembly file ...

    ; file.asm
            .data
            .long   0x003dc100
            .long   0x000020ab
            .long   0x3560f775

    Those values match how your CRC table starts.

    Build it with this command ...

    % cl2000 file.asm

    The next step is to look at the representation of those long values in the object file.  First, determine where those values are in the file.  Use the utility ofd2000 to show where the raw data for the section .data starts.  

    % ofd2000 -v --obj_display=none,sections file.obj
    
    OBJECT FILE:  file.obj
    
     Section Information
    
    ... MANY LINES SKIPPED ...
    
        <3> ".data"
           Load Address:        0x00000000  Run Address:        0x00000000
           Size:                0x6         Alignment:          2
           Loaded Onto Device:  Yes         Address Unit Size:  16 bits
           File Offset:         0x100       # Relocs:           0
           Reloc File Offset:   0x00000000  # Lines:            0
           Line File Offset:    0x00000000  TI-COFF s_flags:    0x00000040
           TI-COFF s_flag:      STYP_DATA   (null)              (null)

    Note the File Offset is 0x100.  Next I use the Unix-like command od to see the bytes in the object file starting at offset 0x100 ...

    % od -Anone -t x1 -j 0x100 file.obj
     00 c1 3d 00 ab 20 00 00 75 f7 60 35

    Note how this matches what you suspect is wrong ...

    Nandini Shankaraiah said:
    00C1 3D00 AB20 0000 75F7 6035

    The C28x assembler, linker, and related tools have worked this way from the beginning.  And, clearly, this encoding is what the C28x CPU expects.

    Explanation of the od command ... od stands for object dump.  It is available on most Unix-like systems, as well as Cygwin.  The supported command line arguments vary between systems.  Here is what they mean in this case:

    • -Anone : Do not display the address
    • -t x1 : Format the data as hexadecimal values, one 8-bit byte at a time
    • -j 0x100 : Skip the first 0x100 bytes of the file
    • file.obj : The name of the input file

    I do not display any of the bytes after the first 12.  I use -t x1 to avoid any byte swaps od might perform.

    Thanks and regards,

    -George

  • Hello George,

    Thank you for detailed explanation. It helped understand how the data is organized in the .obj file( which is served as input to the generation of .bin file)

    I did try your illustration and I do confirm that I see that dump as 00C1 3D00 AB20 0000 75F7 6035

    Now for the example I stated where I see the  CRC value. I did generate .hex file using the hex utility.

    with the following commands attached in this linker file 

    bl_app.out
    --intel
    --image
    --order=MS
    --romwidth=16
    --memwidth=16
    --fill=0xFFFF
    
    
    
    ROMS
    {
    	APP_FLASH : origin = 0x3DA000, length = 0x1E000, files = { bl_app_i.hex }
    
    }
    
    
    /*
    //===========================================================================
    // End of file.
    //===========================================================================
    */
    
    
    

    The .hex file now generated has the output C100 003D 20AB 0000 F775 3560.

    Now the bytes seemed to aligned different( endianness changed due to flag --order=MS).

    Now my questions

    why this difference between .bin and .hex?

    why the endianness cannot be handled in the .bin file? 

    if we cannot handle endianness in .bin file. what file I format I should be using for Firmware Updates? Because, when I write the bin file to the flash the value is read as "20AB" (on debugger, not as expected)

    Thanks

    Nandini


  • The point of my previous post is that the little endian order of 8-bits bytes within 16-bit words emitted by the assembler is the order expected by the C28x CPU.  Therefore, that is the order you see in the .bin file.  Do not use the --order=MS feature of the hex utility to change that order.

    Thanks and regards,

    -George