Embedded code coverage for IAR, Keil, TI, MPLAB and every cross-compiler
RKTracer captures embedded code coverage through MC/DC on the actual device, bare-metal, RTOS or full SoC, with or without a file system. IDE integrations for IAR Embedded Workbench, Keil uVision MDK, TI Code Composer Studio and Microchip MPLAB X, plus every other cross-compiler. No manual source changes.
IAR · Keil · TI CCS · Microchip MPLAB · Arm GNU · with or without a file system
# Prefix your existing cross-compiler build $ rktracer make all auto-detecting compiler: arm-none-eabi-gcc 12.2 instrumenting 142 source files… ✓ build complete, no source modified ✓ runtime linked for target image # Run tests on the device, then report $ rkresults --report html ✓ statement 100% · decision 100% · MC/DC 98.7%
Host coverage numbers lie for embedded code
Embedded teams often measure code coverage on a host build because it is easy: compile the firmware sources with the desktop compiler, run the unit tests on a laptop, and read off a green number. The problem is that the green number describes code that you do not ship. Your firmware is built by a cross-compiler, whether that is IAR, the Arm Compiler in Keil, the TI compiler in Code Composer Studio, the Microchip compiler in MPLAB X or Arm GNU, with target-specific optimization, intrinsics, register and memory layout, and conditional code guarded by target macros. The host build uses a different compiler, different flags and different inlining, so it exercises different branches and different paths.
The result is a coverage report that can look complete while real target paths stay untested. A decision that the host compiler folds into a constant may be a live branch on the device. An interrupt handler, a DMA completion path or a hardware fault routine may never run off-target at all. Endianness, integer width, alignment and stack limits all differ between the host and the device, and each difference can flip which branch a test takes. When the standard that governs your project asks for evidence that every condition was independently shown to affect the outcome, host numbers are not that evidence. On-target code coverage is. RKTracer measures the same binary you flash, so the coverage matches the firmware that leaves the building.
This matters most for the parts of a system that are hardest to reach: low-level drivers, fault handlers, watchdog and brown-out logic, and the conditional paths guarded by build-time configuration. Those are exactly the paths a host build is least likely to compile the same way, and exactly the ones a safety case cares about. Measuring embedded code coverage on the device closes that gap and lets you treat the number as real evidence rather than a comfortable approximation, on bare-metal firmware, an RTOS or a full SoC running Linux.
We dig into the mechanics, with concrete examples of how the same source yields different coverage under different compilers, in why cross-compiler coverage and host numbers diverge.
Measure coverage where the firmware actually runs
RKTracer instruments your existing cross-compiler or IDE build at compile time and adds its runtime automatically. You flash the instrumented image, run your test suite on the device, emulator or simulator exactly as you do today, and the coverage is captured live on the hardware.
Because the instrumentation rides on the compiler that builds your firmware, the coverage reflects the optimized image, not a host approximation. The same model spans your whole bring-up flow: validate on a simulator early, move to an emulator, then confirm on silicon, all with one coverage definition and one report format. There is no manual source rewrite, no environment variable juggling and no separate coverage build of the codebase to keep in sync.
Coverage is collected per test and per run, so you can attribute exactly which test exercised which decision, and merge results from a simulator pass, a hardware-in-the-loop pass and an on-bench pass into a single picture. That makes it practical to build coverage incrementally as the hardware becomes available, rather than waiting for a final board to start counting.
- Host, simulator, emulator and physical target, one coverage model
- Instruments the cross-compiler, so numbers match the shipped binary
- No manual source edits and no toolchain swap
Get coverage off the device, even bare-metal
Bare-metal and constrained RTOS targets cannot just write a coverage file. RKTracer brings the data off the device through the debug session and probe connection you already use, such as SWO, JTAG, SWD or UART, or buffers it in RAM for the host to collect.
Debug transport
When the target is connected to the host, coverage is saved off the device through the IDE debug session over your existing probe link, such as SWO, JTAG, SWD or UART. No SD card, no network stack and no extra peripheral required.
RAM buffer
RKTracer records coverage into a memory buffer on the target. On IAR, an rkdump() breakpoint action writes RK-MEM.raw; on TI, you run rkdump from the Scripting Console; the host reads it back over the probe.
File system when present
On targets with a file system, a Linux board or a rich RTOS, RKTracer writes the raw coverage file directly to the working folder, then merges it with runs from other targets.
Same coverage model whether the device has gigabytes of storage or none at all. If a target cannot be connected to the host, contact support for a customized script to transfer the coverage data. See the IAR Embedded Workbench and Keil uVision MDK-Arm guides for capture setup.
Every embedded toolchain and target, instrumented
RKTracer plugs into the IDE you already use to build firmware. For IAR, Keil, TI and Microchip it adds an in-IDE toggle, instruments on the normal rebuild, and produces HTML reports. For Arm GNU and other cross-compilers, you prefix the build. No manual editing of application source files in any case.
IAR Embedded Workbench
With the IDE closed, run rktracer -iar -integrate. This adds RKTracer ON, RKTracer OFF and RKTracer Reports to the IAR Tools menu. With RKTracer ON, the application is instrumented automatically during the normal IAR rebuild, no manual source-file changes. When the target is connected, coverage is saved automatically when the debug session ends, or on demand via an rkdump() breakpoint action that writes RK-MEM.raw. RKTracer Reports converts it to rk-coverage.txt, maps it to the instrumentation JSON and opens HTML via index.html.
Targets: Arm Cortex-M and Cortex-R/A, RISC-V, Renesas RX, RL78 and RH850, TI MSP430, 8051 and AVR.
IAR Embedded Workbench guideKeil MDK & uVision
With the IDE closed, run rktracer -keil -integrate to add RKTracer ON, RKTracer OFF and RKTracer Reports to the uVision Tools menu. Reopen uVision, select Tools > RKTracer ON (granting read/write permission on first use), then rebuild to instrument. Run your tests on the embedded target; coverage is saved automatically when you terminate the debug process. Tools > RKTracer Report converts RK_MEM.raw to rk-coverage.txt, maps it to the instrumentation JSON and produces the HTML report.
Targets: Arm Cortex-M family and Cortex-M-class devices, plus Arm Cortex-R cores.
Keil uVision MDK-Arm guideTI Code Composer Studio
With the IDE closed, run rktracer -ds -integrate to register RKTracer. Reopen CCStudio and make External Tools visible via Windows > Perspective > Customize Perspective, so RKTracer appears under Run > External Tools (ON / OFF / Reports). Enable RKTracer ON, then clean-and-build to instrument. Run the test cases on the target in debug mode, open the Scripting Console from the View menu and run rkdump to save coverage to the project folder. RKTracer Reports maps it against the instrumentation JSON and produces HTML.
Targets: MSP430, C2000 and TMS320 real-time MCUs and DSPs, Sitara (Cortex-A), Hercules / TMS570 (Cortex-R) and SimpleLink CC wireless MCUs.
Code Composer Studio guideMicrochip MPLAB X
RKTracer installs as an MPLAB X plugin, com-rkvalidate-nb.nbm, through Tools > Plugins Download > MPLAB X Plugin Manager (Downloaded > Add Plugin), then restart the IDE. RKTracer options appear in the Tools menu. Select Tools > RKTracer ON and rebuild to instrument. Run the test on the target in debug mode; when the debug process ends, RKTracer saves RK_MEM.raw in the working folder. Tools > RKTracer Report converts it to rk-coverage.txt, maps it to the instrumentation JSON and produces HTML (index.html).
Targets: 8-bit PIC and AVR, 16-bit PIC24 and dsPIC, and 32-bit PIC32 (MIPS) and SAM (Cortex-M / Cortex-A) MCUs and MPUs.
Microchip MPLAB guideArm GNU & GCC cross-compilers
For command-line cross-compiler builds, prefix your existing build with the rktracer keyword, for example rktracer make all. RKTracer auto-detects the cross-compiler, such as arm-none-eabi-gcc, instruments at compile time against your real flags and links its runtime into the target image, without modifying source files. It fits CMake and Makefile projects the same way, then captures coverage on the device through the debug session.
Targets: Arm Cortex-M, Cortex-R and Cortex-A, RISC-V and other GCC-supported cores. See the CMake and Makefile guides.
Makefile application guideAnd more cross-compilers
Other proprietary embedded toolchains, including Green Hills and TASKING, are handled as generic cross-compilers: prefix your existing build and RKTracer instruments at compile time against your real flags, with no manual source edits. Because detection is automatic, a mixed build that uses one compiler for the bootloader and another for the application is handled without configuration. Tell us your toolchain and target and we will map RKTracer to your stack.
Targets: the MCU, MPU, DSP and SoC families those compilers build for, bare-metal, RTOS or full Linux.
Map RKTracer to your stack# Arm GNU and other cross-compilers: prefix the build $ rktracer make all detecting compiler: arm-none-eabi-gcc 12.2 instrumenting 142 source files… ✓ build complete, no source modified ✓ runtime linked for target image # IAR / Keil / TI / MPLAB: one-time IDE integration, then toggle $ rktracer -iar -integrate # adds Tools > RKTracer ON/OFF/Reports $ rktracer -keil -integrate $ rktracer -ds -integrate # TI Code Composer Studio
Scope coverage with an rktracer.config file using ignore, instrument, never, function-ignore and function-instrument directives. No application source files are edited.
Every metric, from statement through MC/DC, in one run
The hardest structural metric in software assurance, measured natively on the device alongside every other metric.
Function, File & Line
Know exactly which functions, files and lines your on-target tests execute.
Statement & Branch/Decision
Confirm every statement runs and both outcomes of each decision are tested.
Condition & MC/DC
The strongest structural metrics, measured for C and C++ on the real target.
Multi-Condition & Delta
Go beyond MC/DC, and focus coverage on exactly what changed each build.
| Coverage metric | Typically referenced at |
|---|---|
| Statement | DO-178C Level C · ISO 26262 ASIL A |
| Decision / Branch | DO-178C Level B · ASIL B and C |
| MC/DC | DO-178C Level A · ASIL D |
| Multi-Condition | Deep verification · IEC 61508 SIL 4 |
MC/DC and multi-condition are measured for C and C++, which is most embedded firmware. See all features and metrics.
From firmware to coverage evidence, gated in CI
Embedded coverage that lives in your pipeline, not on one engineer's laptop.
Instrument the build
Prefix your existing build, or toggle RKTracer ON in IAR, Keil, CCStudio or MPLAB X. No toolchain swap and no manual source rewrite.
Flash & run on target
Run your test suite on the device, emulator or simulator in debug mode, exactly as you do today.
Capture coverage
Data leaves the device through the debug session into a raw coverage file, even with no file system on board.
Publish the report
Emit HTML and XML, merge runs across targets, gate in CI and publish to SonarQube.
RKTracer publishes HTML and XML reports, integrates with Jenkins, Azure DevOps and GitLab CI, and publishes coverage to SonarQube. Reports from multiple runs and multiple targets can be merged. As neutral context, these structural metrics are the ones safety standards such as DO-178C, ISO 26262, IEC 61508, EN 50128 and IEC 62304 reference. RKValidate is an ISO 9001 quality-management vendor. RKTracer measures the coverage these standards reference; it does not itself carry a functional-safety certification. Wiring it into a project? Follow the CMake application guide, or browse all toolchain guides.
Coverage finds the gaps. Two ways to close them.
RKTracer pinpoints the uncovered lines, decisions and MC/DC conditions in your firmware. It measures coverage; it does not generate tests itself. Turning those gaps into tests is your choice, and both options below are part of the RKTracer tool.
Embedded code is mostly C and C++, so both options apply directly. RKTracerGen is C and C++ only.
See how RKTracer fits your toolchainRKMCP · AI-assisted
An MCP server that serves the uncovered lines, decisions and MC/DC conditions to your AI agent. The agent writes unit and functional tests plus the build, then runs and re-checks until the gaps close.
RKTracerGen · offline, C and C++ only
A deterministic, fully offline unit-test generator for C and C++ only. Boundary-Value Analysis, managed stubs, builds and runs locally. No AI, no tokens, no network.
Embedded code coverage questions, answered
rktracer -iar -integrate, which adds RKTracer ON, RKTracer OFF and RKTracer Reports to the IAR Tools menu. With RKTracer ON, the application is instrumented automatically during the normal IAR rebuild. When the target is connected, coverage is saved automatically when the debug session ends, or on demand via an rkdump() breakpoint action that writes RK-MEM.raw, which RKTracer Reports then converts into HTML.rktracer -ds -integrate, exposing RKTracer under Run > External Tools; instrumentation happens on a clean-and-build, and you run rkdump from the Scripting Console in debug mode to save coverage. For Microchip, RKTracer installs as an MPLAB X plugin (com-rkvalidate-nb.nbm) through the Plugin Manager, adds Tools-menu options, and writes RK_MEM.raw when the debug process ends. This covers TI families such as MSP430, C2000, Sitara and Hercules, and Microchip PIC, AVR, dsPIC, PIC32 and SAM devices.Prove your firmware on the hardware it ships on
Download the free 30-day trial and capture embedded code coverage on your IAR, Keil, TI or MPLAB target this week, or book a 30-minute demo with an engineer.