Improving Software Quality using the C-Stat Static Code Analysis Tool
The excuse that I hear the most from embedded software engineers about why they do not use a static code analyzer is that they are too expensive! The company doesn’t have the budget to purchase the static analyzer and if they do or if they do, they are too time consuming to setup and use. But first, what is a static code analysis tool? Simply put it’s a tool that performs advanced analysis of your C/C++ code without executing it. It is generally used to find bugs or ensure conformance to coding guidelines. The classic example is a compiler which finds lexical, syntactic and even some semantic mistakes. It helps you improve your code quality as well as prove alignment with standards such as MISRA C:2012.
Developers should be using a static code analyzer for many reasons such as:
The Renesas Synergy™ Platform includes a commercial static code analyzer named C-Stat that is included with IAR Embedded Workbench for Synergy. In this post, we will look at how developers can get started using C-Stat.
Even if your project was originally created using e2 Studio, C-Stat can still be used to analyze the code. To import the e2 Studio project, a developer simply needs to create a new Synergy IAR project in the same directory as the original project and IAR will automatically detect the file structure. This can be done by opening IAR and selecting the menu item Renesas->Synergy and then following the new project wizard. The cool thing about his is that a developer can now easily switch back and forth between e2 Studio and IAR.
The settings for the C-Stat analyzer are in the project options. The easiest way to access these are to right click on the project name in the project explorer and select options. Once the project options are displayed, a developer will want to select the Static Analysis category on the left hand side as shown below:
You will notice that there are several different options available to a developer in C-Stat. First, a develop has the option to setup their C-STAT checks and then export those settings to other developers. That way the whole team can be using the same settings and easily import them through the same screen. Second, there are also options available to speed up the analysis such as enabling parallel computing to use multiple cores and timing out if a single module takes too long to be analyzed. Undoubtedly this would be a module that is in a lot of trouble since the default time-out is 10 minutes! There is even a feature that will detect false positives and limit the number of messages that are displayed in the results window at a time.
Even with all these little bells and whistles, the most import option in the Static Analysis category is the Select C-STAT Checks button. This button opens all the different analyses that can be performed on the code base. These are categorized into:
The different categories available can be seen below:
Each category expands and provides a developer with the ability to fine tune the analysis and only check the rules that they feel are the most important. The defaults in many cases are appropriate for new users and for developers who are just starting to use static analysis on a mature code base. If a developer wanted to customize the settings, for example, to ensure that any unspecified behaviors were detected in the analysis, they would expand STDCHECKS, scroll to the SPC option and then select the unspecified behaviors that they want to check for as shown below:
Once a developer has identified what they want to check in their code, they can close out of the project options tab and from the Project menu select C-STAT Static Analysis -> Analyze Project. At this point, depending on the number of modules, code and parallel processes selected, the analyzer will chug away at the code looking for potential problems and non-compliances.
When the analysis is complete, a C-STAT Messages window will appear in the IDE. These messages provide a developer with the analysis results. The messages include what was detected, which check caused the violation, how severe the detection is and the file and line number that it was detected in. A developer can simply click on any message and it will take them to the file and line number and they can resolve the issue at that time.
That’s all there is to it! A simple to configure static analysis tool that doesn’t cost a Synergy developer a dime! Now there is no excuse not use static code analysis to improve your software quality and minimize your bug counts.
Until next time,
Live long and profit!
Hot Tip of the Week
There are some recent Module Guide additions (as of Sept 5, 2017) that you should check out. These app notes give you all the information, is a single place, you need to get started developing applications using the associated module. Look for the most recent additions here: https://www.renesas.com/en-us/products/synergy/tools-kits.html#documents
Some of our favorites include the DTC, SLCDC, and GLCDC HAL modules as well as the Console, USB Communications and ADC Periodic Frameworks. Get a head start on your developments when using these modules by reading, understanding and trying out the associated Application Projects.