Use cases

There are two complementary approaches.

First, architect firmware with a hardware abstraction layer (HAL) so business logic can be tested on the host machine using a standard C test framework like Unity or CppUTest — no cross-compiler or board needed for logic tests.

Second, use an instruction-set simulator likeIAR C-SPY for tests that need the actual CPU behaviour: cycle-accurate simulators let you run cross-compiled firmware on CI runners without physical boards, catching real-time and memory faults.

A mature CI pipeline combines both: host-native unit tests for fast feedback on every commit, and simulator-based integration tests for deeper validation.
Hardware-in-the-loop tests that require real boards run nightly or on release branches, with hardware access scheduled.

Long compile times in embedded projects trace back to monolithic build configurations, redundant full rebuilds triggered by small changes, and inefficient use of multi-core machines.

The fastest wins are:

Take advantage of parallel compilation (some compilers, including IAR support this), split firmware into independently buildable modules so only changed components recompile, and containerize the toolchain so CI runners don't reinstall tools on every run.

Compiler quality also matters — optimizing compilers that produce smaller code often also lead to faster link times.

Teams using CI-integrated toolchains on Linux report up to 50% reduction in build time compared to Windows-only manual builds, primarily because Linux-native toolchains and containerized runners process object files more efficiently.

Want to see how this fits your workflow? Connect with an IAR expert for a custom evaluation. 

 This is the most common embedded CI failure and almost always means the build depends on something installed locally that isn't in the CI environment: a specific compiler version, a vendor SDK path, a host OS library, or an implicit tool in the system PATH.

The permanent fix is a hermetic build: package every tool — compiler, linker, assembler, SDK — into a Docker container image that is version-pinned and checked into version control.

Every developer and every CI runner uses that exact image. Vendor-supplied Linux toolchain installers that work headlessly make this straightforward to containerize. Once the image is the source of truth, 'works on my machine' failures disappear entirely because there is only one machine. 

The key is integrating MISRA analysis directly into your CI pipeline as a non-blocking quality gate at first, then progressively tightening rules.

Set up your static analyser to run on every pull request or merge request and report violations as CI annotations inline with the diff, developers see exactly which line broke which rule without leaving their workflow.

Start with a MISRA-C:2012 required-rules-only profile to reduce noise. Treat new violations as build failures and existing ones as a tracked backlog to fix incrementally. This approach enforces coding standards continuously without a separate review step.

Toolchains that run the same analyzer binary in both the IDE and CI eliminate the 'passes locally, fails in CI' problem that undermines developer trust in the gate.

The practical answer is a single development platform, like the IAR Platform, that supports both architectures under one license and one build tool interface. When Arm and RISC-V projects share the same compiler vendor and IDE, CI pipeline scripts are nearly identical — only the target flag changes.

This means the same Docker image with the toolchains for Arm and RISC-V, the same static analysis ruleset, and the same debugging workflow. As RISC-V adoption accelerates in industrial and IoT applications (driven by cost and vendor independence), multi-architecture support is increasingly a hard requirement rather than a nice-to-have.

Teams that locked into single-architecture tools earlier are now paying migration costs; teams on multi-architecture platforms simply add a target configuration. 

The biggest time sinks in embedded debugging are: waiting for a full build-flash-boot cycle to test one change, missing root cause context when a fault occurs, and finding bugs late that were introduced days earlier.

Address each separately.

• Reduce the iteration loop by running logic tests on-host or in a simulator before flashing.

• Improve fault context with a debugger that captures call stacks, register state, and memory at the crash point rather than just reporting a fault address.

• Shift bug discovery earlier by running runtime analysis (stack overflow detection, memory access checking) as part of CI rather than only during manual sessions.

Teams combining simulator-based CI tests with advanced on-target debugging like IAR C-SPY report debugging time reductions of up to 80% compared to reactive manual workflows.

The ROI case for commercial toolchains rests on four factors that open-source tools don't cover.

First, in-house validation of an open-source toolchain for safety standards (IEC 61508, ISO 26262) can consume up to 12 months of engineering time and must be repeated at every major version update — a cost rarely captured in tool budget comparisons.

Second, compiler optimization quality: commercial compilers typically produce 20–28% smaller code, which directly reduces BOM cost by enabling smaller flash or cheaper silicon.

Third, support response time: unblocking a development team stuck on a toolchain bug incurs a quantifiable daily cost.

Fourth, subscription licensing converts large capital expenditure into a predictable operating cost, which is easier to approve and easier to scale. Present the comparison as a 12-month total engineering cost, not a license fee vs. zero.

Read more in these ebooks:

TCO paper

12 Fundamentals of Embedded Software Development

Missed certification deadlines in embedded projects almost always trace back to the same three causes:

1. compliance evidence collected retroactively rather than continuously,

2. tool validation left until late in the project, and

3. quality issues discovered at system integration.

Each has a process fix.

Replace retroactive evidence with continuous generation: configure CI to produce MISRA violation reports, static analysis summaries, and build traceability automatically on every build.

Use a pre-certified toolchain to eliminate in-house tool validation entirely — this alone can recover 6–12 months.

Run quality gates at commit time to keep defect density entering integration low.

Project managers who instrument these three metrics (evidence completeness, tool validation status, escaped defect rate) get early warning of certification risk rather than discovering it at the audit. 

Start with four stages:

1. Build — cross-compile using a containerized toolchain that runs headlessly on Linux

2. Static analysis — run MISRA or CERT-C checks and fail the build on new violations

3. Unit tests — run host-native tests for logic and simulator-based tests for hardware-dependent code

4. Artifact packaging — produce a signed firmware binary with an accompanying build manifest. Use GitHub Actions or GitLab CI to trigger this on every push.

The critical enabler is a command-line build tool that works without a GUI license — commercial toolchains now offer Linux-native CLI builds with cloud or container licensing, so you don't need a license server on every runner.

Start simple and add hardware-in-the-loop and OTA staging gates once the basic pipeline is trusted. The tutorials at https://github.com/iarsystems provide guidance on how to get started.  

Static analysis examines source code without executing it — it catches undefined behaviour, MISRA violations, null pointer dereferences, and data flow errors at build time, before any binary runs.

It scales well in CI because it needs no hardware. Runtime analysis (dynamic analysis) instruments or monitors the executing firmware to detect errors that only appear at runtime: stack overflows, heap corruption, timing violations, and race conditions in RTOSes.

You need both because they catch different classes of defect. Static analysis is the first line of defense and runs on every commit. Runtime analysis runs on the simulator or hardware-in-the-loop rig to catch the defects that only manifest under real execution conditions.

In safety-critical projects under IEC 61508 or ISO 26262, both are required at their respective development phases. 

Read more  about IAR Static Analysis and Functional Safety

Measure four baseline metrics before the transition:

• average time from code commit to defect discovery,

• number of integration failures per sprint,

• hours spent on compliance evidence collection per release, and

• onboarding time for new engineers.

CI/CD typically moves defect discovery from integration (expensive) to commit time (cheap), cutting rework cost by 40–50%.

Automated compliance evidence eliminates manual documentation cycles that typically take 2–5 days per release in certified projects.

Build automation removes the manual build-flash-test loop, with teams reporting 50% faster build-test cycles.

Onboarding time drops when the toolchain is containerized — engineers stop troubleshooting local setups and start writing code from day one.

These metrics convert directly to engineer-hours saved, which translate to schedule compression or headcount efficiency. 

Read more in this TCO paper