Robust Development Methodologies (I)

Introduction

You now have run your own, simple, application developed with ARM Keil. However, you have little to no knowledge whether this simple application could be used - from a qualitative standpoint - in a safety environment. This codelab aims at adding this dimension to your project so as to have sound foundations for future work.

What you’ll build

In this codelab, you will understand the required tools and guidelines for building qualitatively good SW - attitude that should be used while creating any type of SW. You will also understand how to interpret the results delivered by the tools used in order to improve your work.

What you’ll learn

• How to set up the tools for ensuring MISRA compliancy.
• Start ensuring quality throughout the development lifecycle.
• Understand the different elements composing quality and to interpret the results provided by the different analysis tools.

What you’ll need

• You need to have completed the Getting started with keil codelab.
• You need to have finished the Digging into RTX.

Install the MISRA checker - cppcheck

During this course, we will use cppcheck for ensuring our code conforms to MISRA guidelines. In order to install it, head to cppcheck - Download , download and install the appropriate package (while ignoring Windows warning as the installer is not signed) - make sure you install Python Addons as well.

Install version 2.10

Due to an issue with the presently available version, make sure you pick version 2.10 so ensure that the analysis works reliably

Do not forget to add the application to your $PATH (as the installer is not doing it for you…).

Important

The MISRA organization allows checkers to run an analysis and publish, should there be any, the violation ID but not the text accompanying the violation (here more details).
If you want to access this text, you need to purchase a copy of MISRA C:2012 for a small fee (15 £) - a document that is very interesting as it gives the rationale behind the different rules. An alternative is to use a proprietary tool (see later “MISRA - Going beyond”), whose MISRA supported checks may help already with the meaning of the findings.

Update 03/24: the mapping file can be found under https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/tools/-/blob/main/misra_c_2023__headlines_for_cppcheck.txt?ref_type=heads

Installation: Once you find a text mapping file, the section “AddOns -> Running Addons” of cppcheck manual explains how to add them.
Once done, you simply type cppcheck --addon=misra.json *.c

Tip

Alternatively, one may use the dedicated .devcontainer made available to you under https://github.com/EmbReal/student-tools

Note

There is an online cppcheck if an acquintance of yours is interested in trying it out: cppcheck - Demo.

For our course, though, we need to install it as a) the demo has limitations and b) ARM Keil requires a locally installed tool for its integration.

Run a first MISRA analysis

For our first analysis - to ensure all works - we will make use of the MISRA repository that can be cloned with https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite.git.

Once done, run the cppcheck tool and inspect the results. You can run the tool by entering:

  // use cppcheck.exe under Windows
  cppcheck --addon=misra *.c         // all files 
  cppcheck --addon=misra R_02_03.c   // specific file

Important:
The example files of Example-Suite.git contain a number of C language statements.

These are:

1. support statements
2. “Compliant” examples
3. “Non-compliant” examples

A “Compliant” example is a construct that should not generate a warning message.
A “Non-compliant” example is a construct that should generate a warning message. The exact location of this warning is permitted to be tool dependent.

It is not always possible to avoid “cross-talk” between rules, so some files will violate multiple rules. In particular, no attempt has been made to provide definitions for all external functions or objects (R.8.6), nor is there always more than one use of such identifiers (R.8.7).

Question 1

Analyze file D_04_07.c (of Example-Suite.git) with cppcheck and state what the rationale for Non-compliancy is. Is this a rule or a directive?

Solution

1. It is a directive (Dir 4.7)
2. Ignoring return values may result in undefined behaviour as the exception is not handled properly Note: checking parameters is deemed more robust (Dir 4.11)

Question 2

The file D_04_12.c (of Example-Suite.git) is an example of Directive 4.12 that states Dynamic memory shall not be used. What is the rationale of this directive?

Solution

1. Memory allocation/deallocation can lead to undefined behaviour.
   1. Insufficient memory available
   2. Variance in program execution due to memory de/allocation
2. Rule 21.3 explicitly forbids the use of stdlib.h memory de/allocation

Question 3

The file R_15_05.c (of Example-Suite.git) is an an example of Rule 15.5 that states A function shall have a single exit point at the end. What is the rationale of this directive?

Solution

1. May result in unintentionally omitting the termination code
2. May be difficult to infer the behaviour of the function with many interspersed exit points
3. Mandatory by standards ISO 26262 and IEC61508

If not done so already, go and do:

Exercise: MISRA findings (I and II)

Plug cppcheck into ARM Keil

Once cppcheck is installed on your machine, it can be added to ARM Keil and be run from there. In order to do so, you need to:

• open the Customize Tools Menu under Tools

• create a new entry, for instance MISRA cppcheck, with the parameters below:

  • Command: “C:\Program Files\Cppcheck\cppcheck.exe” (the location you installed cppcheck into)
  • Initial Folder: “YOUR_PROJECT_LOCATION\RTE\Device\STM32L475VGTx\STCubeGenerated\Core\src” (Obviously you need to specify the location you have stored the project into)
  • Arguments: “main.c” –addon=misra

Note

In the example above, an Initial folder is chosen in order to limit the analysis to file created by the developer. This is obviously not the only option.

Run the analysis on your code

First thing first: make sure your code - as is, no MISRA analysis yet - is stored in a git repository hosted on github.
Tag this version with 1.0 (after all it is indeed a first version 😉).

Afterwards, on a dedicated branch, run the analysis on your code to find eventual issues in your application. Go about fixing them one at a time and commit the fixes on a dedicated branch (named misra_fixes).

Important: only run the analysis on main.c contained in YOUR_PROJECT_LOCATION\RTE\Device\STM32L475VGTx\STCubeGenerated\Core\src, not those coming from 3^rd party. Obviously, the Application folder is to be included as well in your analysis.

Note 1

With the option --inline-suppr one can exclude a rule to be applied for as long as the code holds the related comment (e.g. // cppcheck-suppress misra-c2012-2.7).

However, this really needs to be a) justified and b) tracked. Oftentimes, cppcheck is run twice: with and without --inline-suppr. So, a lie never lives to be old as the saying goes…

Note 2

It is important to have a good development hygiene - developing features on branches is one of them. As multiple people work on the same repository, this grants:

• Easier collaboration: each feature has its own dedicated branch, allowing multiple team members to work independently on different features at the same time.
• Fewer merge conflicts: short-lived feature branches contain code for a specific feature, reducing the chance of merge conflicts when merging into the main codebase.
• Faster deployments: features can be deployed as they are completed, since each feature is developed and tested in its own dedicated branch before being merged into the main codebase.
• Better visibility: allows team members to easily see what features are being developed and the progress of each feature, improving project planning and resource allocation.

Explanation of Git Feature Branch Workflow

MISRA - Going beyond

Although we will use cppcheck for analyzing C code throughout the course, a different tool that we will use for producing SW metrics - Scitool Understand - is also capable of analyzing the code according to different guidelines. As a student, you are elegible for a free license by subscribing to their student program.

Go ahead and register today!

Note

Presently, with Scitool Understand the MISRA C:2012 analysis seems buggy. So, although the explanations of the MISRA related issues (that is , the text accompanying the violation) are present in the tool, the analysis will show inconsistent errors.