C2Prog Highlights

• Fast communication protocol that works reliably with USB-to-RS232 converters.
• Support for point-to-point as well as multidrop networks.
• Smart detection of which Flash sectors must be erased (or manual section selection if desired).
• Automatic 32-bit CRC (Cyclic Redundancy Check) generation and programming (allowing the firmware to verify the flash integrity at MCU bootup).
• Extended hex files that can be encrypted and contain all the settings for programming, including secondary bootloader.
• Command-line and DLL interface, callable by other programs, for example for batch programming.
• JSON-RPC server for controlling C2Prog remotely, for example from Python.
• Agentic interface (MCP server) giving AI assistants access to the C2Prog documentation and to the connected hardware.
• GDB server with a Lua scripting client, for reading and controlling a target from a script, a CI job or an AI assistant.
• F29x security workflow: key provisioning, signing, firmware encryption and SSU security configurations.
• Flashing of multi-core devices, from Concerto and Delfino to F2838x, F28P65x and F29H85x.
• Command prompt utilities for advanced testing and debugging.
• Support for custom bootloader solutions, enabling
  • touchless reflashing
  • CAN communication

The C2Prog manual documents every command, option and exit code behind these features.

Extended Hex Files

“Extended Hex” (ehx) is the preferred format for distributing binary files for programming with C2Prog. An ehx file contains the data to be programmed (firmware image), combined with all MCU specific settings and auxiliary binaries required by C2Prog. Ehx files may contain an encrypted firmware image and can be password protected, making it the ideal format for distributing programming files, while also avoiding unauthorized use and protecting IP.

Ehx files can be generated from the C2Prog GUI as well as the command line, for example as a final step of the build process.

c2p-cli mkehx --target=28335_30MHz test.out

C2Prog DLL

The C2Prog core functionality is exported via a Dynamic-Link Library (DLL) for use by other applications, such as end-of-line (EOL) test-stands or field support tools. With the C2Prog-DLL, flash programing capability can easily be added to custom applications generated by virtually any toolchain, including NI LabView.

JSON-RPC Server

The C2Prog functionality can also be accessed over TCP/IP via JSON RPC, a lightweight remote procedure call protocol.

c2p-server --rpc-port=8080

This allows automation of the MCU programming, e.g. from a Python script.

import jsonrpc_requests

def main():
    url = "http://127.0.0.1:8080"
    server = jsonrpc_requests.Server(url)
    result = server.load(
        file = "C:/fw/demo.ehx", 
        port = "COM1", 
        passphrase = ""
    )
    while(result["error"] == ""):
        print(result["progress"])
        if(result["info"] != ""):
            print(result["info"])
        if(result["progress"] == 1.0):
            break
        result = server.get_status()
    print("Final: {0}".format(result))
    server.shutdown()

if __name__ == "__main__":
    main()

Agentic Interface

C2Prog includes an MCP server, so an AI assistant running on the same machine can search the C2Prog manual and inspect your setup. Model Context Protocol is an open standard supported by a range of agent hosts, including Claude Code, Codex, Claude Desktop, Cursor, VS Code and Gemini CLI.

Register the server from the C2Prog GUI, under Help > Set up AI agent integration…, or from the command line:

c2p-agent register

See The C2Prog Agentic Interface for what an assistant can do once it is registered.

GDB Server and Scripting

C2Prog includes a GDB server, c2p-gdb-server, and a Lua scripting client, c2p-gdb. The server attaches to a C28x or C29x target through a JTAG debug probe and responds to the GDB Remote Serial Protocol on a TCP port. Memory, registers, breakpoints and watchpoints are therefore reachable from a shell, a build pipeline or an AI assistant, without launching an IDE.

c2p-gdb-server --ccs-base-path=<ccs_base> --non-intrusive 28P650DK9,DK8,DK7,DK6,SK7,SK6_JTAG xds110

With --non-intrusive the server attaches without halting the target, so a variable can be read while the application keeps running. A single call can start the server, run a script and tear it down again, which suits a test on real hardware in a CI job. The GDB tools require no paid license.

See Debugging TI C2000 with the C2Prog GDB Server.

F29x Security: HSM and SSU

On F29x devices (F29H85x), two hardware blocks enforce firmware security, and C2Prog covers the workflow around both. The Hardware Security Module (HSM) decides which firmware the device accepts, and the Safety and Security Unit (SSU) decides what that firmware may reach while it runs.

• Key provisioning. mkkeys generates the Manufacturer keys into a keyset, mkkpcert builds the key-provisioning certificate, and mkehx-kp packages it with TI’s keywriter runtime into one file to program.
• Signing. mkehx-cp generates and signs every certificate a file needs, for the application images, the flash kernel, the HSM runtime and the security configuration. The signing key comes from a keyset, a PEM file or a PKCS#11 token such as a USB HSM.
• Firmware encryption. mkehx-cp --encrypt puts ciphertext in the file, and the device’s HSM decrypts each image during code provisioning.
• Security configurations. A readable .lua profile compiles into the per-CPU seccfg images, or C2Prog takes the blocks TI’s SysConfig placed into the build.
• Review before signing. --explain-only reports what a configuration does, which fields it commits for good, and whether the device can still be reprogrammed over UART and JTAG afterwards.

c2p-cli mkehx-cp --target=29H85xTU9,TU8-CPU1_JTAG --explain-only --seccfg my_seccfg.lua

See the HSM and the F29x security states and F29x access control with the SSU.

CRC Record Generation

If desired, C2Prog can compute a 32-bit checksum and append it to the firmware image as a CRC Record. This checksum can be used to verify the flash integrity, for example at MCU power-up or continuously in the background of the embedded code execution.

The CRC record is delimited by 0x0000 to allow locating the CRC value.

Custom Bootloaders

C2Prog serves as the reflashing client for CodeSkin’s custom bootloaders.

Custom bootloaders provide support for a variety of communication protocols and interfaces. They further allow firmware encryption and reflashing of MCUs that have the security module enabled.

Custom bootloaders enable touchless reflashing, where the application can activate the bootloader without the need for toggling any GPIO pins.