---
title: Prompts
description: Pre-built prompt templates for common debugging workflows
---

mcjtag ships 5 MCP prompts that provide structured workflows for common debugging tasks. Each prompt returns a multi-step instruction set that an LLM client can follow, calling the appropriate mcjtag tools at each step.

Prompts are not tools -- they don't execute anything directly. Instead, they give the LLM a plan to follow. The LLM then calls the relevant tools in sequence.

---

## identify_chip

Identify what is connected to the JTAG chain.

**Parameters:** None

**Workflow:**

1. Call `jtag_scan()` to enumerate the JTAG chain
2. Note the IDCODE of each TAP
3. Look up the IDCODE to identify the chip manufacturer and part number
4. Call `target_state()` to confirm the debug connection is working
5. Report the chip identification and connection status

**When to use:** First connection to an unknown board, verifying that the debug probe is communicating correctly, or when you need to confirm which chip is on the other end of the wire. For a more thorough identification workflow, see [Target Identification](/guides/target-identification/).

**Related tools:** `jtag_scan`, `target_state`, `probe_diagnostics`

---

## debug_crash

Diagnose a HardFault or unexpected halt by inspecting CPU state and the call stack.

**Parameters:** None

**Workflow:**

1. Call `target_control(action="halt")` to stop the CPU
2. Call `read_registers(names=["pc", "lr", "sp", "xPSR"])` to read key registers
3. Examine the PC to determine where execution stopped
4. Examine the LR to identify the caller (return address)
5. Read the stack: `read_memory(address=<sp value>, count=16, width=32)`
6. Check if xPSR indicates a fault (exception number in bits 0--8)
7. If in a fault handler, read the stacked exception frame at the SP value
8. Report the crash location, call chain, and likely cause

**When to use:** After a HardFault, an unexpected reset, or when firmware appears to hang. The xPSR exception number indicates which fault occurred:

| Exception Number | Fault |
|-----------------|-------|
| 2 | NMI |
| 3 | HardFault |
| 4 | MemManage |
| 5 | BusFault |
| 6 | UsageFault |

**Related tools:** `target_control`, `read_registers`, `read_memory`, `target_state`

---

## reverse_engineer_peripheral

Decode a peripheral's registers using SVD metadata to understand its current configuration.

**Parameters:**

| Parameter | Type | Description |
|-----------|------|-------------|
| `peripheral` | `str` | Peripheral name (e.g. `"GPIOA"`, `"USART1"`, `"TIM1"`) |

**Workflow:**

1. If no SVD is loaded, ask for the SVD file path and call `svd_inspect(svd_path=...)`
2. Call `svd_inspect(peripheral="<name>")` to read and decode all registers
3. For each register, analyze the bitfield values
4. Determine the current configuration of the peripheral
5. Report what the peripheral is doing based on the register values
6. Note any unusual or potentially problematic settings

**When to use:** Understanding what a peripheral is configured to do on a running or halted system. Particularly useful for:

- Debugging communication interfaces (USART, SPI, I2C) that aren't behaving as expected
- Understanding GPIO pin configurations
- Analyzing clock tree setup (RCC peripheral)
- Inspecting timer configurations

**Related tools:** `svd_inspect`, `read_memory`

---

## flash_and_verify

Complete flash programming workflow: halt, erase, program, verify, and reset.

**Parameters:**

| Parameter | Type | Description |
|-----------|------|-------------|
| `image_path` | `str` | Path to the firmware image file |

**Workflow:**

1. Call `target_control(action="halt")` to stop the CPU
2. Call `flash_info()` to check flash bank topology
3. Call `flash_program(path="<image_path>", erase=True, verify=True)`
4. Check the result for success or failure
5. If successful, call `target_control(action="reset_run")` to start the new firmware
6. Wait a moment, then call `target_state()` to confirm it is running
7. Report the flash result and post-reset status

**When to use:** Deploying new firmware to the target. The workflow ensures the target is in a clean state before programming and verifies the result afterward.

Supported firmware formats: `.bin`, `.hex`, `.elf`, `.ihex`, `.srec`, `.s19`

**Related tools:** `target_control`, `flash_info`, `flash_program`, `target_state`

---

## memory_map

Build a memory map of the target by reading the vector table and probing accessible regions.

**Parameters:** None

**Workflow:**

1. Call `target_control(action="halt")` to stop the CPU
2. Read the vector table: `read_memory(address="0x08000000", count=8, width=32)`
   - Word 0: Initial stack pointer (top of RAM)
   - Word 1: Reset vector (start of code)
   - Words 2--7: NMI, HardFault, and other exception vectors
3. Call `flash_info()` to get flash bank sizes and base addresses
4. From the initial SP, deduce the RAM region (SP points to the end of RAM)
5. Read a few bytes at common peripheral base addresses to verify accessibility:
   - `0x40000000` (APB1 peripherals)
   - `0x40010000` (APB2 peripherals)
   - `0xE000E000` (System control block)
6. Build and report the memory map:
   - Flash: base, size, sector layout
   - RAM: base, estimated size
   - Peripheral regions
   - Vector table summary

**When to use:** First encounter with an unknown target, or when you need to understand the memory layout before writing scripts or debugging. The vector table at `0x08000000` (aliased from `0x00000000` on STM32) provides key information about the firmware's memory usage.

See [Memory Layout](/concepts/memory-layout/) for background on the ARM Cortex-M address map.

**Related tools:** `target_control`, `read_memory`, `flash_info`

---

## Using Prompts

MCP clients invoke prompts differently from tools. In Claude Code, prompts are typically surfaced as suggestions or invoked by the client automatically based on context.

A prompt call returns a string containing the step-by-step plan. The LLM then follows the plan by making the appropriate tool calls. The prompt itself does not interact with the hardware.

For example, invoking `identify_chip()` returns this text:

```
Identify the connected chip:
1. Call jtag_scan() to enumerate the JTAG chain
2. Note the IDCODE of each TAP
3. Look up the IDCODE to identify the chip manufacturer and part number
4. Call target_state() to confirm the debug connection is working
5. Report the chip identification and connection status
```

The LLM reads these instructions and begins executing the tools in order, adapting based on what each step returns.
