The Eclipse CODAN (Code Analysis) plugin is part of CDT and is a powerful static analysis tool finding all kind of possible bugs and issues. Still to my surprise not many C/C++ developers take advantage of it maybe because they are not aware that it exists?
ups! Programming error detected by CODAN
In this article I show a few tips how to effectively use it, especially with the NXP MCUXpresso SDK.
Outline
In this article I show how to use the CODAN feature in Eclipse using the NXP MCUXpresso IDE 11.2.1 and the NXP MCUXpresso SDK as example, but it applies to any other recent Eclipse distribution.
I show you how to use it and how to configure it. Because my mantra is to have warning free source code, I share my setting and tweaks how to reach this for example with the NXP MCUXpresso SDK.
For an actual example of CODAN finding a bug, see SDK I2C driver bug – NXP Community.
Usage
To run the static analysis, use the context menu on the project:
Run C C++ Code Analysis
Running this might report a lot of errors and warnings because it might catch a lot of things which might be OK for your project. But you can configure the level of checking, either on a global (workspace) or local (project) level.
The global settings are under Window > Preferences > C/C++ > Code Analysis:
Workspace Code Analysis Settings
I recommend using project specific settings:
Code Analysis project settings
A confusing part is that the global settings seem to be OR’ed with the workspace ones? This is why I have the global settings with all items unchecked:
Unchecked global settings
In the project settings I do have the following items disabled, because I do consider them as OK for my projects:
- Coding Style
- Line Comments
- Multiple Variable declaration
- Return with parenthesis
disabled checks
Suppress Issues
Issues are reported in ‘Problems’ view as well in the source editor view:
code analysis issue displayed in source editor view
Clicking on the issue shows an explanation of the issue:
Code Analysis Issue Explanation
This adds a comment to the source requesting CODAN to ignore it:
Code Analysis Suppress
Here is another example:
goto in SEGGER RTT
💡 Instead of using the ‘suppress’ menu I can simply write or paste that comment too.
It is possible to exclude files and folders for each rule: Below a check is excluded from multiple folders:
customize problem
MCUXpresso SDK
There are a few things to tweak the NXP MCUXpresso SDK to work with CODAN. First several of the header files provided by NXP lack the proper copyright information to be recognized by CODAN (see example above): these I do suppress as shown above.
Warnings for SDK
Because CODAN analyses all source files in a project, this can cause issues if unused headers are present int he project. For example the NXP SDK includes in the CMSIS folder several header files which are for different compilers: they are not needed so I have them removed:
remove not used CMSIS files
The other thing is that because RedLib (a custom library from NXP) does not fully follow the standard, CODAN reports several possible issues, including missing proper includes. I do recommend not using RedLib and using NewLib-nano instead:
Using NewLib-Nano
The SDK startup code is not ‘clean’ as it has several forward extern declarations which are not used:
not used declarations
I usually fix them with deleting the not needed declaration in the source file.
Disable Files and Folders with Resource Filter
If you are using a source library and do not want to change it for CODAN, it is possible to disable files and folders for CODAN.
To disable analysis for a specific folder is different from excluding it for a build: Code Analysis works through the Eclipse Indexer, so I have to change the settings using the Resource Filter:
- Select the folder to be excluded
- Use the Properties context menu on that folder
- Go to Resource > Resource Filter and add a new filter
- Use the following settings:
- Exclude all
- Files and Folders
- Name matches *
Excluding for Indexer
If only some files shall be excluded: use a matching name filter.
This now excludes the files in that folder. Depending on your workspace Indexer settings, trigger an Index rebuild: context menu on the project and do an Index > Rebuild.
With this it should be possible a CODAN error and warning free build.
Summary
Static code analysis is very useful to catch possible bugs early in the development cycle. Eclipse CDT includes CODAN (Code Analysis) which does a good job. It might not be comparable to expensive commercial tools, but it is very worth to use it, especially because it is easy to use and free :-). If you want to use something else (free of charge) in addition to it, a look at CppCheck too.
Happy analyzing 🙂
MCU on Eclipse 
Erich,
You don’t say much about what CODAN looks for. Does it supplant lint?
LikeLiked by 2 people
Hi Gary,
no, it does not supplant lint imho. Lint has more and in-dept tests, but is not free.
LikeLike
Hey Erich,
Thank you for the introduction – I knew about the tool before (working generic C applications in Eclipse) but didn’t think to apply it to MCUXpresso IDE projects.
I like these tools in theory, but they just don’t work out in practice; the biggest dealbreaker for me is given in your copy above; having to delete/modify library (or SDK) files to ensure error/warning free builds as doing this immediately starts making the code non-portable. Lesser issues are things like “line comments” (“//”) being flagged (I prefer them to traditional “/* … */” comments when on a single line) and “assignment in condition” (which I use a lot of but it doesn’t flag them in “for” statements) as well as “symbol is not resolved” (with FreeRTOS, I have a number of global task status variables that are defined in the .h file so they can accessed by other tasks directly without having to go through a queue request for the data). This means that I have to go through the lists and pick and choose which options I think are appropriate – which means that for new projects, the selections have to be updated/imported.
The real value of a tool like this is looking for violations of coding rules written for a project/organization. I’ve always been taught that in a multi-developer project, the code should be written to a set of rules so nobody looking at a part of the code can figure out who wrote it. Unfortunately, most tools only check for somebody’s definition of “good coding” rules.
I applaud your insistence on error/warning free builds – not enough developers understand the value of this basic but the critical piece of guidance for ensuring code will work as expected.
On that last point, I should point out that the final arbiter of errors and warnings is the compiler – with modern systems, even the largest projects can be built in a few seconds (my 40k robot code builds in less than 5s) which means that checks are just a couple of mouse clicks away. But, I can see the value of something like CODAN for students and new C/C++ coders to flag things that they should be aware of and can consider whether or not it is a problem in the application and/or writing style.
Have a Happy New Year!
myke
LikeLiked by 1 person
Hi myke,
to me it is always a combination of different tools making the job: compiler to be set to warn about nearly everything, using code reviews and using tools like CppCheck or CODAN and finally using dynamic analysis too.
Some of the implemented checks by CODAN (like the C++ comments) are debatable: for a clean C code there should be no C++ comments, but libraries I use do not stick to that rule: so I’m fine to turn that rule off, but keep my own sources clean.
It is always a balance between setting the rule checks and keeping the sources clean, same for keeping things uniform and the same across developers.
To me the CODAN checks are rather simple but still useful: better to have them than not using any. It is always shocking to see that many still are not even using the simplest checks (see https://community.nxp.com/t5/MCUXpresso-SDK/SDK-I2C-driver-bug/m-p/1205035).
Happy New Year too!
Erich
LikeLiked by 1 person
Hi Erich – Perhaps its a bad idea to run static analysis, because this happens:
https://community.nxp.com/t5/MCUXpresso-SDK/SDK-I2C-driver-bug/m-p/1205923/emcs_t/S2h8ZW1haWx8dG9waWNfc3Vic2NyaXB0aW9ufEtKSTlIWUg0VktITjVJfDEyMDU5MjN8U1VCU0NSSVBUSU9OU3xoSw
LikeLike
I think it is still an excellent idea ;-). Especially because it flags things like this.
LikeLike
And then the vendor does not take it seriously ;-(
LikeLike
yes, saw that one. I hope it still gets resolved in a proper way.
LikeLike
Pingback: Eclipse Indexer Debug Tips | MCU on Eclipse