Catch faults at the source
Configure the core’s hardware fault catch before running. Inspect decoded fault status and exception-frame evidence after the halt, alongside registers and stack frames.
BKPT Toolkit · In development
When was the last time your AI agent captured instruction trace on a chip that supports it, configured vector catch registers and unwound a HardFault, decoded ETM/ITM trace, graphed live variables, or tracked your RTOS tasks? Configured and used DWT to catch memory and peripheral access? And did it reliably across the range of ARM cores, adapting to each core’s capabilities and vendor quirks and nuances? Sure it can, after spinning its wheels writing a custom parser, wait is it ETMv3 or ETMv4? That’s an entire other code base to maintain. We got your back!
Your agent doesn’t write its own compiler or reimplement GDB. It reaches for the tools already on the machine. BKPT Toolkit is one more tool to reach for, with ARM CoreSight features configured for you.
Give your agent more than stepping, pausing, and breakpoints. BKPT Toolkit makes advanced ARM debugging accessible through ready-to-use commands, persistent sessions, and structured results.
For AI agents, CI pipelines, and engineers who work at the command line.
Included in your BKPT Pro license. One license for all three products.
$ bkpt debug --config debug.json
# Check the firmware against your ELF
bkpt> firmware.verify {}
# Arm hardware fault catch, then run
bkpt> fault.configure {"classes":["all"]}
bkpt> run.continue {"wait":true}
# Inspect the stop in the same session
bkpt> fault.analyze {}
bkpt> stack.list {"limit":8}
Beyond the basics
An AI agent can spend an investigation stepping through code and reading memory while the core’s fault catch, data watchpoints, and trace hardware sit unused. Reaching for those features often means learning register setup, managing a capture, and writing a decoder before the real investigation even starts.
BKPT Toolkit packages that expertise into operations an agent can discover and call. Fault catch and live sampling are already part of the development build. The roadmap extends that approach to on-chip ETM capture and decoded execution history, so the agent can use the evidence without building its own trace parser.
In the development build
Native debug operations with machine-readable arguments and results. Availability depends on the target, probe, and current session.
Configure the core’s hardware fault catch before running. Inspect decoded fault status and exception-frame evidence after the halt, alongside registers and stack frames.
Set a hardware data watchpoint on a memory location. Stop on a matching CPU access and inspect the code and call stack responsible for the change.
Collect PC samples and live memory values while firmware runs. Read bounded sample history and loss counts, then pause for a closer inspection in the same session.
Made for automation
The toolkit handles debug operations. Your agent or test harness decides what to investigate next.
List implemented operations with bkpt capabilities. Ask bkpt describe fault.configure for the arguments, result schema, and bounds of a specific operation.
Use one target connection across run control, fault inspection, and compatible sampling. Keep investigating without rebuilding the debug session for every command.
Consume JSON replies, error codes, and asynchronous events. Track which session and core produced a result, and inspect capture quality before drawing conclusions.
Run ordered scripts with deadlines and explicit expectations. Save results for CI, stop on a failed step, and inspect the cleanup outcome alongside the investigation.
Two ways to automate
Bring your existing AI agent or CI runner. No editor is required to drive the toolkit.
Start a persistent engine, discover its operations, and choose the next request from the last result. Keep reading events while an investigation runs.
$ bkpt engine --stdioA JSONL process interface for sustained control. CLI commands also work for focused tasks. Dedicated MCP and Python adapters are planned.
Turn an intermittent fault into a repeatable check with a bounded observation window, an expected outcome, and saved results.
$ bkpt fault catch --config debug.json --timeout 30 --expect no-fault --json --out results/fault-checkExample for a configured single-core target with programmed firmware. Check the exit status, fault evidence, and cleanup result; a passing window only covers the observed run.
Where we’re going
These capabilities are planned. They are not available in the current Toolkit development build.
Configure a supported on-chip trace sink, capture execution, and decode instruction and call history. Put the path to a failure within an agent’s reach without asking it to write an ETM parser.
Bring SWO/ITM events, exception and counter data, RTOS task inspection, and supported task contexts into automated investigations.
Add SVD-aware peripheral access, Trace Domains, recording queries, and static ELF analysis to give agents more context about the system they’re debugging.
Trace features require compatible hardware and a supported capture route. ETM history records execution; it does not recover historical RAM values. Feature scope and availability will evolve during development.
Getting started
Use a supported ARM target, an ST-LINK or J-Link, programmed firmware, its matching debug ELF, and an ARM-capable GDB. J-Link connections also require SEGGER’s installed software. Firmware programming remains a separate step.
BKPT Toolkit is in active development. Contact us about access and your target, or talk through the investigation you want your agent or CI pipeline to automate.
BKPT Toolkit is included alongside ViewAlyzer and BKPT Debug.
No separate Toolkit purchase. Planned features remain in development.