• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Answers 1 answer
  • Subscribers 60 subscribers
  • Views 8472 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CCS6 Assembly Project Error "No source available for "0x0""

HAL9000
Prodigy 30 points
Other Parts Discussed in Thread: MSP430FG4618, MSP430F4250

I am having a problem creating new assembly only projects in CCS.  Every new project I create I get the same error "No source available for "0x0"".  Projects imported from CSS5.5 compile and run fine.  I can write new code into old CCS5.5 projects an run it.  I have used the default code prefilled by CCS6 as well as deleting the prefilled code and replacing with working code from a CSS5.5 project and neither worked.  I have defined the entry point in the code as well as the linker options.  I have also tried both the eabi and the legacy COFF output formats.

I am running Windows 8.1 and CCS6.01.  The device is a MSP430FG4618 connected via a MSP-FET430UIF.  The UIF has been updated to the latest firmware. I have included a copy of the prefilled code with the entry point defined.  I have also attached a screen shot of the error.

This error was reproduced by a TI representative using a different computer, MSP430FG4618 and the new interface module during at the opening of a new engineering laboratory at my university.  He would also like to be informed of the response to this issue.  Thank you.

;-------------------------------------------------------------------------------
; MSP430 Assembler Code Template for use with TI Code Composer Studio
;
;
;-------------------------------------------------------------------------------
            .cdecls C,LIST,"msp430.h"       ; Include device header file

;-------------------------------------------------------------------------------
            .text                           ; Assemble into program memory
            .retain                         ; Override ELF conditional linking
                                            ; and retain current section
            .retainrefs                     ; Additionally retain any sections
                                            ; that have references to current
                                            ; section
            .global RESET
;-------------------------------------------------------------------------------
RESET       mov.w   #__STACK_END,SP         ; Initialize stackpointer
StopWDT     mov.w   #WDTPW|WDTHOLD,&WDTCTL  ; Stop watchdog timer

;-------------------------------------------------------------------------------
                                            ; Main loop here
;-------------------------------------------------------------------------------


;-------------------------------------------------------------------------------
;           Stack Pointer definition
;-------------------------------------------------------------------------------
            .global __STACK_END
            .sect 	.stack

;-------------------------------------------------------------------------------
;           Interrupt Vectors
;-------------------------------------------------------------------------------
            .sect   ".reset"                ; MSP430 RESET Vector
            .short  RESET

  • 0
    TI__Guru**** 421490 points

    Hello,

    The default location for .text (your code) is FLASH2 and FLASH sections at addresses 0x10000 and 0x3100. Why is the PC at address 0? Is that where it automatically goes when you launch a debug session?

    ki

  • 0
    TI__Guru**** 173310 points

    I can reproduce this behavior but so far have not been able to narrow down or determine what the difference is in the CCSv6 projects. I will file a bug report on this for further analysis.

    In the meantime, a workaround you could use is after loading the code, type RESET in the Disassembly view (where it says "Enter location here"), then click on the first line of code, right-click and select Move to Line. That should set the PC to that address and allow you to debug from there.

  • 0 in reply to AartiG
    TI__Guru**** 421490 points

    Thanks Aarti. I was looking for a 4619 to confirm. I tried on a F2013 with CCSv6.0.1 and there was no issue there.

  • 0 in reply to Ki
    Prodigy 30 points

    Yes, the only two things I changed from the prefilled code was the .global RESET line and setting the entry point in the linker properties to eliminate the entry point not defined error.

  • 0 in reply to HAL9000
    TI__Guru**** 173310 points

    The bug tracking # for this issue is SDSCM00050904. You may track its status using the SDOWP link in my signature.

  • 0 in reply to AartiG
    Prodigy 30 points

    That does work for a program that flows from start to finish.  Unfortunately the work around must be repeated for every call and return because the debugger sees the addresses as out of range and returns the PC to 0x0. When building every command that access RAM gets error #17003-D. It is possible to run but you must keep track of the return points manually.  I have just been deleting the code from old CCS5 projects, cleaning, typing new code, and rebuilding.  Seems to work.

  • 0 in reply to HAL9000
    Expert 1505 points

    Katie has a work around that is better for this.  It is at .

  • 0
    Prodigy 10 points

    What I've found about that is that the problem lies in lnk_msp430[_whatever_your_msp_cpu_is].cmd file. This file describes the partitions of memory in your mcu and the valid sections. In SECTIONS section of the file .text it gives the line:

       .text       : {}>> FLASH2 | FLASH /* Code                              */

    in large data model. This means that when you add something in that .text it first occupies space in FLASH2 portion and then in FLASH. Earlier in the same file, in MEMORY section of the file, FLASH2 is defined as:

       FLASH2                  : origin = 0x10000,length = 0x10000

    When you compile your program it has to put in .reset vector the valid address for your RESET label. The vector's length is one word = 16 bits. This label lies in 10000h address (which is more than 16 bits long), while in .reset only the low word is stored which is 0000h. That is why it sees 0x0 as your entry point and the program is not working.

    In order to make it work you have to change the order of .text as FLASH | FLASH2, or create another section that occupies only the lower part of flash memory in your device. Remember that all vectors are 16 bits long and all those interrupt service routines must lie in the lower part of flash..

    Hope this helped you

    Elias

  • 0 in reply to AartiG
    Expert 1345 points
    Dear AartiG;

    I have experienced the same problem as HAL9000.

    I went to look at the bug tracking number: SDSCM00050904, found a webpage but I did not see any solution. Can you please post the solution to this problem? Specifically, how does one configure CCS6 to find the correct entry point? Thank you for your time.
  • 0 in reply to Michael Choi
    TI__Guru**** 173310 points

    The workaround has been described by Elias in the post prior to yours.

    Open the linker command file in your project and change the following line:

    .text       : {}>> FLASH2 | FLASH

    to

    .text       : {}>> FLASH | FLASH2

  • 0 in reply to AartiG
    Prodigy 20 points

    Where is the 'linker command file'?  Is that msp430f4250.ld file or is it one of the files in Debug or targetConfigs directory? 

    Additionally, in the .ld file, I find neither FLASH nor FLASH2

    I'm having the same problem with CCS v6 and a msp430f4250 device.

  • 0 in reply to Richard Newman1
    Prodigy 100 points

    No, the msp430f4250.ld is the linker file that is created when you choose to use GCC compiler (if I remember well...)


    The file that contains the sections and memory configurations is called lnk_msp430f4250.cmd and is created by the system (well, copied into your project's directory) when you use TI's toolchain. The toolchain is selected when you first create the Code Composer Studio project. But in your case 4250 does not have a problem using higher flash memory (FLASH2) because... it does not contain any...

    Anyway, just to make it clear I put two snapshots to present were you choose the toolchain and what the file in question is.

  • 0 in reply to Elias Chrysoheris
    Prodigy 10 points
    Thank you for solving my problem!