Prompts

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.

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