BKPT Toolkit · In development

Arm and RISC-V hardware investigation.
Ready for AI.

BKPT Toolkit brings Arm Cortex-M and RISC-V debugging into one command interface for execution history, hardware trace, and firmware insight. Give your agent ready-to-use operations to test a hypothesis and inspect the results.

Arm CoreSight and RISC-V N-Trace configuration, capture, and decoding are built in for supported targets. Keep one session open, choose the next operation from the last result, and query decoded evidence. Move from a debugging question to the next experiment with less setup.

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 / the path into a faultExample workflow
# Keep execution history; decode when a fault stops it
bkpt> etm.arm {"output":"history","cpu_hz":64000000,"decode":{"on":["fault"]}}
bkpt> fault.configure {"classes":["all"]}
bkpt> run.continue {"wait":true}

# Read the decoded fault and frame trust
bkpt> fault.analyze {}

# After decoding, query the reported recording path
bkpt> etm.query {"recording":"DECODED_PATH","part":"functions"}
Recorded executionDecoded faultEvidence to query
Arm Cortex-M example for an attached, halted core with supported ETMv4 history and a matching ELF. Set your CPU clock and replace DECODED_PATH with the recording path returned after decoding.
Targets
Arm Cortex-M · RISC-V
Debug probes
ST-LINK · J-Link · FTDI JTAG
Host platforms
Windows · macOS · Linux
Interfaces
CLI · Scripts · JSONL stdio

Built-in debug expertise

Hardware setup.
Decoded evidence.

The same Toolkit command interface works across Arm Cortex-M and supported RISC-V targets. Connect with ST-LINK or J-Link for Cortex-M, or FTDI JTAG for RISC-V. AMD MicroBlaze V designs use the MicroBlaze Debug Module V (MDM V) BSCAN interface.

Toolkit coordinates GDB, live acquisition, and analysis through the shared probe connection. Follow recorded execution into a failure, observe CPU accesses and interrupt activity, or turn live peripheral and firmware state into findings with Trace Domains.

Investigations

Start with the question.
Collect the hardware evidence.

Use the observation that fits the failure. Toolkit handles supported setup, acquisition, and decoding, and keeps the evidence available for the next question.

What happened before it failed?

Keep rolling execution history with Arm ETM or RISC-V N-Trace on compatible targets. Capture at a breakpoint, pause, or supported fault stop, then query calls, branches, invocation paths, and available source coverage. A frozen copy of the ELF keeps the recording tied to the code it captured.

Which CPU access changed this value?

On targets with data watchpoints, stop on a matching CPU access and inspect the responsible context. Supported Arm Cortex-M DWT trace can also record these accesses while firmware runs, alongside interrupt activity, counters, and ITM output.

What is this subsystem doing?

Trace Domains combine live registers, firmware variables, descriptor rings, and structured fields with decoding and rules. Get named states, derived values, and findings with their evidence, then query what the sampled window shows.

What does this fault tell me?

On Arm Cortex-M, catch supported faults before the handler runs. Read decoded status, escalation, valid fault addresses, and reconstructed exception frames, with FPU and security context where available. Frame trust and fault precision make the limits of the evidence explicit.

Where is the CPU spending its time?

Collect statistical PC samples with symbol and source attribution on supported Arm Cortex-M targets. Follow variables and peripheral registers while firmware runs where live memory access is available. Supported SWO routes also expose hardware PC samples and exception events.

Can I repeat this investigation?

Turn the workflow into ordered commands with deadlines and explicit expectations. Save captures and results for review, check acquisition health, and inspect the cleanup outcome alongside the investigation.

Features depend on the target and capture route. ETM and N-Trace record execution, not historical RAM values; Arm DWT observes CPU accesses, and polling can miss changes between reads.

Inside the toolkit

One sustained investigation.

Run control, inspection, and supported acquisition share the native probe connection. bkpt capabilities lists implemented operations and build limits; target discovery and session reports describe hardware support.

Capability discovery

Enumerate ST-LINK, J-Link, and FTDI JTAG adapters. ST-LINK scans discover cores and CoreSight components; J-Link uses its configured device and one SDK-selected core. RISC-V sessions identify the hart and report the supported debug, memory, and trace capabilities.

Debugger control and inspection

Attach or launch, continue, pause, step, or run to a location. Use conditional breakpoints, supported hardware watchpoints, registers, backtraces, locals, expressions, memory, and disassembly with opcodes.

Firmware and source identity

Compare sampled ELF load bytes with the target before trusting symbols. Reload symbols after a rebuild without dropping the session, and preserve frozen source identity with trace recordings. Sampled checks are not full-image verification.

Execution history you can revisit

Capture Arm ETMv4 history through supported ETF or ETR storage, or RISC-V N-Trace through an on-chip trace buffer. Capture at selected stops, decode in the background, and query retained recordings after the session closes. Each route requires compatible trace hardware and a matching ELF.

Multicore and multiple images

On supported ST-LINK targets, control cores independently or as a group, inspect each outcome, and detach one core while preserving its peers. Load multiple images on a core, qualify symbols by image, and inspect accessible TrustZone security state and register banks.

Live state and Trace Domains

Sample symbols, memory, and supported SVD registers over the shared connection. Domain descriptors decode inputs into values and findings, with explicit reasons when an input is unavailable. SVD sampling respects read-action metadata.

Saved contexts and offline analysis

Inspect a supplied saved register context and its backtrace. Query ELF symbols, sections, and memory use without a target; use a linker map for region capacities. Automatic RTOS task discovery is not yet available.

Explicit writes and recovery

Write memory, variables, or registers through explicit operations and inspect the readback. Reconnect and verify, then explicitly restore preserved breakpoints, watchpoints, and fault catch. Run or halt policies on close report whether cleanup was confirmed.

An interface agents can discover

Use bkpt describe for operation arguments, result schemas, effects, and bounds. JSON replies and asynchronous events identify relevant session, core, and source context; acquisition reports include provenance and loss information.

The engine behind BKPT Debug

BKPT Debug uses Toolkit for its debugging workflow. Drive the same engine from a terminal, ordered script, or persistent JSONL process, with native probe and analysis tools included. Use the GDB and binutils toolchain for your target architecture; FTDI adapters also need the D2XX driver.

Toolkit is in development. It does not program flash or call target functions. Acquisition combinations depend on hardware resources and the current session; inspect the capability and activity reports for the exact build.

Two ways to automate

An agent at the bench.
A check in the pipeline.

Bring your existing AI agent or CI runner. No editor is required to drive the toolkit.

For AI agents

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 --stdio

A JSONL process interface for sustained control, with request IDs, operation schemas, explicit errors, and asynchronous events. Integrate it with your agent or automation runner; CLI commands also work for focused tasks.

For CI pipelines

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-check

Or script an ordered session where each step carries an expectation against its structured result:

{"op":"stack.list","args":{"limit":2},
 "expect":{"path":"/result/frames/0/func","equals":"Reset_Handler"}}

Getting started

Built around your firmware
and your workflow.

Start with programmed firmware, its matching debug ELF, and a GDB toolchain for your architecture. Arm Cortex-M connects through ST-LINK or J-Link; supported RISC-V targets connect through FTDI JTAG with the D2XX driver. J-Link also requires SEGGER’s installed software and a device configuration.

The ST-LINK discovery workflow:

$ bkpt probes
$ bkpt scan --serial SERIAL --elf build/app.elf --out-config debug.json
$ bkpt doctor --config debug.json
$ bkpt debug --config debug.json

After attaching, run firmware.verify {} while halted before trusting symbols or variables. This compares sampled load bytes with the target.

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.

One license. The whole toolkit.

BKPT Toolkit is included alongside ViewAlyzer and BKPT Debug.
No separate Toolkit purchase.