CCS/MSP430F5527: GEL: Error: Encountered a problem loading file: <project path>\$(OUTPUT_NAME).out

Tom Herron51

Part Number: MSP430F5527

Tool/software: Code Composer Studio

I have a project that was built under CCSv5.4/CGTv4.1.5 that I'm trying to port to CCS9.2/CGTv18.12.3. I'm now at the point where my project is building successfully, and I'd like to debug it. But when I try to start the debugger, it i get the message in the title of this post (The <project path> part is my replacement) It seems the IDE is trying to using the makefile variable $(OUTPUT_NAME) but not finding it. Any idea where to start on resolving this?

Thanks

over 6 years ago

0 JohnS over 6 years ago

TI__Guru**** 162885 points

Tom,

The round brackets look funny. Normally variables use ${name}.

Can you click on the little down arrow beside the bug button and select "Debug Configurations". This will open the debug configuration dialog. Then select your project on the left. Then click on the program tab on the right.

What does it show in the "Program" box. It should have ${build_artifact:<projectname>} i.e. use the artifact resulting from the build of <projectname>

Regards,

John

0 Tom Herron51 over 6 years ago

Intellectual 320 points

Hi John,

Thanks for the quick reply. I did as you suggest and the program name is set as you describe.

I did notice something though. There is an actual file in my project folder named "$(OUTPUT_NAME).out". It gets created when I click the debug button as gmake is checking that my project is up to date. And $(OUTPUT_NAME).out is how my project output is referenced in my makefile (see snippet below). So it seems gmake is getting confused when it is called before debugging. However, gmake works fine when I click the build button; it generates a file with my expected project output name.

FWIW, the $(OUTPUT_NAME).out is an empty file of 0 bytes.

Tom

# All Target
all:
	@$(MAKE) --no-print-directory pre-build
	@$(MAKE) --no-print-directory main-build

# Main-build Target
main-build: $(OUTPUT_NAME).out

# Tool invocations
$(OUTPUT_NAME).out: $(OBJS) $(CMD_SRCS) $(GEN_CMDS)
	@echo 'Building target: "$@"'
	@echo 'Invoking: MSP430 Linker'
	"C:/ti/ccs920/ccs/tools/compiler/ti-cgt-msp430_18.12.3.LTS/bin/cl430" -vmspx --data_model=restricted -O3 --opt_for_speed=0 --use_hw_mpy=F5 --define=VMAJOR=$(VMAJOR) --define=VMINOR=$(VMINOR) --define=VBUG=$(VBUG) --define=__MSP430F$(CPU)__ --define=$(ENC) --define=RFIDEN=$(RFIDEN) -g --printf_support=minimal --diag_warning=225 --diag_wrap=off --display_error_number --abi=eabi --large_memory_model --silicon_errata=CPU40 -z -m"$(OUTPUT_NAME).map" --heap_size=160 --stack_size=1600 --cinit_hold_wdt=on -i"C:/ti/ccs920/ccs/ccs_base/msp430/include" -i"C:/ti/ccs920/ccs/ccs_base/msp430/include" -i"C:/ti/ccs920/ccs/tools/compiler/ti-cgt-msp430_18.12.3.LTS/lib" -i"C:/ti/ccs920/ccs/tools/compiler/ti-cgt-msp430_18.12.3.LTS/include" -i"C:/ti/ccs920/ccs/ccs_base/msp430/lib/5xx_6xx_FRxx" --reread_libs --diag_wrap=off --display_error_number --warn_sections --xml_link_info="$(OUTPUT_NAME)_linkInfo.xml" --use_hw_mpy=F5 --rom_model -o $(OUTPUT_NAME).out $(ORDERED_OBJS)
	@echo 'Finished building target: "$@"'
	@echo ' '
	@$(MAKE) --no-print-directory post-build

$(OUTPUT_NAME).txt: $(EXE_OUTPUTS)
	@echo 'Building files: $(strip $(EXE_OUTPUTS__QUOTED))'
	@echo 'Invoking: MSP430 Hex Utility'
	"C:/ti/ccs920/ccs/tools/compiler/ti-cgt-msp430_18.12.3.LTS/bin/hex430" --memwidth=8 --romwidth=8 -o $(OUTPUT_NAME).txt $(EXE_OUTPUTS__QUOTED)
	@echo 'Finished building: $(strip $(EXE_OUTPUTS__QUOTED))'
	@echo ' '
	@$(MAKE) --no-print-directory post-build

0 JohnS over 6 years ago in reply to Tom Herron51

TI__Guru**** 162885 points

Tom,

That is really strange. Is the $(OUTPUT_NAME).out getting built each time or is it left over from some old build?

Is that a generated makefile in your post or are you managing the makefile yourself? CCS typically generates a makefile and 4 .mk files. However they all have a header that says # Automatically-generated file. Do not edit.

John

0 Tom Herron51 over 6 years ago in reply to JohnS

Intellectual 320 points

John,

I'm gradually getting this figured out. I think the source of the problem is a botched conversion of the source repository from SVN to git.

The CCS5 project was stored in a SVN repository, but I've been using git recently and thought I'd convert the repository to git. I read a couple forum posts about how to do this, but missed the part about using the --standard-layout option with "git svn clone" As a result, I ended up with my project nested inside a trunk folder inside my project folder (e.g., workspace_9_2/MyProj/trunk/<project files>) Initially, I didn't think this would be a big issue, but now I'm thinking CCS is getting confused by settings that were written when the project was a level higher in the workspace tree.

I'm now redoing the conversion using the standard-layout option and will let you know how it goes.

Tom

0 Tom Herron51 over 6 years ago in reply to Tom Herron51

Intellectual 320 points

John,

Redoing the SVN to Git conversion so that the project structure remained the same solved the problem (I still don't understand what the problem was, but at least I have a solution!)

Here was my process:

I used git svn clone --stdlayout <svn-repo>/<project> <git-repo-name> to create git repository without the trunk/branches/tags in the repository
I put the git repo on my desktop and had CCS import and "copy files to workspace". Initially, I had the repo in my workspace and tried to import without copying, but I got an "invalid project description" error.

Hope someone finds this helpful.

Tom

0 JohnS over 6 years ago in reply to Tom Herron51

TI__Guru**** 162885 points

Tom,

That is great!

John

Code Composer Studio™︎

Code Composer Studio forum

CCS/MSP430F5527: GEL: Error: Encountered a problem loading file: <project path>\$(OUTPUT_NAME).out