SEGGER shipped a simulator. Here's what it does and what it doesn't.

SEGGER sells debug probes. That is the business — a physical object you plug into a physical board, plus software that makes it useful. In July 2026 they shipped a product that makes the object unnecessary.

Ozone-Sim runs your firmware on your PC. No J-Link, no target. SEGGER says so in its own FAQ: "Do I need a J-Link debug probe to use Ozone-Sim? No. Ozone-Sim is a pure software simulator. You can run, debug, and profile your embedded applications entirely hardware-free, without requiring a physical J-Link or target board."¹

When the company whose margin depends on you owning a probe builds a supported way to skip it, that is a useful read on where firmware development is going.

What Ozone-Sim shipped, and when

The press release is dated 3 July 2026: "With Ozone-Sim, SEGGER introduces a high-performance instruction set simulator designed to accelerate embedded software development, debugging, testing, and analysis."² The code landed a day earlier — the Ozone release notes list Version 3.50 [02 Jul 2026] with a New Features entry reading "Added Ozone Simulator."³

The manual is UM20008, and it gives you the shape in one line: "Ozone-Sim is a fast simulator for ARM32 and RISC-V based MCUs. It can be used in two different modes: GDB server... Standalone mode."⁴ Those two modes are the whole product surface.

GDB server mode exposes the simulator over a socket: "An integrated GDB server interface enables the simulator to be used with a wide range of third-party debuggers and development environments."² Ozone attaches this way.

That server capability isn't new. In September 2025 SEGGER said Ozone was "now available for simulators and third-party debug probes," using "the industry-standard GDB Remote Protocol."⁵ The release notes call it "Added Interface to GDB server," Version 3.40.³ That was Ozone becoming a GDB client. Ozone-Sim, ten months later, is the other end of that connection, not the same product.

Standalone mode is the CI mode. You hand it an ELF, it runs, it exits with a code.

On speed, SEGGER reports "up to 700 million instructions per second (on an AMD Ryzen 9)."¹ That is the vendor's own number, with no published workload and no methodology.

The scope question, answered by the vendor

Here is the paragraph that should govern how you think about this product. It is SEGGER's own FAQ, on SEGGER's own product page:

"Does Ozone-Sim support emulation of device peripherals? At this point, Ozone-Sim does not support emulation of device peripherals. Support may be added in a future release. Ozone-Sim does include emulation of the Cortex-M SysTick, allowing operating systems such as embOS to be simulated."¹

No peripheral emulation. One exception, SysTick: without a tick an RTOS does not schedule, and without scheduling the simulator cannot run the software most people want to run.

That is the hardest question about the product, answered in plain words in the FAQ, where a buyer will find it.

Whether temporary or permanent, it is a coherent scope for a first release. Peripheral models are where simulator projects go to die: every part number is a fresh pile of registers, every register has errata, and the maintenance cost never stops growing. Declining to start is a legitimate way to ship something fast and keep it fast. What it buys and what it costs split cleanly:

Question you're asking	Ozone-Sim's scope
Does my sorting/DSP/crypto routine produce the right output?	Yes — pure computation on a modeled core
Does my RTOS schedule tasks in the right order?	Yes — SysTick is modeled, and SEGGER names embOS
Does my state machine reach the right state for this input sequence?	Yes, if every input and observation fits through semihosting
Did my refactor change target-independent behavior across my test suite?	Yes, fast, and in parallel
Does my UART driver configure the baud divisor correctly?	No — there is no UART
Does my DMA controller hand off correctly at a buffer boundary?	No — there is no DMA controller
Does my code survive this chip's silicon erratum?	No

One thing I deliberately cannot tell you: whether the simulation is cycle-accurate. SEGGER does not use the words "cycle-accurate" or "timing-accurate" anywhere I could find, and publishes no claim about instruction timing, bus contention or wait states. Absence of a claim is not a claim of absence. It is an open question, and if timing fidelity matters to your tests, ask before you plan around an answer.

--chip STM32F407VE configures memory, not silicon

The manual's configuration section reads: "The simulator can be configured by specifying a known MCU name, a known core name or via a list of features which constitute a core... If no MCU/core/feature options are provided, a 'default Cortex-M7' core with ample memory is used."⁴ The known-MCU list is short, and here it is verbatim:

• "STM32F407VE: MCU used on the SEGGER Cortex M trace reference board."
• "STM32H743ZI: MCU used on the SEGGER STM32H7 trace reference board."
• "K66P144M180SF5RMV2: MCU on the Segger emPower board."
• "XC7Z007S: Zynq7007S Cortex-A9 MCU."
• "default: A Cortex-M7 with flash memory banks..."⁴

Read that cold and you will conclude Ozone-Sim simulates an STM32F407. It does not. Cross-reference the FAQ above: there is no peripheral emulation, so there is nothing behind the part number except a core selection and a memory map. --chip STM32F407VE tells the simulator where flash starts, how big the RAM banks are, and which architecture profile to decode. Your linker script will be happy. Your driver will not find a peripheral to talk to.

It is a naming collision between "the chip I am building for" and "the chip this flag is named after," and it is the misreading worth guarding against. Peripheral fidelity is where simulator claims most often outrun reality, which is the longer argument in what simulation can't catch.

Semihosting is the entire I/O story, and that's a clean design

If there are no peripherals, how does simulated firmware talk to anything? Semihosting.

The manual is specific about the boundaries. File access is sandboxed: "Semihosting file access can either be handled by the simulator or by the GDB client. The simulator will only perform file access in the directory provided via the --file-root <path> option."⁴

Arguments arrive the same way, and the manual's own example is a regression runner: "a regression test executable might need the name of the test cases to execute. This could be achieved with the following statement: ozone-sim --standalone --bss --arg multiplication --arg addition --arg quicksort CortexM-regression.elf"⁴

Results come back as a process exit code: "In standalone mode, a semihosting exit call will cause the simulator to exit with the code provided to the semihosting call."⁴

That is a complete CI contract in three flags. Firmware in, arguments in, exit code out.

The termination logic is better than it needed to be. Standalone mode "will run until the application performs a semihosting SYS_EXIT operation or until an unhandled exception occurs. Endless loops are also detected by the simulator and will also cause it to stop the simulation."⁴

The slogan is a partner's, and the claims under it check out

The phrase attached to this product in a lot of secondhand coverage is "hardware-free CI/CD regression testing." I went looking for it in SEGGER's material and it is not there.

It comes from a blog post by GSAS, which describes itself as "SEGGER's authorized engineering partner in India."⁶⁷ Which is where I expected to write the usual paragraph about partner content inflating a vendor's scope, because that is overwhelmingly what turned up when we read every embedded simulator comparison on the internet.

Not this time. Take the slogan apart and every piece traces to SEGGER's own documentation. Hardware-free: the FAQ says no J-Link and no target board required.¹ CI/CD: standalone mode exists for it and returns exit codes.⁴ Regression testing: the manual's own worked example is a regression executable taking test-case names as arguments.⁴ Compressed marketing, but compressed from real material.

The same partner post also states the limits more plainly than most first-party copy manages: "Simulation is not a replacement for every test, and no serious embedded team treats it as one. Ozone-Sim validates application logic, RTOS behavior, driver state machines and algorithmic correctness quickly and repeatably, but it does not exercise real peripheral timing, board-level electrical behavior, or interaction with actual sensors and actuators."⁶

Nobody outside SEGGER has run it yet

Six weeks after launch there is no independent hands-on review and no reproduced benchmark. Two trade outlets rewrote the press release⁸⁹ without running the tool. Everything else is SEGGER's material, SEGGER's forum, and the partner's blog. So if you are weighing this against something you already run, you are the one generating the data. Same problem as any Renode alternative evaluation: you run your own firmware and see.

Where it sits on the ladder

We keep a rough ladder for this: host unit tests at the bottom, then instruction set simulation, then generic-core emulation, then simulation of specific silicon, then real hardware. I laid it out properly in Wokwi vs Renode vs QEMU, and Ozone-Sim slots in cleanly at the ISS rung.

That rung is a real tier, not a consolation prize. It is the fastest thing that still executes your actual compiled binary — same instructions, same linker layout, same compiler bugs. Host unit tests do not do that; they run host code you compiled twice.

What the rung cannot do is answer a question about a register that does not exist in the model. If the thing you need to test is the peripheral — the UART divisor, the DMA handoff, the timer capture — you move up to something that models the actual part. That is the tier Chiplab occupies, and it is a different job from the one Ozone-Sim signed up for, not a better version of it.

The part I actually care about

I write about coding agents, so here is the connection. An agent writing firmware needs a loop that closes: write a change, run something, read a result, adjust. An ISS closes that loop for a large class of work — algorithms, RTOS behavior, state machines, refactor regressions — in milliseconds, and hands back an exit code the agent can read without parsing anything. Arguments in, exit code out is close to the ideal machine interface.

It leaves the loop wide open for driver work, because there is nothing on the other end of the driver. An agent asked to fix a UART configuration on Ozone-Sim would produce a patch and get no signal at all about whether the patch was right.

A probe vendor built a real rung of the ladder and told you exactly which rung it is. The remaining work is knowing which of your tests live there — and staying disciplined about not letting a chip name in a command-line flag talk you into thinking more of them do.

Sources

Footnotes

1. SEGGER, "Ozone-Sim," SEGGER product page (technology / Ozone-Sim), accessed 2026-08-13. https://www.segger.com/products/development-tools/ozone-j-link-debugger/technology/ozone-sim/ ↩ ↩² ↩³ ↩⁴

2. SEGGER, "SEGGER introduces Ozone-Sim," SEGGER press release, 2026-07-03. https://www.segger.com/news/pr-260703-ozone-sim/ ↩ ↩²

3. SEGGER, "Ozone Release Notes," SEGGER, accessed 2026-08-13. https://www.segger.com/downloads/jlink/ReleaseNotes_Ozone.html ↩ ↩²

4. SEGGER, "UM20008 — Ozone-Sim User Guide," SEGGER documentation, accessed 2026-08-13. https://doc.segger.com/UM20008_Ozone-Sim.html ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹

5. SEGGER, "SEGGER's Ozone now available for simulators and third-party debug probes," SEGGER press release, 2025-09-09. https://www.segger.com/news/pr-250909-ozone-simulators/ ↩

6. GSAS, "Hardware-free CI/CD regression testing for embedded teams," GSAS blog, 2026-07-08. https://gsasindia.com/blog/hardware-free-ci-cd-regression-testing-embedded-india ↩ ↩²

7. GSAS, "SEGGER Ozone-Sim," GSAS product page, accessed 2026-08-13. https://gsasindia.com/products/segger/segger-ozone-sim ↩

8. Electronic Design, "SEGGER Ozone-Sim Enables Hardware-Free Firmware Debugging," Electronic Design, 2026-07-24. https://www.electronicdesign.com/technologies/eda/product/55393421/electronic-design-segger-ozone-sim-enables-hardware-free-firmware-debugging ↩

9. eeNews Europe, "SEGGER launches Ozone-Sim for embedded software simulation," eeNews Europe, 2026-07-24. https://www.eenewseurope.com/en/segger-launches-ozone-sim-for-embedded-software-simulation/ ↩