India’s safety-critical electronics programmes are moving from “we test until we’re confident” to “we produce documented evidence that the auditor accepts”. Indian automotive Tier-1s in Pune, Bengaluru, and Chennai are being asked by their OEM customers to deliver ISO 26262 ASIL B, ASIL C, and increasingly ASIL D components with statement, branch, and MC/DC coverage evidence. Indian medical device OEMs in Hyderabad, Bengaluru, and Mumbai are shipping Class B and Class C software under IEC 62304, with IEC 62366 usability evidence and complete unit test coverage as part of the CDSCO and FDA submissions. Indian aerospace and avionics teams working in the public-sector aerospace ecosystem, private space launch companies, and avionics subcontractors have started pursuing DO-178C DAL-B and DAL-C qualification on flight-critical firmware. All of these programmes share a common engineering problem: how do you prove, to an external auditor, that your firmware was actually executed the way your test report claims? That is the problem the J-Trace PRO instruction-trace probe from SEGGER Microcontroller GmbH was designed to solve, and this post walks through why J-Trace PRO is the pragmatic answer for Indian safety-critical teams versus both cheaper and more expensive alternatives. GSAS Micro Systems is the authorized SEGGER engineering partner for India, and J-Trace PRO with Indian delivery, INR invoicing, and on-site integration support is available through us.
What instruction trace actually is, and why it is not the same as a debugger
Most Indian embedded engineers are familiar with the J-Link debug probe: you connect it over SWD or JTAG, set breakpoints, step through code, and inspect variables. That is intrusive debug, the moment you set a breakpoint, the CPU halts, the system stops behaving in real time, and anything timing-dependent (interrupts, RTOS scheduler decisions, sensor frame rates, motor control loops) behaves differently than it does in the field.
Instruction trace is a fundamentally different mechanism. The Arm Cortex-M3, M4, M7, M33, and M55 cores include an Embedded Trace Macrocell (ETM): a piece of hardware inside the silicon that, whenever enabled, emits a highly compressed stream describing every branch the CPU took as it executed code. A trace probe like J-Trace PRO captures that stream off the ETM trace pins on the target and streams it continuously to the host over USB 3.0. The host software, SEGGER Ozone, in SEGGER’s tool stack, then reconstructs the full instruction-by-instruction execution history by correlating the compressed stream with the firmware ELF file.
Three things matter for safety-critical teams:
- It is non-intrusive. The CPU does not stop, does not slow down, and does not change its timing. What the trace captures is literally what the CPU executed on the real hardware at real speed.
- It is continuous. J-Trace PRO streams trace data as long as the target is running. A 10-second test run captures 10 seconds of instructions, every interrupt, every task switch, every conditional branch taken inside a loop.
- It is reconstructable off-target. Because the compressed trace references instructions in the firmware binary rather than carrying the instructions themselves, the same trace stream can be replayed later, weeks after the test run, by anyone who has the matching ELF file. That replay property is what makes trace evidence useful for audit.
Why Indian safety-critical programmes need trace: three concrete use cases
1. Code coverage evidence for ISO 26262, IEC 62304, and DO-178C
All three safety standards require some form of structural coverage evidence on the software items that implement safety requirements. The specific flavour varies:
- ISO 26262 Part 6 requires statement coverage at ASIL A and B, branch coverage at ASIL C, and MC/DC (Modified Condition/Decision Coverage) at ASIL D.
- IEC 62304 does not prescribe a specific coverage metric, but Class B and Class C software is required to have documented unit test coverage with objective evidence.
- DO-178C requires statement coverage at DAL-C, decision coverage at DAL-B, and MC/DC at DAL-A.
Indian Tier-1 teams have historically produced this evidence in one of two ways. The first is static analysis, which estimates coverage by inspecting the source code and the test harness. This is cheap but it is not auditable, a good auditor will point out that estimated coverage is not actual coverage. The second is instrumentation-based coverage, where the build injects counter updates on every basic block. This works but it has two big problems in safety-critical contexts: the instrumentation changes the binary (so the binary you tested is not the binary you ship), and the overhead is too high for real-time firmware.
Instruction trace gives you a third option. You run your existing test suite on the real, unmodified, shippable binary, with J-Trace PRO capturing the execution. Ozone reconstructs the coverage over the actual executed instructions, not over an instrumented build. The coverage report you hand to the auditor is computed over the same binary that goes into the ECU in production. That provenance is exactly what ISO 26262 Part 6 Clause 9 and DO-178C Section 6.4 ask for.
2. Crash forensics: the last N thousand instructions before a fault
Every Indian Tier-1 has seen this problem. The HiL rig in Pune runs 40 hours of regression testing overnight, and at 03:17 one of the test cases fails with an unexpected hard fault on the ECU. By the time the team investigates in the morning, the fault has cleared and the register state is gone. The test case is rerun, it passes. The fault is marked “intermittent” and the team moves on, knowing they have a latent bug and no way to find it.
Streaming instruction trace solves this category of problem. J-Trace PRO runs as a continuous capture alongside the HiL test. When the fault fires, Ozone has in memory the last several seconds (or minutes, depending on firmware density) of instruction history. The team can replay the trace and watch the CPU walk into the fault, which branch it took, which task was running, which interrupt preempted it, what value was in which register at each step. Instead of one bit of post-fault register state, they have a continuous reconstruction of the path into the fault.
For Indian automotive Tier-1s building ECUs that have to ship with a “no known intermittent faults” warranty to the OEM, the difference between “we think we know what happened” and “here is the instruction sequence that caused the fault” is the difference between a two-week investigation and a same-day fix.
3. Interrupt latency and hot-loop profiling at the instruction level
The third use case is performance profiling, not the statistical-sampling kind that SystemView and perf counters give you, but the instruction-accurate kind. For a motor control loop running on a Cortex-M7 at 400 MHz, SystemView can tell you that one task is taking longer than expected. Instruction trace can tell you which branch inside that task is eating the time, down to the cycle. For interrupt latency analysis on a medical ventilator running IEC 62304 Class C firmware, instruction trace can measure the exact number of cycles between the interrupt pin going high and the ISR’s first instruction executing, evidence you can put into your verification report as objective measurement, not estimation.
J-Trace PRO model selection: which variant for which architecture
SEGGER ships three J-Trace PRO variants, and picking the right one depends on your target silicon.
J-Trace PRO Cortex-M
J-Trace PRO Cortex-M is the variant most Indian Tier-1s actually buy, because most of the Cortex-M parts in Indian automotive, medical, and industrial firmware have 4-bit ETM trace pins available. It supports Cortex-M3, M4, M7, M23, M33, and M55 cores, captures 4-bit parallel ETM trace, and streams continuously to the host over USB 3.0 at line rate. It includes all the standard J-Link debug capability, you do not need a separate J-Link in addition.
Indian parts this matters for: STM32F4/F7/H7/U5 and STM32H5, NXP i.MX RT1010/1020/1050/1060/1170 (the application cores), Nordic nRF52840 and nRF5340 app core, Infineon PSoC 6, Microchip SAM E54/E70/V71, Renesas RA6M/RA8, TI Tiva and Hercules. All of these expose 4-bit ETM trace when the silicon package breaks out the trace pins (check the datasheet, some smaller packages drop the trace pins to save pin count).
J-Trace PRO Cortex-A/R
J-Trace PRO Cortex-A/R handles the bigger cores, Cortex-A7, A9, A15, A35, A53, A72, and the Cortex-R real-time cores. These parts typically expose 8-bit, 16-bit, or 32-bit parallel trace (PTM or ETMv4) rather than 4-bit, and the trace bandwidth is materially higher. J-Trace PRO Cortex-A/R streams this wider parallel trace over USB 3.0 to the host.
Indian parts this matters for: NXP i.MX 6, 7, 8M, and 9 series, TI Sitara AM335x/AM437x/AM625/AM62A, Renesas RZ/G, Xilinx Zynq-7000 PS (Cortex-A9), Zynq UltraScale+ MPSoC (Cortex-A53/R5), and ST STM32MP1/STM32MP2. If your programme is building Linux-based products on application processors and you need trace on real-time firmware running on the Cortex-R or Cortex-A companion core, this is the probe.
J-Trace PRO RISC-V
J-Trace PRO RISC-V covers RISC-V targets with trace support. RISC-V trace is still maturing, it uses the E-Trace specification, and support depends heavily on which silicon vendor’s core and trace implementation you are using. If your team is building a product on a RISC-V silicon family (SiFive, Andes, Nuclei, WCH CH32V, GD MCU, Espressif ESP32-C/ESP32-H/ESP32-P), talk to GSAS about whether the specific part exposes trace and which J-Trace PRO variant configuration is the right match.
Ozone: the host tool that turns trace into evidence
A trace probe is useless without a host tool that can decode and visualise the stream. SEGGER Ozone is that tool. Ozone is a cross-platform, compiler-agnostic debugger and trace viewer that ships free with every J-Trace PRO. It reads ELF files produced by any compiler (Arm GCC, Arm Clang, IAR EW, Keil MDK, SEGGER’s own toolchain, GCC RISC-V, LLVM RISC-V), loads the firmware onto the target through the J-Trace PRO’s built-in J-Link engine, and presents the instruction trace alongside the disassembly, the source view, the call stack, variable inspection, and (for RTOS-aware sessions) task and ISR timing.
For safety-critical evidence, three Ozone features matter most:
- Timeline view: every executed instruction laid out along a time axis. You can zoom from the full test run down to a single CPU cycle, scroll through the trace, and see which task was running at which instant. When paired with SystemView integration, you get RTOS-level context on top of the instruction-level trace.
- Coverage export: Ozone can compute statement and branch coverage from the captured trace and export it in formats your evidence pipeline consumes. For MC/DC coverage at ASIL D and DAL-A, the decision coverage that Ozone captures feeds the MC/DC calculation.
- Reverse debug on replay: once trace is captured, you can step backwards through the execution. For crash forensics this is transformative: you start at the fault and walk back through the instructions that led there, instead of trying to reproduce the fault from a clean boot.
Ozone integrates with SystemView so your RTOS task-level view and your instruction-level view are on the same timeline.
The cost/benefit case versus Lauterbach TRACE32 and the cheap-probe alternative
This is the part of the story that Indian engineering managers and procurement engineers need to hear clearly. The instruction-trace market has historically been dominated by Lauterbach TRACE32, which is the gold standard in European automotive and aerospace and is priced accordingly. A fully-loaded TRACE32 PowerTrace II setup with a Cortex-M license, Cortex-A license, and the streaming trace accessory runs into the low seven figures in INR per seat. For an Indian Tier-1 equipping a small fleet of functional-safety benches, the TRACE32 line item alone can exceed the programme’s entire debug-tooling budget.
The cheap-probe alternative is worse. Indian teams sometimes try to produce coverage evidence using a ₹5,000 CMSIS-DAP probe plus open-source instrumentation. This is cheap, but it is not defensible in front of an auditor, the instrumented binary is not the shippable binary, and there is no trace provenance.
J-Trace PRO sits deliberately in the middle. It is materially more expensive than a plain J-Link PRO (because it does continuous streaming trace, which plain J-Link cannot), but it is substantially cheaper than Lauterbach while delivering the evidence package Indian safety-critical programmes actually need for ISO 26262, IEC 62304, and DO-178C qualification. For a Pune automotive Tier-1 equipping four HiL benches with trace capability, the difference between J-Trace PRO and TRACE32 is typically enough to fund the rest of the functional-safety tool stack.
Two practical considerations to check before you commit:
- Target silicon must expose trace pins. Not every Cortex-M package breaks out the ETM trace pins. Before ordering, confirm that your target silicon and your board layout both expose the trace pins on a standard 20-pin Cortex Debug+ETM header (or a vendor-specific equivalent). If the pins are not exposed, J-Trace PRO will fall back to J-Link debug capability but you will not get the trace stream.
- Board layout needs clean trace signals. ETM trace runs at the CPU core clock divided by two or four, which is hundreds of MHz on modern Cortex-M7 and Cortex-M33 parts. Route the trace pins with controlled impedance, short stubs, and matched lengths on the target PCB, GSAS can review your schematic before tape-out.
The GSAS on-site integration workflow for Indian teams
For Indian Tier-1s new to instruction trace, GSAS runs a typical 3-day on-site engagement to bring J-Trace PRO into the functional safety evidence pipeline:
- Day 1, Hardware bring-up. Verify the trace pin routing on the target board, wire up J-Trace PRO, load the firmware, capture a first trace run. Validate the stream decode in Ozone.
- Day 2, Coverage workflow. Connect J-Trace PRO to the team’s existing test harness. Run the unit test suite with trace capture enabled. Export coverage. Demonstrate the evidence pipeline the auditor will review.
- Day 3, Crash forensics and hand-off. Set up continuous capture on the HiL bench. Walk the team through Ozone reverse-debug workflow. Hand off the runbook, establish the per-test-run trace archival process, and train the functional safety manager on reading the evidence.
After that, J-Trace PRO runs as a standing piece of the evidence-production pipeline. The CI server captures trace on every automated test run. The functional safety manager pulls coverage reports directly from Ozone when preparing the audit submission.
Further reading
- SEGGER J-Trace PRO family overview, authoritative product documentation at segger.com
- SEGGER ETM trace technology explanation at segger.com
- SEGGER J-Trace PRO Cortex-M product page at GSAS
- SEGGER J-Trace PRO Cortex-A/R product page at GSAS
- SEGGER embOS-Safe for Indian automotive Tier-1 teams, the ISO 26262 certified RTOS that pairs with J-Trace PRO trace evidence
- SystemView V4 ELF integration, the RTOS-level profiling tool that pairs with instruction trace
- SystemView for IEC 62304 medical device evidence, the medical-device evidence companion post
- SEGGER J-Link model selection guide for India, choosing between J-Link and J-Trace for your programme
- SEGGER at GSAS, full SEGGER portfolio page
- GSAS automotive industry solutions
Buy SEGGER J-Trace PRO in India from GSAS
GSAS Micro Systems is India’s authorized SEGGER engineering partner for every J-Trace PRO variant. Whether you are an automotive Tier-1 in Pune producing ISO 26262 ASIL D brake controller evidence, a medical device OEM in Hyderabad documenting IEC 62304 Class C coverage for a CDSCO submission, an avionics team in Bengaluru pursuing DO-178C DAL-B qualification, or a defence electronics house in Chennai needing instruction-trace forensics on qualification test failures, we will help you match the J-Trace PRO variant to your target silicon, review your board’s trace pin routing before tape-out, and run on-site bring-up at your facility. Contact us for a hands-on demo at any of our Bengaluru, Chennai, Hyderabad, Delhi NCR, Mumbai, or Pune offices, or visit our SEGGER India partner page for the full portfolio.
Also appears in:
Interested in SEGGER tools?
Talk to our application engineers for personalized tool recommendations.
More from SEGGER
View all →