ChipCtx MCU Specs
Authoritative MCU chip specification queries for embedded development.
Real-time access to chip parameters, pin definitions, TRM registers, and programming guides
via the ChipCtx MCP Server.
When to Apply
Activate this Skill when ANY of the following conditions are detected:
1. Explicit — User mentions chip model
- Specific model: STM32F407VGT6, ESP32-S3-WROOM-1, nRF52840
- Series reference: "STM32F4 series", "ESP32", "nRF52"
- Chip search or comparison: "which chip has BLE and 1MB flash?"
2. Code Context — Chip-specific headers or APIs
- Headers: , , ,
- HAL/SDK calls: , ,
- Chip-specific register or memory address references
3. Project Configuration — Build system files
- STM32CubeMX files
- with
- / with MCU definitions ()
- ESP-IDF , Zephyr
4. Topic-Related — Hardware discussion
- Pin assignments, peripheral configuration, register operations
- GPIO, UART, SPI, I2C, ADC, DMA, Timer topics
- Datasheet, TRM, or hardware design references
MCP Interface Quick Reference
MCP Server Endpoint: (Streamable HTTP)
| User Intent | MCP Tool | Input | Output |
|---|
| Find/identify chip model | | query (string) | Chip list with id, model, vendor, series, matchScore |
| Chip parameters & specs | | chipId, category? | Core params, electrical specs, peripheral list |
| Pin definitions & package | | chipId, query? | Pin table with AF mapping, package info |
| TRM registers & modules | | chipId, section? | TRM sections, register/field definitions |
| Programming guide & code | | chipId, topic | Init steps, code examples, pitfalls |
Key Principle: bridges all queries. Always call
first to obtain
, then use it in all subsequent tool calls.
Intent Routing Matrix
| Keywords in User Query | Tool to Call | Priority |
|---|
| Model, series, find, compare, identify | | Always call first |
| Parameters, specs, frequency, flash, RAM, features | | Basic info |
| Pin, GPIO, package, pinout, AF | | Hardware design |
| Register, TRM, module, address, bit field | | Deep technical |
| Code, init, configure, program, example, HAL | | Programming |
Standard Query Flow
Every chip-related query follows this 5-step flow:
Step 1: Extract chip model keywords from user input or project context
Step 2: chip_identify(query) -> validate model, get chipId
Step 3: Check matchScore -> confirm unique match or ask user to select
Step 4: Route to appropriate tool based on user intent
Step 5: Format and present results, generate code if requested
Important: Never skip Step 2. All other tools require
from
.
Hardware-Aware Identification
The chip identification flow supports automatic detection from project context:
Automatic Detection Sources:
- C/C++ header includes: -> STM32F4 series
- Platform IO config:
board = esp32-s3-devkitc-1
-> ESP32-S3
- CMake definitions: -> nRF52840
- STM32CubeMX files: project chip configuration
matchScore Thresholds:
-
= 0.9: High confidence, proceed directly
- 0.7-0.9: Moderate confidence, confirm with user
- < 0.7: Low confidence, present candidates for user selection
Multi-Candidate Handling:
When multiple chips match, present a numbered list with model, vendor, and description. Ask the user to select. Never silently pick a low-confidence match.
See
rules/flow-chip-identify.md
for detailed flow and error handling.
Context Injection Strategy
After chip identification, inject specification data progressively:
Layer 1: Always Inject (after identification)
- Chip model, vendor, series
- CPU core (e.g., ARM Cortex-M4), max frequency
- Flash and RAM capacity, operating voltage
Layer 2: On-Demand Inject (when discussing peripherals)
- Peripheral specs (UART count, SPI features, etc.)
- Pin definitions and alternate functions for specific peripherals
- Package info (pin count, dimensions)
Layer 3: Deep Inject (when writing low-level code)
- TRM register definitions (name, address, bit fields, access type)
- Programming guide with init sequences and code examples
- Both HAL-level and register-level implementations
Context Management
- Avoid overflow: Do NOT load all chip data at once. Load only what the current task needs.
- Prioritize relevance: When discussing UART, load UART data, not all peripherals.
- Chip switching: When user switches to a different chip, clear old context completely and load new chip data. Never mix data from different chips.
See
rules/flow-context-inject.md
for detailed injection flow.
Supported Chip Families
| Vendor | Series | Example Models |
|---|
| STMicroelectronics | STM32F0/F1/F2/F3/F4/F7/H7/L0/L1/L4/G0/G4/U5/WB/WL | STM32F407VGT6 |
| Espressif | ESP32/ESP32-S2/S3/C3/C6/H2 | ESP32-S3-WROOM-1 |
| Nordic Semiconductor | nRF52810/832/833/840 | nRF52840 |
Rule Categories
Detailed rules are organized in
for progressive loading:
| File | Impact | Description |
|---|
rules/flow-chip-identify.md
| HIGH | Chip identification triggers, 5-step flow, matchScore handling, error recovery |
rules/flow-context-inject.md
| HIGH | 3-layer injection strategy, context window management, chip switching protocol |
rules/api-chip-identify.md
| HIGH | chip_identify interface: fuzzy matching, alias recognition, response format |
| HIGH | chip_trm interface: section filtering, Register/RegisterField data format |
| MEDIUM | chip_specs interface: 4 category queries, electrical specs with limits |
rules/api-chip-hardware.md
| HIGH | chip_hardware interface: pin/function filtering, AF mapping, package info |
rules/api-chip-programming.md
| MEDIUM | chip_programming_guide: SDK/HAL code, init sequences, dual implementations |
Section index: See
for loading order and strategy.
Full Compiled Document
For platforms that prefer a single file with all rules, see
— a compiled version of all rule files in this Skill.