Generate Code coverage report for EFR32

[Markg]

Hello,

I would like to generate code coverage reports of our unit tests ran on the efr32. I have tried adding the flags to the compiler: https://medium.com/@naveen.maltesh/generating-code-coverage-report-using-gnu-gcov-lcov-ee54a4de3f11

But that give me an:

Severity Code Description Project File Line Suppression State Suppression State
Error undefined reference to `__gcov_init' UnitTest_CICD_test
Error undefined reference to `__gcov_exit' UnitTest_CICD_test

Could you guys help?

Kind regards,

Mark

• This topic was modified 4 years, 5 months ago by support. Reason: formatting

[support]

Hi,

Sorry, code coverage is not supported for embedded projects yet. Obtaining the coverage for GCC-based projects requires a mechanism for transferring the coverage data from the target to the host, and there are a few caveats that make this task non-trivial. We are internally experimenting with it and will very likely support it in one of the next preview builds for v5.5. However, as of today, the only way to obtain code coverage for an embedded project would be to use Segger J-Trace (see this tutorial).

[Markg]

Ok thanks, good to know! Do you have an ata for that release?

[support]

Hi,

Currently we are still researching the ways to reduce the RAM use by the profiling counters. We should be able to get an ETA for this feature around the middle of the next week.

[support]

Hi,

Just wanted to share an update that we have added support for embedded code coverage (including Live Coverage) to the following build: VisualGDB-5.5.2.3390.msi

You can enable it via VisualGDB Project Properties -> Code Coverage.

For most accurate results, please consider upgrading to the latest GCC 9.2.1-based ARM toolchain (that is a repackaged version of the official GNUARM toolchain).

[Markg]

Thank you!

[Markg]

Hi All,

I did some testing, but as soon as I enable the code coverage io run in to a issue. The compiler complains that the sram section is to small.  This is due to the “-<strong class=”hu iv”>fprofile-arcs” which is automatically set because of the “–coverage flag”. Is this a known issue? (chip uses: EFR32MG1P232F256GM48)

Kind regards,

Mark

• This reply was modified 4 years, 4 months ago by Markg.

[Markg]

Hi All,

I did some testing, but as soon as I enable the code coverage I run in to a issue. The compiler complains that the sram section is to small.  This is due to the -profile-arcs which is automatically set because of the –coverage flag. Is this a known issue? (chip used: EFR32MG1P232F256GM48) Using the -fno-zero-initialized-in-bss does not solve the problem.

Kind regards,

Mark

• This reply was modified 4 years, 4 months ago by Markg.

[support]

Hi,

Most likely, you are not using the VisualGDB build engine to build the project. Just building the code with the –coverage flag will introduce immense memory overhead, so VisualGDB does some advanced pre-link patching to move most of the coverage logic to the PC side. Please try creating an MSBuild-based projects and check with it instead.

Alternatively, please try running the following command line after compiling the code, but before linking it:

VisualGDB.exe /decover <full path to the ELF file> <full paths to all .o files>

Then re-link your ELF file as usual. This will greatly reduce the memory overhead caused by the code coverage.

We are also preparing a tutorial showing the related settings and best practices. Feel free to follow us on Twitter to get notified once we publish it (or simply check our tutorials list next week).

[Markg]

Hi,

Is there an update on the tutorial?

[support]

Yes, we have published the tutorial here: https://visualgdb.com/tutorials/profiler/embedded/coverage/

[Author]

Posts