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/MSP430F5527: How to incorporate version number to output file name?

Part Number: MSP430F5527

Tool/software: Code Composer Studio

I am trying to update a project I did 6 years ago under CCSv5 to CCSv8.  However, I did something too-clever-by-half back then to get the output file name to include my firmware version number.  Although I never had a problem under CCSv5, it's not working under CCSv8.   I'll try to explain what I did, and then maybe someone can explain a better way.

In makefile.init, I added defines for my firmware version and configuration options and used them to define an output file name, OUTPUT_NAME.

VMAJOR = 1
VMINOR = 2
VBUG = 3

CPU    = 5527
OPTION = 1

ifeq ($(OPTION),1)
OPTEXT = O
else
OPTEXT = X
endif

OUTPUT_NAME = $(CONFIG_NAME)-V$(VMAJOR).$(VMINOR).$(VBUG)-$(OPTEXT)

Then in makefile.defs I added a rule to build a source file containing a datecode that gets updated anytime the project is built.

# This file inserts the datacode object as a dependency between source objects and 
# output file.  So if any change to source occurs, the datecode object gets rebuilt
# and then that triggers rebuilding of the output file.

PERL_TOOL = "C:\Perl64\bin\perl.exe"	# ActivePerl 5.18.2

MY_OBJS := $(OBJS)		# create a copy of the source object list
OBJS := datecode.obj	# make output file dependent only on date code object

ORDERED_OBJS += datecode.obj	# add datecode object to list of objects to be linked into output

datecode.obj: $(MY_OBJS) $(GEN_CMDS) $(CMD_SRCS)	# data code object is dependent on source objects
# -------
# generate data code source file
# -------
	@echo 'Generating datacode.c'
	$(PERL_TOOL) ../datecode.pl ../datecode.c
	@echo ' '
# -------
# compile the file
# -------
	@echo 'Building file: datecode.c'
	@echo 'Invoking: MSP430 Compiler'
	"$(CG_TOOL_ROOT)/bin/cl430" -vmspx --abi=eabi -O3 --opt_for_speed=0 -g \
	--use_hw_mpy=F5 --define=__MSP430F$(CPU)__ --silicon_errata=CPU40 \
	--data_model=restricted --large_memory_model --preproc_with_compile "../datecode.c"
	@echo 'Finished building: datecode.c'
	@echo ' '
# -------
# delete the source
# -------
	@echo 'Removing datacode.c'
	$(RM) "$(subst /,\,$(CWD)/../datecode.c)"
	@echo ' '

Finally, I went into Project Properties>Build>MSP430 Linker>Basic Options and set map file name to "$(OUTPUT_NAME).map" and output file name to $(OUTPUT_NAME).out.  (Note quotes are only on map file.  Not sure why I did that or if it's important)

After importing this to CCSv8, I'm having two issues:

  1. After cleaning, source files don't get built.  This has something to do with my trick to insert the datecode rule--if I remove that the build works normally. Otherwise I have to select the source files and click "build selected file(s)" from the context menu.  After that building the output works.
  2. Once the output is built, clicking the debug button results in error message: "Encountered a problem loading file: C:\<long path name>\Test\Test\$(OUTPUT_NAME)."  I looked in the debug configuration and the program name is ${build_artifact:Test}.  Apparently, CCSv8 is taking this literally and using the name specified in the linker options where CCSv5 used the result of the output name from gmake.

Attached is a zip file with a stripped down version of my project demonstrating the problems.  It was built using CCSv8.3

5417.Test.zip

For now, I've copied my source code into a new CCSv8 project and am building the output with the default name, which works.  To get the datecode, I added a prebuild step that always builds the datecode object before every build whether the project needs building or not.  It's not elegant, but it's working.

If you know how to fix this or a better way to incorporate a datecode and filename version, I'm eager to hear.  

  • Tom Herron51 said:
    Then in makefile.defs I added a rule to build a source file containing a datecode that gets updated anytime the project is built.

    I'm not sure that makefile.defs is the right place to do this. That file is typically used for defining additional make rules for SYS/BIOS projects. Were you able to get the same thing working correctly with CCSv5 with those rules in makefiles.def?

    Another way to do this would be to call the perl script as a pre-build step and just let CCS handle building the generated datecode.c. So basically remove the makefile.defs from the project (or rename it), go to the Project Properties->Build->Steps tab, and add a pre-build step like:

    perl ../datecode.pl ../datecode.c

    Then in the main build step, the generated datecode.c will be pulled in along with the other source files. Would that achieve what you were looking for?

    However, I don't see how or where the date and timestamp are being used. They appear to be getting optimized out. Do you plan to use/reference these variables somewhere?

  • Thanks for the reply, .  

    Yes, this worked well under CCSv5.  If no source files were out of date, the make file would say "nothing to build"  I'm now doing what you suggest and using a prebuild step.  But there's no smarts here and the datecode gets recompiled regardless of whether the project is up to date.

    As for getting the version number in the output file, I am using a post build step to make a copy of the output file with the version ID'd file name.  I can then copy this to a distribution folder when changes have proved out.

    You're right that the date code is not used.  This is a stripped down version of my project which contains proprietary client info.

  • Tom,

    I just imported your project into CCS 8.3 and did some testing. 

    Tom Herron51 said:
    After cleaning, source files don't get built.  This has something to do with my trick to insert the datecode rule--if I remove that the build works normally. Otherwise I have to select the source files and click "build selected file(s)" from the context menu.  After that building the output works.

    I was able to reproduce this and seems the issue here is that the datecode.obj is not getting cleaned as part of the default clean rule. And because that .obj file is left behind, it probably confuses the build system into thinking that the source files do not need to be rebuilt. 

    I created a new file named makefile.targets. In it, I added a custom rule to delete datecode.obj. Then I added the rule to the Builder and described in this page (under "Example of using makefile.targets"):

    http://software-dl.ti.com/ccs/esd/documents/users_guide/ccs_project-management.html#makefiles

    After this the clean/build worked as expected.

    Tom Herron51 said:
    Once the output is built, clicking the debug button results in error message: "Encountered a problem loading file: C:\<long path name>\Test\Test\$(OUTPUT_NAME)."  I looked in the debug configuration and the program name is ${build_artifact:Test}.  Apparently, CCSv8 is taking this literally and using the name specified in the linker options where CCSv5 used the result of the output name from gmake.

    Yes since the output file name in Linker options is specified as $(OUTPUT-NAME).out, that is being interpreted literally. Typically the syntax to resolve it as a variable would be ${OUTPUT_NAME} but then OUTPUT_NAME would need to be a CCS build variable.

    I don't know how CCSv5 interpreted this correctly. Perhaps something changed in the makefile/build process between v5 and v8.

    A workaround to load the file is to launch the debugger and load the .out file manually, instead of clicking the Debug button. More information on manual launch is here: 
    http://software-dl.ti.com/ccs/esd/documents/users_guide/ccs_debug-main.html#manual-launch

    I understand that's likely not the solution you were looking for. I will think about this a bit more and if I come up with another way to make this work, I will let you know. 

  • AartiG,

    Thank you for your reply and sorry to be slow to respond--it's been a big holiday week here in the US.

    You are correct about the makefile not building.  That was my error.  I finally realized that I was literally telling gmake to ignore the source dependencies by replacing them with just the datecode.obj dependency.  I changed OBJS assignment in makefile.init to use += and everything works as intended.  This tells gmake to rebuild if datecode.obj is missing or if any source object is out of date

    PROJ_OBJS := $(OBJS)
    OBJS += datecode.obj
    
    ORDERED_OBJS += datecode.obj
    
    datecode.obj: $(PROJ_OBJS) $(CMD_SRCS) $(GEN_CMDS)
    	@echo 'Generating datacode.c'
    	"C:\Perl64\bin\perl.exe"  ../datecode.pl ../Source/datecode.c
    	@echo ' '
       <truncated>

    As for not being able to name the output file, I'm ok with that now.  The #1 thing I wanted was to ensure the hex file had the version in the name, and I'm doing that by copying the hex file to a one with the version number in a post build step.  

    I'll mark this case closed.