5.1. AI Agents

AI-powered assistants and agents are rapidly becoming indispensable for developers - providing suggestions and automated features that help in writing code more efficiently and accurately. AI functionality is available with CCStudio™ for VS Code using functionality bundled with the extension, as well as numerous third-party AI code assist extensions available on VS Code Marketplace. CCStudio for VS Code also offers MCP (Model Context Protocol) servers that enable AI assistants to interact directly with CCStudio's debug backend and SysConfig, allowing for more integrated and context-aware development workflows.

Caution

AI assistants are designed to assist developers by providing suggestions and automating certain tasks. However, they are not perfect and may occasionally provide incorrect or suboptimal suggestions. It is important for developers to critically evaluate the suggestions provided by AI assistants and use their own judgment when deciding whether to accept or modify those suggestions.

In addition to code suggestions, an agent can use CCStudio to import and build projects using command-line build commands documented in its guidance files, configure devices with SysConfig, and load and debug programs on a target.

This is done through the following CCStudio components, which are described in this chapter:

• MCP servers that expose debug and SysConfig functionality to the agent.

• Guidance files that give the agent CCStudio workflows, command-line build instructions, and TI device, board and SDK information.

• Skills for specific tasks, such as migrating a project to a TI device.

CCStudio for VS Code does not include an AI agent or model. You select the agent and model provider to use.

Caution

AI agents can make mistakes. Review the changes an agent makes, particularly when it runs code on hardware or changes project settings.

5.2. How the AI Integration Works

The integration is built on open standards so that you can use the agent and model you prefer, and so that the integration keeps working as the AI landscape changes. CCStudio for VS Code does not include or require a specific model. You bring your own agent, and CCStudio provides what that agent needs to be effective on TI devices.

The integration has four parts:

Part	What it is	What it gives the agent
AI agent	A coding agent such as Claude Code or Codex, running as an extension.	The conversation, reasoning and planning.
MCP servers	Programs, started by CCStudio, that expose debug and SysConfig functionality as tools using the Model Context Protocol (MCP).	The ability to act: configure and debug the target.
Guidance files	A central guide plus guidance files for SDKs and boards.	The knowledge to act correctly: workflows, rules, pin assignments, device specifics.
Skills	Packaged, multi-step workflows for common TI tasks.	Reliable procedures for tasks such as migrating a project or measuring code coverage.

5.2.1. What happens when you enable the integration

When you configure an AI assistant, CCStudio for VS Code performs the following steps for you:

1. Installs the agent. The extension for the agent you selected is installed if it is not already present.

2. Registers the MCP servers. The agent's configuration is updated so that it can start and use the CCStudio MCP servers.

3. Configures the agent. The agent's instruction file (for example CLAUDE.md or AGENTS.md) is updated to direct the agent to read the CCStudio central guide before it starts any TI-related task.

4. Makes skills available. TI-provided skills are made available to the agent.

5. Sets up access to your model. You supply the model provider settings and credentials.

These steps are performed by the AI Agent Configurations. If you select the Other agent option, the configurator instead generates the same CCStudio skills, instructions, and MCP settings files into a generic resources folder, so that you can configure an agent of your choice on your own.

5.2.2. Your choice of agent and model

• Industry-standard agents. Claude Code, Codex, and Copilot are supported out of the box. Other agents that support MCP can use the CCStudio MCP servers with manual configuration (see Using other AI Agents).

• Your model provider. Use your own subscription or API key, or a provider approved by your organization.

• Data stays under your control. The MCP servers run on your machine and communicate with your agent locally. Organizations that must keep data inside their network can use a locally hosted or on-premises model. (See Data Privacy and Information Handling.)

5.2.3. Why tool access matters

Done correctly the first time with SysConfig. Hand-writing device configuration code is error-prone and often takes several failed attempts. Through the SysConfig MCP server, the agent can see exactly what can be configured, the valid values for each setting, and any errors or conflicts as soon as it makes a change. It corrects problems immediately, and the result is a validated configuration rather than a guess.

Verifying its own work with debug access. With access to the debugger, an agent can load the program on a board, run it, stop at breakpoints, and inspect variables, registers and memory. Instead of guessing why something fails and iterating blindly, it can find the root cause from the program's actual runtime state and verify that its fix works.

Good information. Documentation and examples are the ground truth for an agent. CCStudio points the agent to SDK documentation and examples, and to TI-authored board and SDK guidance, so that it produces correct results faster and with less back-and-forth.

5.3. CCStudio MCP Servers

CCStudio provides two MCP servers. Each server exposes a set of tools that the agent can call. You normally do not call these tools yourself: you describe what you want in the chat, and the agent chooses which tools to use.

Project build and import tasks are not exposed through an MCP server. Instead, the agent is given command-line build commands in its guidance files, and uses those directly through its shell/terminal tool.

Server	Name in agent	Purpose
Debug	ms-debug	Run and debug programs on a target
SysConfig	ccstudio-sysconfig	Read, change, validate and save device configuration

Note

The MCP servers are active only while CCStudio for VS Code is running and a workspace configured for AI is open. They are stopped when CCStudio for VS Code is closed or when the integration is disabled.

5.3.1. Debug server (ms-debug)

ms-debug is Microsoft's debug MCP extension for VS Code. CCStudio for VS Code registers it with the agent and connects it to the CCStudio debug backend, giving the agent control of a debug session on real hardware.

Capabilities

• Detect connected boards and debug probes; start, list and end debug sessions.

• Load programs and symbols; reset, run, pause and step (into, over, out).

• Set, list and clear breakpoints.

• Inspect call stacks and local variables; evaluate expressions and registers.

• Read and write target memory.

• Read the console (CIO), debug output and GEL output views.

• Use the profile clock to count cycles and other events.

Example prompts

• "Debug the project, break at main, and tell me the value of counter after ten iterations."

• "The LED never blinks. Find out why."

• "Rebuild, reload and run the updated program."

Note

Only one CCStudio debug session can be active at a time. If more than one board is connected, the agent can use the ti-ccstudio-use-specific-board skill to pin the project to one debug probe.

5.3.2. SysConfig server (ccstudio-sysconfig)

Lets the agent configure a device through SysConfig without editing .syscfg files by hand.

Capabilities

• Open a .syscfg file and list available modules.

• Add and remove module instances; read and change configuration values.

• Report errors and warnings as configuration changes are made.

• Manage connections between module instances and inspect clock-tree configuration.

• Save the configuration and review the generated source files.

• Migrate a configuration to a different device, package or variant.

• Inspect example .syscfg files from an SDK for guidance.

Example prompts

• "Add a UART at 115200 baud on the backchannel pins."

• "Why does my SysConfig file report an error?"

• "Migrate this configuration to a different device in the same family."

Caution

Hand-edited .syscfg files can build successfully and still behave incorrectly on the hardware. The agent is instructed to use only this server to read and change .syscfg files.

5.3.3. Using the MCP servers with other agents

The MCP servers use the standard MCP protocol. If you use an agent other than Claude Code or Codex, see Using other AI Agents for the command line used to start each server.

5.4. Skills

A skill is a packaged set of instructions that teaches an agent how to carry out a specific, repeatable task. Where the MCP servers give the agent individual abilities, skills give it a proven procedure that combines them: which questions to ask, which steps to run in what order, what to check along the way, and when to stop and ask you.

CCStudio includes the following skills.

Skill	Use it to	Section
ti-ccstudio-migrate-to-ti	Migrate an embedded firmware project from another vendor's microcontroller to a TI device. Step 1 of the migration workflow.	Migrating a Project to a TI Device
ti-ccstudio-test-migration	Verify the migrated project on real hardware. Step 2 of the migration workflow.	Testing a Migrated Project on Hardware
ti-ccstudio-clang-code-coverage	Produce a code coverage report for a project built with a TI Clang compiler.	Code Coverage
ti-ccstudio-check-bp-compatibility	Check whether BoosterPack™ plug-in modules can be used with a LaunchPad™ development kit.	BoosterPack Compatibility Check
ti-ccstudio-use-specific-board	Lock a project to one debug probe when several boards are connected.	Using a Specific Board

The agent selects a skill automatically when your request matches the skill's description, or you can request one by name.

Tip

Skills work best when your request includes the key inputs, such as a project path or a part number. If an input is missing, the skill asks for it.

5.4.1. Migrating a Project to a TI Device

Moving an existing firmware project to a new microcontroller is a large task. The peripherals are different, the driver APIs are different, and the pin assignments, clocks, interrupts and memory map all have to be redone. The migration workflow breaks this into two skills that you run in order:

1. ti-ccstudio-migrate-to-ti analyzes your project, writes a migration plan for your approval, then creates a new CCStudio project for the TI device, configures it, ports the code and builds it.

2. ti-ccstudio-test-migration then helps you verify the result on a real board. It is described in Testing a Migrated Project on Hardware.

The result of the migration skill is a project that builds. It is a starting point that you review and test, not a finished product. The test-migration skill exists because a successful build says nothing about whether the ported code behaves correctly on hardware.

5.4.1.1. You own the migration

The migration skill is an assistant. It does the repetitive work and proposes a result, but you own the process and the outcome. The skill reminds you of this in three places: in a notice shown when it starts, in the plan approval step, and in a banner at the top of the generated migration-report.md.

The notice shown when the skill starts says, in summary:

Note

Migration Assistant - The assistant helps you migrate this project to a TI device. It is used as part of an AI-assisted process. TI does not access, collect, or store any input or output of this process. Your prompts, data, and results stay in your own environment and with whatever AI model you choose to use. You retain full ownership of your code. Any libraries or components remain subject to their original licenses. The tool is provided as is, and results will not always be correct or complete. It is up to you to review and confirm that any output is accurate, complete, secure, and right for your needs before you use or rely on it.

In practice, this means:

• You make the decisions. The skill asks you to choose the board, package and variant, and to approve the plan before anything is created. You can change the plan, or stop, at that point.

• You review the result. A project that builds is not a correct project. Review the ported code and the migration report.

• You verify the details the skill cannot. Confirm pin assignments against the target board schematic. Verify clock and baud-rate calculations. Treat the SDK documentation as the authoritative reference for API usage.

• You test on hardware. Test the ported code on a board. The test-migration skill helps with this (see Testing a Migrated Project on Hardware), but you still decide when the result is good enough.

• You are responsible for licenses. Libraries and components remain under their original licenses. The skill detects licenses from file headers, which is not a legal review, so check the license notes in the report before you distribute the result.

Caution

AI-generated code can be wrong in ways that are not obvious and that still compile. Do not use a migrated project in a product until you have reviewed it and tested it on hardware.

5.4.1.2. Before you start

• Install the TI SDK for the target device. The skill locates the installed SDK. If the SDK is not installed, the skill installs it as part of project creation.

• Have the source project in a folder on your computer. The skill only reads it. It never modifies, moves or deletes anything in the source folder.

• Know your target part number, for example MSPM0G3507. If you use a TI LaunchPad, the skill can also select the board.

• Open an empty workspace folder for the migration. The skill saves its plan next to where it runs and creates the new project there.

5.4.1.3. How the migration works

The skill is an orchestrator. It does not do the work in one long conversation. Instead it runs a series of specialized sub-agents one after another, each starting with a clean context and a narrow job. This keeps each step focused and avoids the quality loss that happens when one agent holds a very large amount of code, documentation and history at once. The state that carries from step to step lives in two files in your workspace, not in the agent's memory.

Phase	What happens	Result
Start	The skill shows a notice and asks for any missing inputs: the source project path and the target part number.	Inputs
Resolve the target	Finds the installed SDK for the part, and asks you to choose when there is more than one option: which device variant, which LaunchPad (or a bare device or custom board), and which package.	SDK, board, package
Analyze the source	Inspects the source project: the family and part, build system, peripherals and pins in use, middleware, memory use, source licenses, and which files to copy. It reads files by pattern and does not need a complete understanding of every file.	Source summary
Plan	Compares the source against the TI device and SDK using TI's migration guides. Writes migration-plan.md. You review and approve it.	migration-plan.md
Execute the plan	Runs the plan step by step (see below).	New project, migration-report.md
Report and hand off	Marks the project as built but not yet tested on hardware, and points you to the report and the test skill.	Report

5.4.1.3.1. The plan and your approval

The planner produces migration-plan.md in the workspace folder and prints its assessment. The assessment is a set of flags to help you decide, not a pass or fail gate. It covers:

• How the source peripherals map to the TI device's peripherals, and anything that has no direct equivalent.

• Whether the program fits in the target's flash and RAM.

• Behavioral differences that matter, such as different interrupt, low-power, or timing behavior.

• Pin compatibility between the source and the chosen TI package, with a pin translation table.

• Source files that carry a license that requires special handling (see Licenses below).

• Known risk areas, listed as named items.

The plan also lists the work in order: one step to create the project, then for each area (a peripheral group such as GPIO, UART, SPI or the core/clock setup) a configure step followed by a port step, and a final build step. You can see exactly what will happen before it does.

You are then asked to choose one of:

• Yes, proceed. Create the TI project and start porting.

• Tweak the plan. Describe what to change, for example drop an area, choose a different package or device, or reorder steps. The plan is regenerated and presented again. You can also edit migration-plan.md directly, for example to rename the new project. Nothing is created until you proceed.

• Abort. Stop and keep the plan for later.

5.4.1.3.2. Executing the plan

For each step in the plan, a sub-agent does the following.

1. Create the project. Imports a suitable SDK example project into the workspace as the foundation. For most migrations, this is the minimal ("empty") example for the board. When the application's behavior must be reproduced rather than edited (see Edit mode and regenerate mode below), the closest functional example is used instead. The agent then copies your source files into the new project, and creates migration-report.md inside it.

2. Configure each area. Configures the TI device for that peripheral group.

   • For projects configured with SysConfig, the agent uses the SysConfig MCP server to add and set up the modules (for example a UART at the baud rate your source used), checks for errors, and saves the .syscfg file so that the configuration source files are generated.

   • For projects that use devicetree and Kconfig (Zephyr), the agent edits the devicetree overlay and prj.conf files instead.

3. Port each area. Updates your source code for that area to use the TI SDK APIs, using the configuration generated in the previous step and TI's peripheral-by-peripheral migration guides.

4. Build and fix. After all areas are ported, one agent builds the project and works through compile and link errors until it builds, applying fixes and rebuilding as needed. Real migrations often need several rounds of fixes, which is normal.

Each step is recorded as it completes. At the end of each area and each build, the agent summarizes what it did.

5.4.1.3.2.1. Edit mode and regenerate mode

Where the source and target are similar in shape (for example, one bare-metal driver model to another), the skill edits your code in place, replacing the vendor-specific calls with TI equivalents. Where they are structured differently (for example, a project built on one RTOS and its devicetree-bound drivers moving to another RTOS), line-by-line editing is not possible. In that case the skill regenerates each area by adapting a TI SDK example to reproduce the behavior of your code. It keeps your original code wherever it can, such as helper functions, protocol logic and constants, and rewrites only the parts that depend on the original RTOS or driver model. If keeping the code and keeping the behavior conflict, behavior takes priority. The planner chooses the mode and records it in the plan.

5.4.1.3.2.2. Licenses

Your source project may include third-party code with its own license. The migration looks at the license header of each file and handles it as follows. Detection is based on header patterns. It is not a legal review.

• Permissive license. The file is migrated normally.

• Restrictive license on library code. The file is not copied or read. The skill instead reconstructs the affected peripheral behavior from TI's SDK documentation only, a "clean-room" approach, and says so in the plan. If the documentation alone does not give enough information, the skill asks you to describe in your own words what the excluded file does. Only your description is used. The agent never reads the original file.

• Restrictive license on example or application code. The file is ported and built so that you can see the application work on the TI device, but it is flagged as something you must rewrite before distributing or using in production.

5.4.1.3.3. Resuming

The migration can span more than one session, and you can stop at any time.

• The plan is the intent. The report's Migration Checklist records what has been done. Each step is ticked when it finishes.

• If you start the skill again in the same workspace, it detects the existing plan and asks whether to Resume from the first unfinished step, Start over (deletes the plan and report and plans a fresh migration), or Abort.

• The steps are safe to repeat. Re-running a partially completed step reuses the project, configuration and files that already exist.

• If a step fails, the skill reports what went wrong. It retries when it can fix the cause, such as re-dispatching after a transient failure, and otherwise stops and leaves the files on disk so you can resume.

5.4.1.3.4. What you get

Item	Where	Contents
New CCStudio project	Workspace folder	The TI project that builds with the ported code, with its SysConfig file (or devicetree overlay and prj.conf).
migration-plan.md	Workspace folder	The assessment, the project and SDK details, the memory comparison, the pin translation, and the ordered steps.
migration-report.md	Inside the new project	The record of what was done: project details, peripheral summary, the SysConfig configuration, pin assignments, API mappings, code porting notes, license notes, unsupported features, and the checklist.

Note

The report begins with an AI-Assisted Migration banner that repeats the notice shown when the skill started: the report was generated by an AI assistant, you retain ownership of your code, and you are responsible for reviewing and confirming the result before relying on it.

Open migration-report.md before relying on the port. In particular, review License Notes (files with non-permissive or unknown license terms), and under Code Porting Notes the items marked as clean-room regeneration (reconstructed from documentation and not verified against the original) and those marked "rewrite required before distribution".

When the build succeeds, the skill sets the report status to Build verified - hardware testing pending. It leaves the Tested on hardware checklist item unticked. That item is ticked by the test skill.

5.4.1.3.5. Example

1. Open an empty workspace folder in CCStudio for VS Code.

2. Ask the agent: "Migrate the project in C:\work\blinky to MSPM0G3507."

3. Read the disclaimer. Answer any questions about board and package.

4. Review the assessment and the plan. Choose Yes, proceed.

5. When the build completes, review migration-report.md.

6. Start a fresh conversation (for example with /clear in Claude Code) and run the test-migration skill.

Tip

Starting a fresh conversation before testing keeps the migration's context from crowding out the hardware-testing work.

5.4.2. Testing a Migrated Project on Hardware

ti-ccstudio-test-migration is the second half of the migration workflow. A migrated project that builds has not been shown to work. Pins may be assigned differently, timing may differ, and the behavior of the ported drivers may not match the original. This skill helps you test the migrated project on a real board, tailored to the equipment you have, and records the results.

Run it in the same workspace as the migration, after ti-ccstudio-migrate-to-ti has finished, because it reads migration-plan.md and migration-report.md to learn what was migrated. It does not perform the migration itself.

Note

As with the migration, the testing skill is an assistant and you stay in charge. The test report begins with an AI-Assisted Testing banner that tells you to verify all pass and fail results, and any fixes the skill applied, against the target hardware before relying on the migration in production. You confirm each wiring step, and you decide whether to accept a failed or skipped test.

Caution

Hardware can be damaged by incorrect wiring. Reversed polarity, a signal pin connected to a supply rail, or mismatched voltage levels can destroy a board. The skill displays this warning when it starts, and pauses for you to confirm every physical connection before any test runs. Check each connection against your board schematic.

5.4.2.1. How the testing works

Phase	What happens	Result
Detect	Checks for an unfinished test session in the workspace and offers to resume it.
Notice and context	Shows the hardware warning and reads the compact project details from the migration report.
Mode and resources	Detects the connected board and debug probe, and asks how you want to test (see below).	Inputs
Profile the instrument	If you use a bench instrument, researches how to control it and saves a profile. Skipped otherwise.	Instrument profile
Plan	Writes the test plan. You review and approve it.	migration-test-plan.md
Generate a framework	Optional. Creates a standalone, runnable test project from the plan.	Test project
Run the tests	Runs each test in order, fixing and rebuilding when a test fails.	migration-test-report.md
Finalize	Records the outcome and updates the migration report.	Final status

5.4.2.1.1. Choose a testing mode

The skill asks what you want help with.

• I have existing tests. You tell the skill how to run your tests (the command, the working directory and what counts as pass or fail). It builds a plan around them, runs them, and helps you debug and fix failures.

• Help me create a test plan. You do not have tests yet. The skill builds a test plan from what was migrated, such as one test per migrated peripheral area, and can generate a test framework for it.

In the second mode, you also say what test resources you have:

Resource	What the skill can do with it
JTAG access	Load and run the program, halt it, and read variables and memory with the debug server.
Bench instrument	Drive and measure real signals with an oscilloscope, logic analyzer or signal generator. The Digilent Analog Discovery 3 is supported with built-in knowledge, and a USB logic analyzer such as the Saleae Logic can be named. Other instruments can be named too, and the skill researches how to control them.

Only one bench instrument can be used per run.

5.4.2.1.2. The test plan and your approval

The plan, migration-test-plan.md, is saved inside the new project. It contains the test strategy, the ordered list of test cases, and, when you have no existing tests, a Fixed Wiring Setup. This section lists every connection to make once for the whole session (for example, jumper wires between two pins for a loopback test, or which instrument channel connects to which pin). The plan also states an estimated target I/O voltage, and shows where the estimate came from, so that you can check it against the board before any signal is driven.

Each test case is marked as one of:

• Automatic. The skill can run it and judge the result by itself.

• Stub. The test is described but cannot be automated yet. The skill records it as a stub and continues.

• Cases that need you to do something physical list their steps, and the skill prompts you for them.

You then choose what to do with the plan.

• With existing tests: Proceed, Tweak the plan, or Abort.

• When creating tests: Generate a test framework, Tweak the plan, or Stop here. If you stop, the plan on disk is a checklist you can follow yourself, and you can run the skill again later to pick it back up.

5.4.2.1.3. Generating a test framework

If you choose to generate a framework, the skill asks which language and test framework to use. JavaScript with Mocha is the default recommendation, and Python with pytest is also offered. You can name another. The skill creates a standalone test project, including a README with the command to run it. If the framework or the instrument needs software that is not installed, the skill lists what is missing and how it would be installed, then asks you to choose: install it for you, install it yourself, or continue without instrument automation. It installs nothing without your permission.

Because the generated project stands alone, you can re-run the tests yourself later, with no AI agent present, for example before each release.

5.4.2.1.4. Running the tests

Before the first test runs, the skill prints the Fixed Wiring Setup and asks you to make the connections and confirm. Once you confirm, all tests in the session then run without further wiring prompts. If you resume in a later session, it asks again, because the physical setup may have changed.

The skill then runs the tests in order, and for each test it:

1. Loads and runs the program on the target as needed.

2. Observes the result through the debugger, the serial port, or the instrument.

3. If a test fails, investigates, applies a fix to the migrated code, rebuilds, and tries again.

4. Ticks the test in the Test Checklist in migration-test-report.md when it passes.

Some fixes are deferred rather than applied automatically, such as reassigning a pin. When that happens the skill explains the recommendation and asks whether to apply the fix, skip the test, or accept the result as is. If an instrument is not available (not connected, runtime not installed, or in use by another program), you are asked to fix the problem and retry, or skip the test.

5.4.2.1.5. Finalizing

When all tests have passed, or you accept the remaining results, the skill:

• Sets the test report status to Complete.

• Ticks Tested on hardware in migration-report.md and updates its status, but only if at least one test actually passed on hardware.

• Prints a summary of how many tests passed, how many failures you accepted, and how many fixes it applied.

• If it changed any code during testing, lists the changes and recommends that you re-test everything.

Test progress is saved as it goes. If the session ends part way, run the skill again in the same workspace to resume from the first unfinished test.

Note

Some targets have limited debug automation. For example, projects built on devicetree and Kconfig may use fewer of the automatic debugger-based tests. The skill sets its expectations from the project it finds.

5.4.3. Code Coverage

ti-ccstudio-clang-code-coverage generates a code coverage or profiling report for a project built with the TI Arm Clang or TI C29 Clang compiler. It shows which lines, functions and branches of your program ran while the program ran on the target. It is useful for measuring how much of your code a test run exercised, and for finding code that never runs.

The skill automates a flow that is otherwise manual: the compiler is instrumented to count execution, the counters are read back from the target's memory, and the compiler tools convert them to a report.

What it does

1. Adds the coverage options. Adds the compiler options for instrumentation to every build configuration. You can also choose optional modes: MC/DC (modified condition/decision coverage) for safety-oriented analysis, function-level coverage only (less overhead), or smaller 32-bit counters (less target memory).

2. Rebuilds the project fully, so that every file is instrumented, and checks that the options were applied.

3. Runs the program on the target. The skill starts a debug session and runs the application. You decide how long it runs, so that you can exercise the code paths you want to measure, and tell the skill when to stop.

4. Reads the counters from the halted target. The skill reads the counter memory while the debug session is still open, because ending the session can let the processor run briefly and skew the counts. It then saves the data to a file.

5. Generates the report. The compiler's profile and coverage tools convert the data into an HTML report that you can open in a browser. The report is branded, and is placed in a coverage_report folder next to the program. Several runs can be merged into one report.

6. Offers to remove the coverage options. If you accept, the options are removed from every configuration, and the project is rebuilt and checked, so that the code you ship is not instrumented.

Requirements: a project that uses the TI Arm Clang or TI C29 Clang compiler, and a board that can be debugged from CCStudio for VS Code.

Note

Instrumented code is larger and slower. The instrumented build needs extra flash and RAM for the counters. Do not ship an instrumented build.

Example prompt: "Generate a code coverage report for my project. I will tell you when I have finished exercising the program."

5.4.4. BoosterPack Compatibility Check

ti-ccstudio-check-bp-compatibility checks whether one or more BoosterPack plug-in modules can be used with a LaunchPad development kit. It compares the pin assignments of the LaunchPad with those of each BoosterPack, and reports where they clash. Use it when choosing a BoosterPack for a LaunchPad, or when you want to stack more than one.

The skill uses the board guidance files that CCStudio provides (see Board and SDK Knowledge) and does not change any file.

What it does

1. Finds the board data for the LaunchPad and each BoosterPack. A board without data is marked as unknown, and the check continues with the boards it has.

2. Asks which LaunchPad signals you do not need, such as the backchannel UART, the debug (SWD) pins, the LEDs or the buttons, so that it can leave out warnings about pins you will not use.

3. Compares each connected BoosterPack pin with the LaunchPad function on the same pin.

4. Compares the BoosterPacks with each other when you give more than one.

5. Reports the result.

How results are classified

Result	Meaning
Conflict	The pins cannot be used together as they are. For example, the BoosterPack uses a pin that is hard-wired on the LaunchPad to an LED, button, or flash chip, or two stacked BoosterPacks use the same pin for different functions. Where the LaunchPad documentation mentions a resistor or jumper that can free the pin, the report includes the hint.
Warning	The pin can probably be used, but check it. Examples are a pin that the LaunchPad also routes to the backchannel UART or debug pins, a general-purpose pin the LaunchPad could repurpose, and two BoosterPacks sharing a bus such as SPI, which may be intentional.
Unknown	The skill could not determine the function of a pin from the guidance file, so it does not guess.
Compatible	No problem was found.

Example prompt: "Is the BOOSTXL-EDUMKII compatible with the LP-EM-CC1314R10?"

Note

The check is as good as the board guidance it reads. Treat the result as a way to find problems early, then confirm against the board schematics before you build hardware.

5.4.5. Using a Specific Board

ti-ccstudio-use-specific-board configures a project to always use one particular debug probe. When several boards are connected at once, the debugger cannot tell which board a project should use, and debugging or flashing fails with a probe-selection error. This skill fixes that by saving the probe's serial number in the project's target configuration (.ccxml file). It does not change anything on the board.

What it does

1. Finds the target configuration in the project, and the device it is for.

2. Lists the connected debug probes and picks out those that match the project's device.

3. Decides what to do based on what is connected:

   • No matching board connected: offers to save a serial number you type, for example before the hardware arrives.

   • One probe connected: explains that selecting a probe is optional, and asks whether to configure it anyway for when you add more boards.

   • One matching board among several probes: configures the project for that board.

   • More than one matching board: shows the serial numbers and asks you to choose. It never picks one for you.

4. Writes the serial number into the target configuration, replacing any previous setting.

5. Verifies the file and reports the file that changed and the serial number that was set.

After this, every debug session and flash for the project uses that probe. Run the skill again with a different serial number to change it.

Example prompt: "I have two LaunchPads connected. Make this project always use the one with serial number L40001BC."

5.5. Board and SDK Knowledge

Agents produce much better results when they know the specifics of your hardware. CCStudio provides this knowledge in three kinds of files that the agent reads automatically:

• Central guide. Describes how the agent should work with CCStudio: the workflow for modifying or creating projects, the rules for using each MCP server, and rules such as never changing SDK content. The agent is directed to read this file before any TI-related task.

• SDK guidance (AGENTS.md). For supported SDKs, describes the SDK's structure, drivers, examples and conventions, with optional supplemental guides for peripherals and software stacks.

• Board guidance (AGENTS.md). For TI LaunchPad and BoosterPack boards and other evaluation modules, describes the pin assignments, the UART backchannel, LEDs, buttons, onboard sensors and jumper settings.

When you say "my LaunchPad" or name a specific board, the agent uses this information to select the right pins and settings rather than relying on general knowledge that may be wrong for that board.

Note

These files are installed with CCStudio for VS Code under its AI resources folder and are updated with CCStudio for VS Code. They are read-only reference material for the agent.

5.6. AI Agent Configurations

The AI Agent Configurations view can be opened with the Set up AI option described in the vsc-getting-started section. If no AI agent has been configured, there will be an option to Configure one.

The user will then be presented options to configure for Claude Code, Codex, Copilot, and Other. The Other option generates the same skills, instructions and MCP settings files that are used for the supported agents, but places them in a generic ti-ccstudio-ai-resources folder in your workspace instead of wiring them into a specific agent. You then manually copy or point your agent of choice at the files it needs from that folder.

Once an agent has been selected, an API configuration dialogue will appear. If the selected agent has already been configured on the system, the corresponding configurations settings may appear automatically.

If the selected agent has already been correctly configured on the system or an alternative authentication method (such as OAuth-based authentication) will be used, the Provide configuration details checkbox can be disabled and the rest of this section can be skipped.

Otherwise, select the scope. You can choose to apply the settings to the current workspace (Workspace) or to your entire system (Global). The settings file path will be automatically populated based on the selected scope. If you select Workspace, the settings will be saved in a file within your current workspace. If you select Global, the settings will be saved in a global configuration file that applies to all workspaces. Any existing configuration file will be automatically detected and loaded when the relevant scope is selected. If no existing configuration file is found, a new one will be created when you apply your settings.

Warning

Any settings stored in the Workspace will always override any settings stored in the Global configuration file. This allows you to have different configurations for different workspaces, while still maintaining a global default configuration that can be used when a workspace-specific configuration is not available. Even if the AI Agents Configurations view is used to configure settings at the Global level, any workspace that has settings configured at the Workspace level will override the global settings when that workspace is active.

The below parameters are used to connect to the provider's services and configure the AI assistant:

• API provider: The provider selected will vary depending on the agent selected.

• Auth token / API Key: Enter the token/key for the selected provider to authenticate your access to the AI model.

• Base URL: Provide the base URL for the API endpoint of the selected provider.

• Model: Choose the specific AI model you want to use

• Custom headers / HTTP Headers: If the provider requires any custom headers for API requests, you can add them here.

If you have already configured your model for this agent and provider in the past, this information will be automatically populated with the relevant information for the selected scope. If you have an existing subscription with the provider and wish to use those credentials, the above connection parameters can often be left blank.

Note

Depending on your environment, not all of these parameters may be applicable/needed. Please refer to the provider's documentation and/or your local IT department for instructions.

Press Finish to complete the configuration. If the agent extension needs to be downloaded, it will be done automatically.

Once the configuration is complete, additional tabs should appear for the AI Agent Configurations view:

• General: View the status of the installed AI agent extension and use the Open Chat button to open it. There is also an option to enable/disable CCStudio AI, view the agent instructions, and view permissions of tools and folders.

• MCP Servers: Configure the status of MCP Servers. There is also an option to add additional ones.

• Skills: Lists the available skills.

• API Configuration: Review the settings for the API configuration and apply new settings.

5.6.1. Example: Debugging With Claude Code

The configured AI assistant can use CCStudio-aware tools to interact with your project. For example, asking the assistant to debug a project can result in it inspecting the workspace, setting breakpoints, and starting a debug session on your behalf:

Caution

AI assistants are designed to assist developers by providing suggestions and automating certain tasks. However, they are not perfect and may occasionally provide incorrect or suboptimal suggestions. It is important for developers to critically evaluate the suggestions provided by AI assistants and use their own judgment when deciding whether to accept or modify those suggestions.

5.7. Agent Configuration Files

When Claude Code, Codex, or Copilot is configured and CCStudio AI is enabled, a configuration file (CLAUDE.md for Claude Code or AGENTS.md for Codex and Copilot) in the workspace directory to provide context and guidelines for the AI agent. These files are always read by the respective agents at the start of each session to understand the workspace context and constraints.

5.7.1. File Structure

Both configuration files follow the same structure:

• Auto-populated content (between "TI-CCSTUDIO-INSTRUCTIONS" comments): This section is automatically Managed by CCStudio. Edits between these markers will be overwritten. The auto-populated content provides CCStudio-specific context such as installation directories, device-specific information, and mandatory requirements for interacting with CCStudio. This ensures the agent has the most current and accurate CCStudio-specific information available.

• User instructions section (below "END TI-CCSTUDIO-INSTRUCTIONS" comment): Any custom content you add in this section will be preserved, allowing you to maintain persistent instructions and guidelines for how the agent should behave within your workspace. This allows you to customize agent behavior on a per-workspace basis by adding your own instructions, preferences, and guidelines.

Warning

Any custom content placed between the "TI-CCSTUDIO-INSTRUCTIONS" comment markers will be automatically overwritten by CCStudio. To ensure your custom instructions and guidelines are preserved, always add them below the "END TI-CCSTUDIO-INSTRUCTIONS" comment. Only content in this section will persist across sessions.

5.7.2. Example Content

Below is an example of the structure and content that appears in these configuration files:

<!-- BEGIN TI-CCSTUDIO-INSTRUCTIONS -->
<!-- Managed by CCStudio. Edits between these markers will be overwritten; add your own instructions below the END marker. -->
## CCStudio for VS Code Folders

Remember for the session (needed by scripts and tools):
- `{ccs-resources-ai-dir}` = `C:/Users/user/AppData/Local/Texas Instruments/CCSVSC/resources/ai_1_3_0` (AI resources)
- `{ccs-resources-nodejs-dir}` = `C:/Users/user/AppData/Local/Texas Instruments/CCSVSC/resources/nodejs_24_21_0` (Node.js)
- `{ccs-resources-debug-dir}` = `C:/Users/user/AppData/Local/Texas Instruments/CCSVSC/resources/debug_1_0_0` (debug tools: GDB, LLDB, OpenOCD)
- `{ccs-extensions-project-dir}` = `c:/Users/user/.vscode-insiders/extensions/ti-development-tools.ccstudio-project-1.0.0` (project extension)
- `{ccs-extensions-targetlink-dir}` = `c:/Users/user/.vscode-insiders/extensions/ti-development-tools.ccstudio-targetlink-1.0.3-win32-x64` (targetlink extension)

## MANDATORY Pre-Task Requirement (DO NOT SKIP)

**CRITICAL - NO EXCEPTIONS**: Before ANY CCStudio/Texas Instruments-related task (even simple ones), you MUST load the central guide at `{ccs-resources-ai-dir}/CCS.md`. It explains how to interact with CCStudio for VS Code and has device-specific information.

Do NOT call any MCP tools until the central guide has been read.
<!-- END TI-CCSTUDIO-INSTRUCTIONS -->

5.8. Using other AI Agents

While Claude Code, Codex, and Copilot are the only AI assistants fully supported for use within CCStudio for VS Code, it is possible to use other AI assistants that are available as extensions on the VS Code Marketplace. To use a different AI assistant, you will need to install the relevant extension and configure it according to the instructions provided by the extension developer. Once the extension is installed and configured, you can use it within CCStudio for VS Code to assist with your coding tasks. Please refer to the documentation for the specific AI assistant extension you are using for more information.

Caution

Only Claude Code, Codex, and Copilot are fully supported out of the box with CCStudio for VS Code. While other AI assistants may work to some extent, they will not have the same level of integration or functionality as Claude Code, Codex, and Copilot when used with CCStudio for VS Code. Use at your own discretion when using other AI assistants with CCStudio for VS Code, and be aware that you may encounter issues or limitations when using assistants that are not fully supported.

5.8.1. Generated resources for the Other option

Selecting Other in the AI Agent Configurations generates the same skills, instructions and MCP settings files used to configure Claude Code, Codex, and Copilot, but places them in a generic ti-ccstudio-ai-resources folder in your workspace instead of wiring them directly into one of those agents.

The folder is not tailored to any particular agent, so you still need to get its contents into the form and location your agent expects, for example an AGENTS.md file in the workspace root, and MCP server entries in that agent's own settings file.

Tip

Rather than doing this by hand, point your agent at the ti-ccstudio-ai-resources folder and ask it to copy, move or rename the files as needed to match its own configuration conventions. Most coding agents can read their own documentation and adapt the generated instructions, skills and MCP settings accordingly.

5.9. Data Privacy and Information Handling

When using an AI assistant with CCStudio for VS Code, it is important to understand how your code and data are processed and transmitted. This section explains the data flow and privacy considerations for AI-powered development workflows.

5.9.1. Local Processing

When you interact with an AI assistant in CCStudio for VS Code, the assistant runs locally within your editor instance on your machine. Texas Instruments infrastructure does not process your code, queries, or project information. The MCP (Model Context Protocol) servers that enable AI assistants to interact with CCStudio also run locally on your machine and are only active when CCStudio for VS Code is running.

5.9.2. Communication with Third-Party AI Providers

When you send a query to an AI assistant, the query and any code context you include are sent directly to the third-party AI model provider (such as Anthropic, OpenAI, or other configured providers). Texas Instruments does not act as an intermediary and has no involvement in these communications.

The specific information sent to the third-party provider depends on:

• The question or request you submit to the AI assistant

• Any code snippets, file contents, or project files you explicitly include or reference in your conversation

• Context provided through MCP servers if you have enabled that functionality (such as project structure, build information, or debug session details)

• Your conversation history (if retained by the AI assistant extension)

5.9.3. Third-Party Data Handling and Privacy Policies

How third-party AI model providers handle your data, including data retention, usage for model training, and other processing, is governed by their own privacy policies and terms of service. Texas Instruments does not control or determine how these providers handle your information.

For details on data handling practices, please refer to the privacy documentation provided by your configured AI model provider:

• Anthropic (Claude Code): Visit Anthropic's privacy resources for information about how Anthropic handles data, conversations, and model usage.

• OpenAI (Codex): Visit OpenAI's privacy policy and security documentation for information about their data handling practices.

• Other Providers: Refer to the privacy documentation and terms of service provided by the specific provider or proxy service you have configured (such as LiteLLM or OpenRouter).

5.9.4. Locally Hosted Models

If you configure CCStudio for VS Code to use a locally hosted AI model (such as through a proxy service like LiteLLM pointing to a local deployment), your queries and code context remain on your local network and are not sent to external third-party providers. This configuration option provides enhanced data privacy if your organization has deployed local AI infrastructure.

When using locally hosted models:

• Your code and queries are processed entirely within your organization's network

• No data is transmitted to external cloud-based AI providers

• You maintain complete control over where your data resides

• You are responsible for the security, maintenance, and data handling practices of your local infrastructure

Refer to your organization's IT department or infrastructure documentation for guidance on setting up and using locally hosted AI models with CCStudio for VS Code.

5.9.5. Local Storage and Configuration

Your AI assistant configuration and conversation data are stored locally on your machine:

• API keys and authentication tokens: Stored locally according to your selected scope (workspace-specific or global)

• Conversation history: Retained locally by the AI assistant extension

• MCP server configuration: Stored locally with workspace or global settings

• Configuration files: Stored in your workspace settings or global configuration directory

This local data is not transmitted to Texas Instruments and remains under your control. You are responsible for protecting API keys and credentials, as these grant access to your third-party provider account.

5.10. FAQ

Please refer to the FAQs for answers to common questions and troubleshooting steps related to using AI assistants with CCStudio for VS Code.