MSP430FR5969 example code fails to compile..

Dr. Fullmer,

Try using the small data model option in your project, but don't ask me where to specify it. But you're right - this should have worked out-of-the-box.

--Randy

Well, I've diddled with the code/data model settings to no avail...

The problem seems to be with the /driverlib library files.. the files are not getting rebuilt, even on a clean, and the linker is pulling the library in from another project (unclear at this point - and nested make files are not my forte..  and these makefiles are all generated automagically which makes it even harder to trouble shoot, at least for me..  )

The build works like the other OutOfBox and 430BOOST-SHARP96_GrlibExample_FR5969 demos, etc.. so not clear where its picking up the access to the previously compiled files...  the project has its own set of driverlib/ directory and files to build.. but doesn't appear to use them.. sigh...

I'm still under the impression it is a simple configuration fix that is eluding me quite well at the moment :)

Hi Dr. Fullmer,

Apologies for the issue that you have encountered with the example code.

Here's some info on the16KB project: The 16KB example project is included to enable users of the Free License CCS to still build and debug projects that exceeds the 16KB code size limit. It bypasses the code size limit by including a special pre-built library file of some of the larger .c files that caused the original project to exceed the size limit (430BOOST-SHARP96_ULP_FRAM_Lib.lib in this case). This is why these .c files have been excluded from the 16KB project (because they are built into the .lib).

From the error log you posted above, it looks like there's a mismatch between the project setting (specifically data memory model) used to build the 430BOOST-SHARP96_ULP_FRAM_Lib.lib and your 16KB project.

Please make sure your project setting for the data memory model is set to small or blank by right clicking the Project name -> Properties->Build->MSP430 Compiler->Processor Options:

Note: The 20-bit MSP430X devices use the small data model by default (blank)

I'm not sure why --data_model=restricted had been added to the project setting, but the 16KB project should default to blank for the data memory model and build out of the box.

Hopefully this helps.

Best Regards,
Eric C.

Hi Eric..

I can't seem to beat the -- large_memory_model flag from being set..

Even though both the code and data models are set to small (or blank) the large_memory_model stays set.. :(

Where is that being set, do you know?

Also, notice the warnings from the incompatible redefinition of a macro..there are more, this is just the first two..

--------------------

**** Build of configuration Debug for project 430BOOST-SHARP96_ULP_FRAM_16KB ****

"C:\\TexasInstruments\\ccsv6\\utils\\bin\\gmake" all
'Building file: ../ActivePowerMeasure.c'
'Invoking: MSP430 Compiler'
"C:/TexasInstruments/ccsv6/tools/compiler/msp430_4.3.3/bin/cl430" -vmspx --abi=eabi --code_model=small --data_model=small --near_data=globals -O4 --opt_for_speed=0 --include_path="C:/TexasInstruments/ccsv6/ccs_base/msp430/include" --include_path="C:/TexasInstruments/ccsv6/tools/compiler/msp430_4.3.3/include" --include_path="C:/Projects/TexasInstruments/workspace_v6_0/430BOOST-SHARP96_ULP_FRAM_16KB" --include_path="C:/Projects/TexasInstruments/workspace_v6_0/430BOOST-SHARP96_ULP_FRAM_16KB/driverlib/MSP430FR5xx_6xx" --advice:hw_config="1" -g --gcc --define=__MSP430FR5969__ --diag_warning=225 --display_error_number --diag_wrap=off --silicon_errata=CPU21 --silicon_errata=CPU22 --silicon_errata=CPU40 --large_memory_model --printf_support=minimal --preproc_with_compile --preproc_dependency="ActivePowerMeasure.pp"  "../ActivePowerMeasure.c"
>> WARNING: Small code model requires small data model as well.  Small data model is being used.
>> WARNING: --near_data is only applicable for large data models. Option ignored.
"C:\Projects\TexasInstruments\workspace_v6_0\430BOOST-SHARP96_ULP_FRAM_16KB\driverlib\MSP430FR5xx_6xx\inc\../deprecated/CCS/msp430fr5xx_6xxgeneric.h", line 160: warning #48-D: incompatible redefinition of macro "LPM0" (declared at line 134 of "C:\TexasInstruments\ccsv6\ccs_base\msp430\include\msp430fr5969.h")
"C:\Projects\TexasInstruments\workspace_v6_0\430BOOST-SHARP96_ULP_FRAM_16KB\driverlib\MSP430FR5xx_6xx\inc\../deprecated/CCS/msp430fr5xx_6xxgeneric.h", line 161: warning #48-D: incompatible redefinition of macro "LPM0_EXIT" (declared at line 135 of "C:\TexasInstruments\ccsv6\ccs_base\msp430\include\msp430fr5969.h")
"C:\Projects\TexasInstruments\workspace_v6_0\430BOOST-SHARP96_ULP_FRAM_16KB\driverlib\MSP430FR5xx_6xx\inc\../deprecated/CCS/msp430fr5xx_6xxgeneric.h", line 162: warning #48-D: incompatible redefinition of macro "LPM1" (declared at line 136 of "C:\TexasInstruments\ccsv6\ccs_base\msp430\include\msp430fr5969.h")

Dr. Fullmer,

I cannot answer your question or solve your problem, but I can feel your pain. The problem you're encountering here is the exact reason I greatly dislike using IDEs and, for some 15 years now, have instead opted for using my own gnu-make based build systems. With this method I see ALL the options I've set EXPLICITLY and have complete control over them via the textual .mak files.

Having said this, I do know one thing you can try, at least temporarily. I've done this occasionally when trying to get a stubborn CCS project to build. Open a DOS command window (if you're on Windows, or something like an xterm if you're on linux) and copy the compile and link commands (one at a time) from the CCS window. Then try manually changing the data model option and run the command in the (e.g.) command window. Then if you can get it to build that way you know with confidence the problem is just an option buried somewhere in the IDE you need to change.

--Randy

And now that I read your most recent post... I see you've done just that (copied the command). Yeah, it looks like CCS has somehow generated conflicting options for your project: "--data_model=restricted" at one point and "--large_memory_model" later on. You also have that conflicting --near_data option specified as well as stated in the linker message.

I would remove the --near_data and --data_model options completely, change --data_model=restricted to --data_model=small, and change --code_model=small to --code_model=large. See how that works.

--Randy

PSS: For your reference, here is the link command I'm using in my current project (not that it necessarily will work for you):

/home/ess-src/../ess-tool/linux/ti/msp430/cgtools/4.3.1/bin/lnk430 --use_hw_mpy=F5 --reread_libs --warn_sections --rom_model   -i`cyg2dos /home/ess-src/../ess-tool/linux/ti/msp430/cgtools/4.3.1/lib/`  -i`cyg2dos /home/ess-src/../ess-tool/linux/ti/msp430/include/`  -i`cyg2dos /home/ess-src/lib/lib/`  `cyg2dos /tmp/yates/home/ess-src/app/ess/msp-explinux/ess.obj /tmp/yates/home/ess-src/app/ess/msp-explinux/pre_init.obj /tmp/yates/home/ess-src/app/ess/msp-explinux/taskuserout.obj /tmp/yates/home/ess-src/app/ess/msp-explinux/taskhwcontrol.obj /tmp/yates/home/ess-src/app/ess/msp-explinux/tasktest.obj /home/ess-src/lib/lib/freertos.a /home/ess-src/lib/lib/hal.a /home/ess-src/lib/lib/essstate.a /home/ess-src/lib/lib/i2c.a ess.cmd` -l`cyg2dos libc.a` -m `cyg2dos /home/ess-src/app/ess/ess.map`  -o `cyg2dos /home/ess-src/app/ess/ess.out`  

A couple of notes: 1) this is under linux, 2) the long paths in the library (.a) and object (.obj) files are because I put all generated files off in a temporary directory.

One more note on that command above: the `cyg2dos ...` strings are a clever way I've come up with to get the same build to work under linux and windows/cygwin. the "`" means "run the command inside me and use the result". cyg2dos does nothing under linux (and hence uses the specified linux-style path), but under cygwin cyg2dos converts "/home/xyz" paths to "/cygdrive/c/xyz" paths.

Correction: but under cygwin cyg2dos converts "/cygdrive/c/xyz" paths to "c:/xyz" paths.

Well, sorry for this long string of corrections and responses, but I just realized I don't even specify the memory models in my link command, but I do in the compile command. Again, here's an example one from my current project;

/home/ess-src/../ess-tool/linux/ti/msp430/cgtools/4.3.1/bin/cl430 --compile_only `cyg2dos /home/ess-src/app/ess/ess.c` -fe `cyg2dos /tmp/yates/home/ess-src/app/ess/msp-explinux/ess.obj` -vmspx --code_model=large --data_model=small -g --gcc --diag_warning=225 --display_error_number --diag_suppress=172 --silicon_errata=CPU21 --silicon_errata=CPU22 --silicon_errata=CPU23 --silicon_errata=CPU40 --printf_support=full -fr `cyg2dos /tmp/yates/home/ess-src/app/ess/msp-explinux` -ft `cyg2dos /tmp/yates/home/ess-src/app/ess/msp-explinux`  --define=__MSP430F5438A__ --define=__DISABLE_SMCLK__ --define=TARGET_MSP_EXP --define=PLATFORM_LINUX --include_path=`cyg2dos /home/ess-src/../ess-tool/linux/ti/msp430/cgtools/4.3.1/include/` --include_path=`cyg2dos /home/ess-src/../ess-tool/linux/ti/msp430/include/` --include_path=`cyg2dos /home/ess-src/lib/inc/` 

Hi guys..

Both of your suggestions helped and solved the issue...

Setting the include file as Leo suggested cleared all the warnings about redefinition..

Setting the data=small and the code=large solved the library incompatibility..:)

And finally setting the --near_data to globals (seems it won't take the blank setting), made that warning go away..

So, now its compiled, and I'll see if it loads and runs :)

Thanks again Randy and Leo..

(and yes Randy I agree with your rake on IDEs.. and will revisit  your details on this)