# C2000 Idea > Step-by-step workflows for C2000 code migration tasks. Supports F28x to F28x and F28x to F29x device migration (F29x not yet implemented), bitfield-to-driverlib conversion, and SysConfig ePWM-to-MCPWM peripheral migration — migrate, port, or consolidate an EPWM-based .syscfg project onto a device's MCPWM peripheral, including checking whether several EPWM instances can share one MCPWM instance and reconciling the sync chain / time-base before migrating. Uses the IDEA MCP server as the primary tool, with CCS Project MCP, CCS SysConfig MCP, and TI ASM MCP as supporting dependencies. - Skill: `texasinstruments/c2000-idea` (Agent Skill, multi-file: 27 files) - Install (CLI): `npx skillmds@latest add texasinstruments/c2000-idea` - Raw SKILL.md: https://api.skillmd.com/api/skills/texasinstruments/c2000-idea/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: texasinstruments (https://skillmd.com/u/texasinstruments) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/texasinstruments/c2000-idea --- # C2000 IDEA Migration This skill provides task-specific workflows for migrating C2000 MCU code using the `idea-mcp` MCP server hosted by the C2000-IDEA VS Code extension. It does NOT contain migration facts (symbol changes, register mappings, suggested fixes) — those are produced live by the IDEA MCP tools against the actual project. This skill tells you *how to drive the MCP* for a given migration task; the MCP supplies the analysis. ## Prerequisite These workflows require the IDEA MCP server, CCS Project MCP, CCS SysConfig MCP and (for TRM register lookups) TI ASM MCP to be running. They are hosted by the C2000-IDEA VS Code extension over HTTP. If any required MCP tools are not available in your session, tell the user to enable them (Command Palette → `C2000-IDEA: Enable IDEA MCP` / `Enable TI ASM MCP`, or click **MCP Servers** in the VS Code status bar) and register them with their agent, then retry. **Minimal MCP probe (before any task):** 1. Attempt `get_projects()` as a probe call. - If it succeeds → server is running. Proceed. - If it fails or is unreachable → server is not running. **Stop here.** 2. Tell the user: *"The IDEA MCP server is not running. Please enable it:"* - **Enable:** Command Palette → `C2000-IDEA: Enable IDEA MCP` - **Verify:** Command Palette → `C2000-IDEA: Check IDEA MCP` — shows a status message confirming the server URL (`http://localhost:55001/mcp`) - After enabling, re-register the MCP with their agent tool, then retry the probe call. 3. Do not proceed with any migration step until the probe call succeeds. ## How to use this skill 1. Discover the workspace first. Call `get_projects()` to list the C2000 projects, their current devices, and configured migration targets. If the list is empty or the project you expect is missing, call `get_projects(rescan: true)` once to re-scan the workspace. 2. Look up the migration task in the workflow matrix below. 3. Open the matching reference file and follow its steps. **General rules (apply to all workflows):** - Never fabricate migration data — all symbol replacements and suggested fixes must come from the IDEA MCP or migration collateral URLs, not from memory. - Keep the source project untouched throughout — it is the golden reference. - Confirm with the user before applying bulk changes (same symbol repeated many times). - If any phase MCP call fails and cannot be resolved, stop and ask the user; do not skip the step or guess the outcome. - **Before starting any migration:** Recommend the user to put the project on a git repository and commit all changes and create a clean Git branch (e.g., `migration-to-f28p55x`) so rollback is trivial if needed. After Phase 5, suggest committing with a descriptive message including source/target devices. ## Workflow matrix | Task | Reference file | Primary IDEA MCP tool | | --------------------------------------------- | --------------------------------------------- | --------------------------------------------- | | Device-to-device migration (F28x → F28x/F29x) | references/device-migration.md | get_device_migration_report | | Bitfield → driverlib conversion | references/bitfield-to-driverlib-migration.md | get_bitfield_to_driverlib_migration_report | | SysConfig ePWM → MCPWM peripheral migration | references/epwm-to-mcpwm-sysconfig-migration.md | get_syscfg_module_migration_guide | Notes: - Device-to-device migration moves code from a source device family to a target device family. Two migration paths are supported: - **F28x → F28x** — fully implemented - **F28x → F29x** — not yet implemented - The primary MCP is idea-mcp. Supporting MCPs used during migration: - **ccs-project MCP** — project creation, build, and settings management - **ccs-sysconfig MCP** — SysConfig file analysis and migration - **ti-asm-mcp** — device TRM access for register definitions, bit-field details, and peripheral descriptions; query this when a report issue has no `Suggested fix` or when register-level intent must be verified before constructing a replacement - Bitfield-to-driverlib conversion modernizes legacy bitfield register-structure accesses (`PeriphRegs.REG.bit.FIELD`) into driverlib calls for the *same* device. There is no target device. Run this **before** device-to-device migration when the source uses bitfield patterns — it reduces noise in the device migration report. - SysConfig ePWM → MCPWM peripheral migration ports an EPWM-based `.syscfg` project onto a device's MCPWM peripheral, consolidating EPWM instances onto MCPWM instances (pair capacity varies per instance and is read from the target device's TRM) across confirmed phases. Field mappings come from the `get_syscfg_module_migration_guide` tool (`moduleToModule: "epwm_mcpwm"`); the live `.syscfg` edits use the **ccs-sysconfig MCP**. The supported source/target device set is whatever that tool validates — don't assume it. This is **distinct** from device-to-device migration: that workflow's SysConfig step (Phase 3) uses SysConfig's *same-peripheral* `migrate()`, which would drop EPWM as absent on an MCPWM-only target. Run the ePWM → MCPWM workflow on its own, not inside a device migration. ## Extending this skill Add a row to the workflow matrix and a file under `references/`. Keep each reference procedure-only — describe how to call the IDEA MCP tools and how to process their reports. Do not hardcode migration facts; let the MCP produce all authoritative analysis. Validate every step against the live IDEA MCP before committing.