Makefile project: CCS does not "know" macros predefined by compiler like __TMS320C28XX__

Hello,

This functionality would rely on the indexer and there may be a dependency on a managed make project vs a custom makefile project. I will need to take a closer look to see if this can be supported in the latter.

Thanks

ki

Thank you. Could you have a look at this minimal 'led_ex1_blinky' code (attached below)? I derived it from the driverlib-example for the TMS320F28388 CPU. It compiles fine from outside CCS by running "gmake". Import it into CCS:

• New -> C/C++-Project -> Makefile project with Existing code
• Call it "makefile_led_ex1_blinky"
• Select the directory where you unpacked the ZIP file
• Choose "TI Build Tools" as Toolchain for Indexer Support
• You might need to adjust the directories in my Makefile

Inside CCS, "Build Project" and "Clean Project" work fine. But the indexing is broken as described in the original post. How to fix this or how to work around this issue?

Best regards, Nils

makefile_led_ex1_blinky.zip

Thank you, this is helpful. I will try with your example project

Great, I'm looking forward to hear from you!

Hello,

It looks like the indexer is working for a custom makefile project. I can jump to declaration (F3) and the editor shading of inactive code seems to be working. If none of these are working, did you select a toolchain for the indexer settings when creating the custom makefile project?

As for:

Nils Larsen said:

he editor shows many "Symbol xxx could not be resolved" altough the compiler finishes without warnings. The reason is that CCS does not recognize that the compiler automatically defines some macros like __TMS320C28XX__ and more macros are defined on the compiler command line by our Makefile. In the editor, the code gets treated as if non of these macros were defined.

This part would be expected false positives from the static code analysis tool (CODAN) that comes with CCS Eclipse. We recommend disabling this to avoid confusion

https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/944045/ccs-drv8301-69m-kit-error-after-first-build-with-iqmpy/3487430#3487430

Nils Larsen said:

And even worse, when stepping though the code in the CCS debugger, the program and the shown line gets out of synchronization, also because debugger thinks these macro are not defined.

This part confuses me. Regardless of the CODAN false positives, it should not have any impact during debug. The shown lines should correspond with the debug information in the compiled executables. CODAN / indexer should have no impact on debug. If you are getting mismatch source line correlation during debug, it is more likely an issue with debugging optimized code or the wrong source file is being referenced.

Thansk

ki

Thank you for testing my custom makefile project! Your feedback is already very useful.

To answer your question, yes, I selected "TI Build Tools" as Toolchain for the Indexer.

Jump to declaration (F3)
I can jump to the declaration of Device_init() and Device_initGPIO() with F3. But not to the declaration of GPIO_setPadConfig(). The difference is that the former are part of the source code in the project folder and the latter is part of "driverlib" outside of the project folder. Do you experience the same behavior? If yes, is there a way to "fix" this?

False positives Errors from Code Analysis (CODAN)
Thank you for the explanation. It is a good idea just to disable that (Project Settings -> Code analysis). For us, it is enough to see the "real" compiler errors. Unfortunately, the compiler output does not get parsed correctly. If I add an extra parameter GPIO_setDirectionMode(), I can see "too many arguments" in the Problems pane, but neither the file nor the line number are "understood", so I have to manually look in the CDT Build console to see ""led_ex1_blinky.c", line 76: error #141: too many arguments in function call". Clicking there also does not "send" me anywhere. Can it be "fixed"?

Shading of inactive code sections
I also see shading, but the wrong sections get shaded. If you open Device_init() in device.c, the section "#ifdef CPU1" gets shaded (=inactive), but actually CPU1 is defined and the section is compiled. It looks like we also have to do without this nice feature, if we go with Makefile-based projects? Can the shading of inactive settings only be disabled globally (Window->Preferences->C/C++->Editor->Inactive code highlight) or per project or per workspace?

Impact during debugging - it works
I'm sorry, you are right, it works. After checking again, the program and the shown line are actually perfectly synchronized, also inside sections falsely shaded as inactive.

Best regards, Nils

Thank you for the link. That actually solves my opening question: In Project Settings ->C/C++ General -> "Preprocessor Include Paths, ..." I can add "CDT User Setting Entries" and instruct the indexer and CODAN to threat a macro like CPU1 or __TMS320C28XX__ to be predefined and I can also add additional include paths. I can now fix the "inactive code shading" and "Jump to declaration" issues by adding more entries. Ok, it is pretty clumsy (because I need to manually keep it in sync with the Makefile), but at least possible.

What still does not work is this part:

If I add an extra parameter GPIO_setDirectionMode(), I can see "too many arguments" in the Problems pane, but neither the file nor the line number are "understood", so I have to manually look in the CDT Build console to see ""led_ex1_blinky.c", line 76: error #141: too many arguments in function call". Clicking there also does not "send" me anywhere.

Probably we have to live with that and see what Theia IDE can do for us (thank you also for this hint).