• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 83 subscribers
  • Views 691 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Compiler/TMS320F28379D: Makefile-level defines are not seen by compiler

Jeff Campbell91
Prodigy 120 points

Part Number: TMS320F28379D

Tool/software: TI C/C++ Compiler

Hi,

I have a weird problem with multiple makefiles that have worked fine up until the other day when I had to delete everything and re-clone the repositories I was working in.

It seems that some symbols we define at compile time are no longer visible to the program, and the compiler throws an error because it cannot find the symbol values.  (This is only happening on my machine; my coworkers have not seen the same issue yet).

This is an example command our makefile generates which is still failing.

C:/ti/ccsv7/tools/compiler/ti-cgt-c2000_18.1.4.LTS/bin/cl2000 -v28 -mt -ml --cla_support=cla1 --float_support=fpu32 --tmu_support=tmu0 --vcu_support=vcu2 -Ooff --opt_for_speed=2 -g --define="CPU1" --define="_FLASH" --define="SYSCLK_MHZ=200" --define="OSCCLK_MHZ=20"  --diag_warning=225 --display_error_number --diag_suppress=232 --diag_suppress=16002 --diag_wrap=off --c99 --fp_mode=relaxed -I . -I src -I ../c2000ware/common/include -I ../c2000ware/driverlib -I ../c2000ware/headers/include -I ../Common -I ../F021_API_F2837xS/include -I ../F021_API_F2837xS/include/Constants -I C:/ti/ccsv7/tools/compiler/ti-cgt-c2000_18.1.4.LTS/include  --preproc_with_compile --obj_directory=release src/boot_obj_can.c
"src/boot_obj_can.c", line 274: error #20: identifier "SYSCLK_MHZ" is undefined
1 error detected in the compilation of "src/boot_obj_can.c".

>> Compilation failure
makefile:134: recipe for target 'release/boot_obj_can.obj' failed
gmake: *** [release/boot_obj_can.obj] Error 1

Now, the program complains that SYSCLK_MHZ is not defined, but it is clearly specified with a --define option in the command used.  What is going on here?  Is there something wrong in the order we've provided the arguments in?

  • 0
    TI__Guru**** 253410 points

    I don't see anything wrong with the invocation of the compiler.

    Please add the option --gen_preprocessor_listing, then inspect the resulting .rl file.  That will probably provide some clues about what happened.  Please read more about that option in the C28x compiler manual.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 120 points

    George,

    Thanks for the tip, that's an interesting tool.  However it seems to just confirm what I'm seeing here, the parsing fails at the first line in the code which references SYSCLK_MHZ.

    The other weird thing is that it seems like the problem starts with defines that are set to have a value.  In one project, here is the order of defines:

    • CPU1
    • _FLASH
    • SYSCLK_MHZ=200
    • OSCCLK_MHZ=20

    And in a different project for the same chip, it's this order:

    • _FLASH
    • _INLINE
    • SYSCLK_MHZ=200
    • OSCCLK_MHZ=20
    • CPU1

    The interesting thing is that it's acting as if symbols stop being accepted after SYSCLK_MHZ.  In the first project, CPU1 and _FLASH are both accepted as symbols.  However, in the second one, _FLASH and _INLINE are recognized but CPU1 is not.

  • 0 in reply to Jeff Campbell91
    TI__Guru**** 253410 points

    I am unable to reproduce this behavior.  And without that, there is nothing more we can do.

    Here is an unusual idea to consider.  Change the makefile so that it does not invoke cl2000, but a program you write.  This program echoes its command line arguments, then quits.  Implement the program in whatever language is most convenient.  It can even be a script or batch file.  You could even change the makefile to run a debugger on your program.  The general idea is to explore how command line arguments are getting from the makefile to the program. 

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Prodigy 120 points

    George,

    As a matter of fact, I had just tried your exact idea with a python script.  I've noticed some behavior that makes me suspect gmake is at fault rather than the compiler.

    I found that if I copy and paste the command that gmake prints out to the screen, and then run it myself, the compiler sees all of the #define symbols I pass to it.  That is, it seems as if what gmake prints to the screen when I have it echo the whole command is not exactly what it's passing to the compiler.  This is very strange and will take some more debugging, but it's definitely not a TI compiler issue at this point.