GNU Coverage (gcov) with NXP S32 Design Studio IDE

The open-source GNU tools provide a rich set of tools to help developing software. Some are clearly more for the high-end application development. But many of the tools are applicable for the more restricted embedded software development process as well. One is gcov, or the GNU Coverage Tool. Coverage is essential for the testing phase, as it tells you what part of code have been used and ‘covered’. This article describes how GNU coverage can be added the NXP S32 Design Studio IDE.

Outline

I wrote about using gcov in earlier articles, for example “Adding GNU Coverage Tools to Eclipse“. For a complete list of related articles see the ‘Links’ section at the end of this post. Because installation and usage depends a bit on the IDE used, this article shows how gcov can be added and used with the NXP S32 Design Studio IDE which is Eclipse based. I’m using the S32DS (Design Studio) v2.2 for ARM:

S32 Design Studio for ARM

For a detailed explanation about how gcov works, please see the links at the end of the article.

Installation

Unlike the NXP MCUXpresso IDE, this IDE does not come with the necessary GNU plugins installed. So I have to install the needed plugins first.

The S32DS v2.2 IDE is based on the older Eclipse Neon release. The corresponding update site

http://download.eclipse.org/releases/neon

can be turned on in the workspace preferences:

Eclipse Neon Plugins

Use that update site using the menu Help > Install new software and search for the gcov plugin:

Install the plugin and restart the IDE at the end of the installation.

The plugin is required to work with the coverage .gcno and .gcda files:

GNU coverage files

Instrumentation

To generate coverage information at runtine, the code needs to be instrumented by the compiler. For this the options

-fprofile-arcs -ftest-coverage

have to be added to the the source file compiler options. Do not instrument all the sources: just the source files for which coverage information shall be collected. The options can be added to the properties/settings of files or directories:

Compiler Option to instrument code for Coverage

Additionally, the Linker needs the following option added:

-fprofile-arcs
Linker Coverage Option

Coverage Helper

To initialize the coverage collection and to export the data, add the necessary helper (gcov_support.c and gcoc_support.h). You can find the code in the GitHubProject:

gcov helper and stub

Usage

To collect coverage information in the application: initialize the library with

gcov_init();

At the end, write the data to the host using semihosting with:

gcov_write();

Writing of the data to the host is done by default using semhosting, e..g with a J-Link debug probe connection which is full capable to do semihosting. The library includes a function

gcov_check();

which can be used to verify semihosting. Of course other means (RTT, UART, …) can be used to transfer the data to the host: for this, you can implement this in the stubs if you would like to use something different.

Keep in mind that instrumentation and file I/O requires stack and memory: start with a small working example, and increase stack and heap size as needed if more instrumented code is used.

Other than that: usage is the same as for example in the MCUXpresso IDE.

Summary

The NXP S32DS IDE can be used with the GNU coverage (gcov) tool too: it requires the installation of a plugins. After that, code can be instrumented and data collected from the target using semihosing. I have published an example project used in this article on GitHub.

Happy covering 🙂

LInks

8 thoughts on “GNU Coverage (gcov) with NXP S32 Design Studio IDE

  1. Hi Erich,

    I tried your example project, no issue here.
    Then I tried to add it to my own project and the gcov_check did not work.
    So I went back and tried to create a simple project from scratch:
    – Adding the coverage files to a blank application project without SDK –> OK
    – Adding the coverage files to a blank Processor Expert Project (with SDK 3.0.0) –> FAIL
    The issue I see is that the fopen call (used in gcov_check()) always fails (file remains NULL).
    I tried to adapt linker files (differences between Processor Expert and simple project), and tried to find resources online but did not find anything.
    I should say that I have some experience with the coverage, but I used to get the data through UART and I wanted to experiment with semihosting. I also successfully used the dynamic printf that you detailed in another post (so the semihosting seems to work). I use the PEMicro Multilink Universal probe.
    Have you by any chance tried the semihosting with a Processor Expert project? Do you plan to try it? Any idea why the file writing using semihosting would not work?

    Thank you,
    Jérémie

    Liked by 1 person

      • Actually it seems that it does work, because using your example project it does write both files on my hard drive, exactly as expected. It just doesn’t seem to work in a processor expert project with the same code.

        Liked by 1 person

        • does semihosting printf() work in your Processor Expert project?
          If yes, it could be a memory or stack problem, as file I/O needs lots of them. Have you tried increasing your heap and stack size? These are settings in the Processor Expert CPU settings.

          Like

        • Semihosting works for dynamic printf in my processor expert project. It does not seem there is a setting for heap and stack size in processor Expert on S32DS, but it can be changed directly in the linker file, I tried doubling the heap and stack from 0x400 to 0x800 each but no luck.

          Like

        • can you try normal printf if that works? dynamic printf can be different.
          As for the settings: you should have something like this:

          Like

        • In S32DS, there are not as many options (basic and advanced are the same) ( I would like to add a screenshot to show you but it doesn’t seem possible here). In fact there is no CPU configuration options available after you have chosen the CPU.

          Like

What do you think?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.