Skip to main content
TESSY + SEGGER J-Link: Debug-Assisted On-Target Unit Testing for Embedded Safety Projects, featured image

TESSY + SEGGER J-Link: Debug-Assisted On-Target Unit Testing for Embedded Safety Projects

GSAS Engineering · · 5 min read

Host-based unit testing is convenient. You compile the embedded C code with GCC on your development PC, run the tests, and get coverage numbers in seconds. But safety assessors ask a pointed question: does your coverage data reflect the code running on the actual target, or does it reflect a host-compiled version with different compiler semantics, different integer sizes, and different optimization behaviour?

For ISO 26262 ASIL C/D and DO-178C DAL A projects, on-target testing provides the strongest evidence. Razorcat TESSY integrates with SEGGER J-Link debug probes to execute unit tests directly on the microcontroller and collect coverage data through the debug channel, giving teams MC/DC coverage evidence from the production hardware.

Why On-Target Matters

The gap between host-based and target-based testing is not theoretical. Real differences include:

Compiler behaviour. Arm Compiler 6 and GCC generate different code for the same C source. Structure packing, bit-field layout, integer promotion rules, and volatile access semantics can differ. A function that passes all tests under GCC may behave differently when compiled with AC6 for Cortex-M4.

Memory layout. On the target, stack, heap, and static memory regions have defined sizes and addresses. Functions that work on a PC with gigabytes of address space may overflow a 4 KB stack on a Cortex-M0+. On-target testing catches these issues.

Peripheral dependencies. While most unit tests stub out peripheral access, some functions interact with DMA controllers, timers, or ADCs that cannot be meaningfully simulated on the host. On-target testing exercises the real peripheral interface.

Optimization effects. At -O2 or -Os optimization, the compiler may reorder operations, inline functions, or eliminate dead code. Coverage measured on optimized target code reflects what actually executes in production.

How the Integration Works

TESSY’s integration with SEGGER J-Link follows this sequence:

1. Test compilation. TESSY compiles the unit under test, test driver, and stubs using the project’s cross-compiler (Arm Compiler 6, IAR, TASKING, HighTec, or GCC cross-compiler). The output is an ELF binary targeting the specific microcontroller.

2. Download to target. TESSY invokes J-Link to flash the test binary to the microcontroller’s internal flash or RAM. J-Link supports SWD and JTAG interfaces, covering virtually every Arm Cortex-M, Cortex-R, and Cortex-A device, plus Infineon AURIX TriCore, Renesas RH850, and other architectures.

3. Test execution. TESSY starts execution on the target through J-Link. The test harness runs, setting up inputs, calling the function under test, capturing outputs, and recording coverage instrumentation data.

4. Data readback. After each test case completes, TESSY reads the results and coverage data from the target’s memory through the J-Link debug channel. Coverage instrumentation counters stored in RAM are transferred back to the host for analysis.

5. Coverage analysis. TESSY processes the raw coverage data into statement, branch, decision, MC/DC, and MCC reports, the same reports as host-based execution, but with data sourced from real hardware execution.

The entire sequence, compile, download, execute, readback, happens automatically per test case. Engineers interact with TESSY’s graphical interface to view results; the J-Link communication is transparent.

J-Run for Automated Batch Execution

SEGGER’s J-Run utility enables headless test execution without a debug session. TESSY can use J-Run to execute test binaries on the target in batch mode, which is essential for CI/CD pipeline integration.

In a Jenkins or GitLab CI pipeline:

  1. CI runner triggers TESSY batch execution
  2. TESSY compiles test suites with the project’s cross-compiler
  3. J-Run downloads each test binary to the target board connected to the CI runner
  4. Tests execute on hardware and results are collected
  5. Coverage reports are generated and compared against quality gates

This enables automated on-target regression testing, every commit triggers test execution on real hardware, with coverage evidence that satisfies the most stringent safety assessors.

Supported Targets

The TESSY + J-Link combination supports the microcontroller families most common in Indian embedded development:

  • Arm Cortex-M0/M0+/M3/M4/M7/M33: automotive body controllers, industrial sensors, medical devices
  • Arm Cortex-R4/R5: automotive ECUs requiring hardware lockstep (Hercules TMS570)
  • Infineon AURIX TC2xx/TC3xx: safety-critical automotive powertrain and chassis ECUs
  • Renesas RH850: automotive gateway and communication ECUs
  • STMicroelectronics STM32: widespread across industrial and consumer applications

For teams in Pune working on AURIX-based powertrain ECUs, in Bengaluru developing Cortex-M7 ADAS interfaces, or in Hyderabad building industrial safety controllers, the TESSY + J-Link workflow provides on-target coverage evidence without changing the development toolchain.

Host vs Target: When to Use Each

On-target testing through J-Link is essential for safety certification evidence, but host-based testing has its place:

  • During development: Use host-based execution for rapid iteration, tests run in milliseconds instead of seconds
  • During regression testing: Use on-target execution in CI pipelines for certification-grade evidence
  • For safety certification: Use on-target results in the safety case, assessors accept this as evidence that coverage was achieved on the production target

TESSY supports both modes with the same test project. Engineers switch between host and target execution without modifying test cases.

Why Buy from GSAS

GSAS Micro Systems is an authorized partner for both Razorcat (TESSY) and SEGGER (J-Link). This means a single source for the complete on-target unit testing workflow, debug probe, testing tool, licensing, training, and support, with INR invoicing. Our engineers in Bengaluru, Hyderabad, Chennai, Pune, Mumbai, and Delhi NCR configure the TESSY + J-Link integration on your target hardware, set up CI/CD on-target regression pipelines, and provide ongoing technical support for safety certification projects.

Request a TESSY + J-Link evaluation →

Interested in Razorcat tools?

Talk to our application engineers for personalized tool recommendations.

Stay in the Loop

Get monthly compliance updates, product insights, and engineering best practices delivered to your inbox.

Related Articles

Master and slave roles on a 100BASE-T1 link: the master PHY times its transmitter from a local clock, the slave recovers the clock from the received signal, with the both-master and both-slave misconfigurations that leave the link down, from GSAS Micro Systems India
Automotive Ethernet Automotive & Mobility

100BASE-T1 Link Won't Come Up: A Vendor-Neutral Checklist

A 100BASE-T1 link that will not come up is almost never a mystery, but the answers on the web are written per silicon vendor and do not transfer. This is the ordered bring-up checklist that holds regardless of which PHY, switch or SoC you have: physical layer first, then the PHY over MDIO, then the master and slave pairing, then the causes of a link that comes up and drops. The standards and tooling claims trace to IEEE 802.3 task force records, the Linux ethtool and kernel documentation or published test material. Written by the GSAS Micro Systems engineering team in India.

29 Aug 2026 · 14 min read
Side by side comparison of a 10BASE-T1S multidrop mixing segment, one balanced pair with four nodes on short stubs and a termination at each end, against a point to point star of four separate links into switch ports, from GSAS Micro Systems India
Automotive Ethernet Automotive & Mobility

10BASE-T1S and PLCA: Multidrop Ethernet Explained

10BASE-T1S is the one member of the T1 single-pair Ethernet family that keeps a shared medium, and PLCA is the reconciliation sublayer that stops the nodes on it from colliding. This article covers what IEEE 802.3cg standardises, how the beacon and transmit opportunities schedule a cycle, the node count and segment length figures the OPEN Alliance interoperability test suite works to, and the failure modes that put a segment quietly back into contention while every link still looks up. Written by the GSAS Micro Systems engineering team in India for teams bringing up multidrop segments on the bench.

29 Aug 2026 · 12 min read
Horizontal stacked bar showing where an ADAS test vehicle's bandwidth budget is spent, split into cameras, lidar, radar and bus traffic, with the logger uplink limit drawn as a vertical rule crossing the bar, from GSAS Micro Systems India
Automotive Ethernet Automotive & Mobility

ADAS Sensor Data Logging: Bandwidth Budgets That Add Up

Every page that tells you an ADAS test vehicle produces terabytes a day states the headline and skips the arithmetic, so you cannot redo it for your own sensor set. This article publishes the arithmetic instead: one formula, every table row derived on the page, a worked eight-hour drive that chains those rows into a sustained write rate, a media count and an offload window, and the five places bandwidth budgets go wrong. Written by the GSAS Micro Systems engineering team in India.

29 Aug 2026 · 15 min read