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.

Creating bin file

Other Parts Discussed in Thread: MOTORWARE

I am working on a motor control application.  I have the motor control part which I based on lab11 of motorware and a bootloader which I created.  The motor control application runs, I have the blinking LED/comms as required, but the motor itself doesn't run properly.  When I load the application via the jtag and not my bootloader it works.  

I use the following post build step to generate a bin to create the proprietary file from:

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

However when this runs I get the following error:

warning: section prjlab11-8305.out(.econst) at 07ebe00h falls in unconfigured

So I'm guessing this section is not making it into the bin file which is why the motor won't run properly.  To bootloader lives in flash A and the motor control lives in flash BCD.  I use a modified cmd when linking, included below.  I'm sure I could do things better, but this does (when loaded via jtag) work.  Can someone please offer me some advice?

/*
// TI File $Revision: /main/7 $
// Checkin $Date: July 6, 2009   17:25:36 $
//###########################################################################
//
// FILE:  F28027.cmd
//
// TITLE: Linker Command File For F28027 Device
//
//###########################################################################
// $TI Release: 2802x C/C++ Header Files and Peripheral Examples V1.29 $
// $Release Date: January 11, 2011 $
//###########################################################################
*/

/* ======================================================
// 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>\DSP2802_Headers\cmd
//
// For BIOS applications add:      DSP2802x_Headers_BIOS.cmd
// For nonBIOS applications add:   DSP2802x_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 DSP2802x_Headers_nonBIOS.cmd */

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

/* 2) In your project add the path to <base>\DSP2802x_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 F28027
   PAGE 0 will be used to organize program sections
   PAGE 1 will be used to organize data sections

   Notes:
         Memory blocks on F2802x 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.

         The L0 memory block is mirrored - that is
         it can be accessed in high memory or low memory.
         For simplicity only one instance is used in this
         linker file.

         Contiguous SARAM memory blocks or flash sectors can be
         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 */
   //CSM_RSVD    : origin = 0x3F7F80, length = 0x000076     /* Part of FLASHA.  Program with all 0x0000 when CSM is in use. */
   BEGIN       : origin = 0x3F0000, 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 */

   IQTABLES    : origin = 0x3FE000, length = 0x000B50     /* IQ Math Tables in Boot ROM */
   IQTABLES2   : origin = 0x3FEB50, length = 0x00008C     /* IQ Math Tables in Boot ROM */
   IQTABLES3   : origin = 0x3FEBDC, length = 0x0000AA     /* IQ Math Tables in Boot ROM */

   ROM         : origin = 0x3FF27C, length = 0x000D44     /* Boot ROM */
   RESET       : origin = 0x3FFFC0, length = 0x000002     /* part of boot ROM  */
   VECTORS     : origin = 0x3FFFC2, length = 0x00003E     /* part of boot ROM  */
   FLASHB_D    : origin = 0x3F0002, length = 0x005EFC     /* on-chip FLASH B, C and D */
   P_RAML0     : origin = 0x008000, length = 0x000800     /* on-chip PRAM block L0 */

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

   RAMM0_M1    : origin = 0x000000, length = 0x000600     /* on-chip RAM block M0 + M1. 0x600 to 0x800 reserved for InstaSPIN */
   D_RAML0     : origin = 0x008800, length = 0x000800     /* on-chip DRAM block L0 */
   D_FLASHB_D    : origin = 0x3F5EFF, length = 0x000100     /* on-chip FLASH A */
   //D_FLASHB_D    : origin = 0x3F0000, length = 0x005FF6     /* on-chip FLASH A */
   MAGIC	   : origin = 0x3F5FFF, length = 0x000001
}

/* 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
{
   /* Allocate program areas: */
   .cinit              : > FLASHB_D     PAGE = 0
   .pinit              : > FLASHB_D,    PAGE = 0
   .text               : > FLASHB_D     PAGE = 0
   codestart           : > BEGIN        PAGE = 0
   ramfuncs            : LOAD = FLASHB_D,
                         RUN = P_RAML0,
                         LOAD_START(_RamfuncsLoadStart),
                         LOAD_END(_RamfuncsLoadEnd),
                         RUN_START(_RamfuncsRunStart),
                         PAGE = 0

   //csmpasswds          : > CSM_PWL_P0   PAGE = 0
   //csm_rsvd            : > CSM_RSVD     PAGE = 0

   /* Allocate uninitalized data sections: */
   .stack              : > RAMM0_M1     PAGE = 1
   .ebss               : > D_RAML0      PAGE = 1
   ebss_extension      : > P_RAML0      PAGE = 0
   .esysmem            : > RAMM0_M1     PAGE = 1

   rom_accessed_data   : > RAMM0_M1     PAGE = 1
   MagicSection		: > MAGIC PAGE = 1

   /* Initalized sections go in Flash */
   /* For SDFlash to program these, they must be allocated to page 0 */
   .econst     : LOAD = D_FLASHB_D,
                 RUN = RAMM0_M1,
                 LOAD_START(_econst_start),
                 LOAD_END(_econst_end),
                 RUN_START(_econst_ram_load),
                 PAGE = 1

   .switch     : LOAD = D_FLASHB_D,
                 RUN = RAMM0_M1,
                 LOAD_START(_switch_start),
                 LOAD_END(_switch_end),
                 RUN_START(_switch_ram_load),
                 PAGE = 1

   /* Allocate IQ math areas: */
   IQmath              : > FLASHB_D     PAGE = 0            /* Math Code */
   IQmathTables        : > IQTABLES,    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

}

  • I just confirmed the same happens with a virgin motorware project.
  • One more follow up.

    I loaded the program with the JTAG then used code composer studio memory browser to dump the flash contents on the chip to a bin file. I was able to load this bin file with my bootloader and have the program execute as expected. I have also confirmed the contents on chip match exactly the contents set by the bootloader.
  • DRProton,

    The boot loader you have written accepts bin file? On C28x we use HEX format for boot loading, at least the ROM loaders use the HEX format and I suppose most of the customers and third party SW also uses the HEX format because it allows for a discontinuous target memory map, where in the HEX file can contain blocks of data and a header with information on where in target this block of data has to be programmed/loaded. It helps when the target application doesn't occupy a continuous memory range. But again it is up to customer on the formats they choose.

    I believe you can use hex2000, to create a bin file directly from the COFF(or OUT) file, you don;t have to go through the scripts you have shown. I'm not sure where you got that information, we suggest to use those scripts for Concerto M3 with ARMHEX.

    Hex2000 supports the below option to generate a binary file from COFF file, try hex2000 -h to see the possibilities.

      --binary,-b                  Binary output format (for DSKs)

    Best Regards

    Santosh Athuru

  • Santosh,

    My bootloader accepts a custom encrypted format which I generate from a bin file using a separate utility.

    I tried your suggestion, but it didn't work. The resulting and jtag dump are identical for the majority of the program. There comes a point where the jtag dump is fill with 0xFF and the bin with 0x00, but I'm guessing this is just blank space. At the very end (equivalent of 0x3F5F00) things become different. The bin is still 0 but the dump has some data. I get the following output at build time:

    'Invoking: C2000 Hex Utility'
    "C:/Work/ti/ccsv6/tools/compiler/ti-cgt-c2000_6.4.2/bin/hex2000" --memwidth=16 --romwidth=16 --intel --binary -o "prjlab11-8305.hex" "prjlab11-8305.out"
    Translating to Binary format...
    warning: section prjlab11-8305.out(codestart) at 07e0000h falls in unconfigured
    memory (skipped)
    "prjlab11-8305.out" codestart ==> codestart
    warning: section prjlab11-8305.out(.text) at 07e0004h falls in unconfigured
    "prjlab11-8305.out" .text ==> .text
    memory (skipped)
    "prjlab11-8305.out" ramfuncs ==> ramfuncs
    warning: section prjlab11-8305.out(ramfuncs) at 07e7f30h falls in unconfigured
    "prjlab11-8305.out" .cinit ==> .cinit
    memory (skipped)
    "prjlab11-8305.out" .econst ==> .econst
    warning: section prjlab11-8305.out(.cinit) at 07e855eh falls in unconfigured
    memory (skipped)
    warning: section prjlab11-8305.out(.econst) at 07ebe00h falls in unconfigured
    memory (skipped)
    'Finished building: prjlab11-8305.hex'
  • DrProton,
    can you try using -fill argument to specify the fill value and see if the memory dump matches the output of hex2000? Does your linker command file have -fill option at the end of sections.

    Those warnings doesn't seem good as well. The .econst , .text, .cinit should all link to flash and I don't understand the 07e0004h , that doesn't seem to be a valid address.

    Let me move the forum post to the tools team, they should be of good help from here.

    which device is this?


    Best Regards
    Santosh Athuru
  • Yeah, I made a mistake. I had the other script still running and it was making the bin. Turns out the hex2000 tools is not making anything.

    My cmd file is the same as in my first post. this is a F28027F
  • If you are still interested in using tiobj2bin, I have some news to share.

    DrProton said:
    warning: section prjlab11-8305.out(.econst) at 07ebe00h falls in unconfigured

    This is due to a bug in tiobj2bin that was fixed about 5 years ago.  While it seems unlikely you have such an old installation of tiobj2bin, this diagnostic is exactly what is seen when that bug shows up.  For a fix, please see this forum post.  The circumstances that lead to that post are not the same as those present here, but the solution is the same.

    Thanks and regards,

    -George

  • I updated the files as suggested. Still have the same problem though.
  • To explain what happened, I need to reproduce it.  Please zip up the .out file and attach that to your next post.

    Thanks and regards,

    -George

  • I am less confident than usual that I understand this situation.  I may come back and make some corrections.

    The batch file tiobj2bin.bat invokes the hex utility hex2000.  I'm pretty sure the problem is with hex2000.  I filed SDSCM00052907 to have this investigated.  Feel free to follow it with the SDOWP link below in my signature.

    Thanks and regards,

    -George

  • I had a look at the support ticket.  The issue is not that the warning is incorrect, the issue is that the resulting bin file doesn't work.

  • I see what you are saying.  I updated the entry to make it clear the hex utility incorrectly skips over the section .econst.

    Thanks and regards,

    -George

  • Any update on this?
  • We do not have an update at this time.  We have not looked into this issue yet. 

  • Still Nothing?
  • We don't have any updates at this time.  The issue is being transferred into our new bug database and will be assigned to an engineer when possible.

  • Defect report is CODEGEN-1505. Still not assigned, but briefly the hex command file needs to specify the page. Use the following to get just .econst
    ROMS { page 1: all_mem: o = 0x003f5f00, l = 0x1000 }
    or else change your linker command file to put everything on page 0