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.

  • Resolved

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

Part Number: TMS320F2808

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

  • Guru 149285 points

    sanat choudhury
    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.

    ____________________________________________________________________________

    Please click This Resolved My Issue if the reply answers your question.

    Search the wikis for common questions: Compiler, CCSv6, CCSv7
    Track a known bug with SDOWP. Enter the bug id in the "Find Record ID" box

  • In reply to AartiG:

    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

  • Guru 149285 points

    In reply to sanat choudhury:

    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.

    ____________________________________________________________________________

    Please click This Resolved My Issue if the reply answers your question.

    Search the wikis for common questions: Compiler, CCSv6, CCSv7
    Track a known bug with SDOWP. Enter the bug id in the "Find Record ID" box

  • In reply to AartiG:

    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

  • In reply to sanat choudhury:

    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
  • Guru 149285 points

    In reply to sanat choudhury:

    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.

    ____________________________________________________________________________

    Please click This Resolved My Issue if the reply answers your question.

    Search the wikis for common questions: Compiler, CCSv6, CCSv7
    Track a known bug with SDOWP. Enter the bug id in the "Find Record ID" box

  • In reply to AartiG:

    Hi Aarti,

    This helped. Thank you.

    Best Regards,

    Sanat

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.