// Debug Over I3C
Debug on the bus
you already have.
MIPI Debug Over I3C carries halt-mode debug and trace over the same two wires as your functional I3C bus, no separate debug port to route. Drive it with the Supernova, decode it with our I3C Analyzer.
// the specification
Debug and trace, defined by MIPI.
MIPI Debug Over I3C defines how a Debug and Test System (DTS) and a Target System (TS) communicate over an I3C bus. It covers both basic debug control, such as halt-mode debugging of processors, and tracing, where streams of data flow from the target to be decoded and analyzed in the DTS. The DTS acts as the I3C controller; the target is an I3C target.
It builds directly on I3C’s own mechanisms: eight Common Command Codes reserved for debug, four broadcast and four direct, plus in-band interrupts that carry triggers and events from the target back to the DTS. The bus can be dedicated to debug or shared with normal functional use, with a separate dynamic address for each, and the behavior is implemented in hardware, software, or a mix. Published by the MIPI Debug Working Group in 2020 and extended in 2024.
// how it works
A DTS, the I3C bus, and a Target System.
The Debug and Test System drives the bus as the I3C controller, reaches the Target System over the same two wires the design already runs, and uses I3C’s own extensions to configure, trigger, and collect debug and trace.
// the debugger
Debug and Test System
The DTS is the debugger. It drives the bus as the I3C controller, primary or secondary, issuing debug commands and collecting trace as ordinary I3C transactions over the two-wire bus.
// the bus
Dedicated or shared
The I3C bus can be used solely for debug, or shared with normal functional traffic. When shared, debug and functional use each take a separate I3C dynamic address, so one two-wire bus carries both.
// the target
Target System
The TS exposes its debug logic as an I3C target. A single bus can reach several Target Systems, each addressed dynamically, for both halt-mode debug control and trace streamed back to the DTS.
// the mechanics
Debug CCCs and IBIs
Debug rides on I3C’s own extensions: eight Common Command Codes reserved for debug, four broadcast and four direct, plus in-band interrupts that carry triggers, status, and events from the target back to the DTS.
// why it matters
Fewer pins. The bus you already route.
Low pin count
Debug rides on the two I3C wires instead of adding dedicated debug pins and a separate trace port, reclaiming package and board area on space-constrained designs.
Reuse the functional bus
I3C is already present as the sensor and control bus, so debug access runs on hardware that is already there, and can share the bus with functional traffic.
Built for power-managed parts
With hot-join and dynamic addressing, application processors, PMICs, and modems can drop off and rejoin the debug bus across power states, in the lab and in the field.
// the tools
Drive the bus. See the traffic.
The Supernova is the I3C controller you use to exercise the bus a debug session runs on. The I3C Analyzer decodes that bus, so you can see the transactions, CCCs, and interrupts underneath.
Hardware · USB Host Adapter
Binho Supernova
Exercise the bus.
The Supernova is a full I3C controller or target: bring up the bus, run dynamic addressing, issue CCCs, and handle in-band interrupts and hot-join. Script it from a GUI, Python, or C.
- Controller or target on the I3C bus
- CCCs, IBIs, hot-join, dynamic addressing
- Scriptable from a GUI, Python, or C
Software · Saleae Plugin
I3C Protocol Analyzer Plugin
See the bus underneath.
The I3C Protocol Analyzer decodes the I3C traffic a debug session rides on, dynamic addressing, CCCs, and in-band interrupts, inside the Saleae Logic tool your team already uses.
- Decodes DAA, CCCs, IBI, and PEC
- SDR, HDR-DDR, and HDR-BT modes
- Runs in Saleae Logic 1.x and 2.x
// our edge
I3C is what we do.
Debug Over I3C is one of many protocols now built on I3C, and I3C is the bus Binho knows best.
MIPI Contributor Member
Binho is a MIPI Alliance Contributor Member, actively working on the I3C specification the whole ecosystem builds on.
Semiconductor teams
200+ semiconductor companies use Binho tools to develop, validate, and ship devices with I3C support.
MIPI I3C Plugfests
We’ve verified our tools at the past 4 MIPI I3C Plugfests, and helped others verify theirs too.
// trusted by engineering teams at
+ hundreds more
// faq
Common questions.
What is Debug Over I3C?
Debug Over I3C is a MIPI Alliance specification that defines how a Debug and Test System (DTS) and a Target System (TS) communicate over an I3C bus, for basic debug control such as halt-mode debugging, and for tracing, where data streams from the target are decoded and analyzed in the DTS. It reuses the two-wire I3C bus instead of a dedicated debug port.
Does it replace JTAG or SWD?
No. Debug Over I3C is a different approach, not a drop-in replacement for JTAG or SWD. It carries debug and trace over the functional I3C bus a design already has, a low-pin-count path for debug access that fits within the broader MIPI Debug Architecture alongside traditional debug interfaces.
Is Debug Over I3C a published specification?
Yes. MIPI published it in 2020 (originally as Debug for I3C) and extended it in 2024, when it was renamed Debug Over I3C.
How does it use the I3C bus?
The I3C specification reserves eight Common Command Codes for debug, four broadcast and four direct, and Debug Over I3C defines their formats. In-band interrupts carry triggers, status, and events from the Target System back to the Debug and Test System, and dynamic addressing lets one bus reach several targets. The bus can be dedicated to debug or shared with normal functional traffic.
Can I work with Debug Over I3C using Binho tools?
Yes. The Supernova drives and brings up the I3C bus a debug session runs on, and the I3C Protocol Analyzer decodes that bus, its transactions, CCCs, and interrupts, so you can see what is happening underneath.
Explore the Supernova How does it relate to the other protocols over I3C?
Debug Over I3C is MIPI’s debug and test transport on I3C. It sits alongside other layered protocols that ride the same bus, such as MCTP over I3C for management, JESD300 SPD for DDR5 memory, and the emerging I/Os over I3C Bridge, each defined by its own standards body.
Explore the I3C protocol