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.

CCS/TMS320F2808: "no source available for 0x0" error when trying to flash HEX file

Part Number: TMS320F2808
Other Parts Discussed in Thread: UNIFLASH, CONTROLSUITE

Tool/software: Code Composer Studio

Hello,

For initial phase of development our project uses TMS320F2808 evaluation board.

To generate the hex file I used below flag settings in CCS 6.0.1.00040.

--fill=0xffff --memwidth=16 --romwidth=16 --intel


But when I try to flash the hex file into the board I get "no source available for 0x0" error.

It all works fine, when I flash the .out file. 

Last week I got response from TI to try to reset the chip and restart the program. I did that, but still it is not working.

To make sure that everything is OK with the .cmd file, I used .cmd from example project. The same is attached.

Is there anything that I am missing here?

Best Regards,

Sanat

F2808.txt
/*
// TI File $Revision: /main/4 $
// Checkin $Date: August 2, 2006   16:57:00 $
//###########################################################################
//
// FILE:	F2808.cmd
//
// TITLE:	Linker Command File For F2808 Device
//
//###########################################################################
// $TI Release: DSP280x C/C++ Header Files V1.70 $
// $Release Date: July 27, 2009 $
//###########################################################################
*/

/* ======================================================
// 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>\DSP280x_Headers\cmd
//   
// For BIOS applications add:      DSP280x_Headers_BIOS.cmd
// For nonBIOS applications add:   DSP280x_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 DSP280x_Headers_nonBIOS.cmd */

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

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

   Notes: 
         Memory blocks on F2808 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. 
         
         L0/L1 and H0 memory blocks are mirrored - that is
         they 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 */

   RAML0       : origin = 0x008000, length = 0x001000     /* on-chip RAM block L0 */
   OTP         : origin = 0x3D7800, length = 0x000400     /* on-chip OTP */
   FLASHD      : origin = 0x3E8000, length = 0x004000     /* on-chip FLASH */
   FLASHC      : origin = 0x3EC000, length = 0x004000     /* on-chip FLASH */
   FLASHA      : origin = 0x3F4000, length = 0x003F80     /* on-chip FLASH */
   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     : origin = 0x3F7FF8, length = 0x000008     /* Part of FLASHA.  CSM password locations in FLASHA */
   
   ROM         : origin = 0x3FF000, length = 0x000FC0     /* 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                                                  */

   RAMM0       : origin = 0x000000, length = 0x000400     /* on-chip RAM block M0 */
   BOOT_RSVD   : origin = 0x000400, length = 0x000080     /* Part of M1, BOOT rom will use this for stack */
   RAMM1       : origin = 0x000480, length = 0x000380     /* on-chip RAM block M1 */
   RAML1       : origin = 0x009000, length = 0x001000     /* on-chip RAM block L1 */
   FLASHB      : origin = 0x3F0000, length = 0x004000     /* on-chip FLASH */
   RAMH0       : origin = 0x3FA000, length = 0x002000     /* on-chip RAM block H0 */
}

/* 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              : > FLASHA      PAGE = 0
   .pinit              : > FLASHA,     PAGE = 0
   .text               : > FLASHA      PAGE = 0
   codestart           : > BEGIN       PAGE = 0
   ramfuncs            : LOAD = FLASHD, 
                         RUN = RAML0, 
                         LOAD_START(_RamfuncsLoadStart),
                         LOAD_END(_RamfuncsLoadEnd),
                         RUN_START(_RamfuncsRunStart),
                         PAGE = 0

   csmpasswds          : > CSM_PWL     PAGE = 0
   csm_rsvd            : > CSM_RSVD    PAGE = 0
   
   /* Allocate uninitalized data sections: */
   .stack              : > RAMM0       PAGE = 1
   .ebss               : > RAML1       PAGE = 1
   .esysmem            : > RAMH0       PAGE = 1

   /* Initalized sections go in Flash */
   /* For SDFlash to program these, they must be allocated to page 0 */
   .econst             : > FLASHA      PAGE = 0
   .switch             : > FLASHA      PAGE = 0      

   /* Allocate IQ math areas: */
   IQmath              : > FLASHC      PAGE = 0                  /* Math Code */
   IQmathTables        : > ROM         PAGE = 0, TYPE = NOLOAD   /* Math Tables In ROM */

   /* .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.
//===========================================================================
*/

  • sanat choudhury said:
    But when I try to flash the hex file into the board I get "no source available for 0x0" error.

    How are you loading the hex file - using CCS or Uniflash?

    The "no source..." message usually just means that there is no source code correlation at that address, hence the debugger is unable to provide source level debug. The message in itself is nothing to be alarmed about, as long as the program still runs correctly.

  • Hi Aarti,

    Thank you for the reply.

    I am using ccs for flashing.

    The program is not running when the errors pops up.

    I could never run the software with the hex file.

    I am able to run the software with the .out.

    Since the example linker command file is not working, could you please tell me, what should go to 0x00 location?

    Best Regards,

    Sanat

  • Sanat,

    The code and data sections get allocated to memory as directed by the linker command file. Looking at your linker command file, code and most of the other initialized sections are allocated to Flash. RAMM0 starts at address 0x0 and .stack is allocated to it. All of this looks fine. 

    The hex converter only converts initialized sections to hex format, so I'm not sure why the section at address 0x0 is even relevant. Are you using any other options with the hex converter? Have you checked the hex output file to see if the values/addresses look ok?

    Also as a general comment, I would recommend using the latest CCS, or at least the latest version of C2000 compiler tools if at all possible, to avail of the many bug fixes and feature enhancements that come with each new version.

  • Hi Aarti,

    Thank you for your response.

    I am not using any other option in hex converter.

    I think the values/addresses in the HEX file are ok, since I verified them by loading the .out file to processor and comparing the values in memory window and in HEX file.

    One more thing that I observed here is, it works fine when I flash the generated .hex file and load symbols from .out file(Run -> Load -> Load symbols option).

    But I believe the symbol file is needed only when I want to debug. The software should give me correct output, even when I am not loading the symbols. Correct me if I am wrong.

    When I give a CPU reset the software RESET the control jumps to 0x3FFB50. I have no idea from where this address comes. I thought it should jump to 0x3F7FF6, which is configured in the linker command file and the BOOT GPIO settings also are done for the same.

    Best Regards,

    Sanat

  • Hi Aarti,
    After analyzing further I found that, 0x3FFB50 has the factory programmed boot load functions, which is responsible for jumping the software to locations 0x3F7FF6. So I have no issue with the last statement in above post.

    So the question that I have now is, why the software does not work properly without the symbols?

    I understand that debug is not possible without the symbols, because there is no linkage to the code, but the functionalities should work!!!

    Best Regards,
    Sanat
  • Sanat,

    You are correct, the code should still function correctly even if the symbolic debug information is not there. I can't explain why it does not, other than if the hex file itself is incorrect for some reason. Perhaps you could try performing a similar test with a simple, known example project, say from ControlSuite, to see if a similar hex conversion/download procedure functions correctly.

  • Hi Aarti,

    This helped. Thank you.

    Best Regards,

    Sanat