Transition Applications from C28x to C29x Targets

Migrate applications from C28x targets to C29x targets by updating flash boot configuration, memory usage, peripheral ownership, multicore startup, and deployment workflows. This migration introduces architectural changes, including the use of certified executables, a unified memory model, CPU1-managed boot sequencing, and deployment as a single multicore executable. Use this information to identify which migration changes apply to your existing models and to prepare your software and hardware environment for C29x targets.

The following table summarizes key architectural differences that affect migration decisions.

Compare C28x and C29x Architecture Differences

Feature	C28x	C29x
Data size	16-bit word	8-bit word
Core architecture	C28x core	C29x core
Flash boot	Certified executable not required	Certified executable required
Multicore deployment (SoC builder workflow)	Separate executable per core	Single executable for all cores
Flash access	All CPUs can access flash	CPU2 cannot access flash

Update Third-Party Toolchain

Migrating to C29x targets requires updating the third-party toolchain used for code generation, device support, and executable certification. The required tools differ from those used for C28x targets and reflect architectural and security changes introduced with C29x devices.

Tools for C28x Targets

C28x development relies on the following tools for code generation and device support:

• TI C2000 compiler (COFF and EABI) for code generation

• C2000Ware for device support and peripheral libraries for F2837x device families

• ControlSuite for device support and peripheral libraries for F2802x, F2803x, F2805x, and F280x device families

Tools for C29x Targets

C29x development requires a new set of tools to support updated architecture and secure boot requirements:

• TI C29x Code Generation Tools (CGT) for code generation

• TI C29x Software Development Kit (SDK) for device support and peripheral libraries for F29H85x devices

• OpenSSL version 3.0.18 to generate certificates for certified executables

• Python® version 3.x to support certificate generation workflows

These tools are required to generate, certify, and deploy executables that support flash boot and multicore operation on C29x devices.

Boot from Flash Certification Options for C29x Devices

C29x devices require a certified executable to boot from flash after a power cycle. You can create a certified executable by using a TI-provided dummy certificate or by generating your own certificate. The appropriate approach depends on whether the workflow targets evaluation and development or production deployment.

Use TI-Provided Dummy Certificate

Use this approach for evaluation, algorithm development, and early hardware bring-up.

TI provides a dummy certificate with F29x SDK versions later than 1.00.00. During Hardware Setup for C2000 Microcontroller Blockset, select the Use dummy certificate from C29x SDK option so that the generated executable is appended with the TI-provided certificate.

The dummy certificate is located at:

<F29x SDK Root>\source\dummycert

For example: C:\ti\f29h85x-sdk_1_01_00_00\source\dummycert

This approach generates a certified executable that boots after a power cycle without requiring additional signing tools and is intended for non-production use.

Generate Certificate Using Signing Tools

Use this approach for production workflows that require secure or custom executable signing.

Configure the following tools before generating the certificate:

• Python® version 3.x

• OpenSSL version 3.0.18

The signing key is located at: <F29x SDK Root>\tools\boot\signing

For example: C:\ti\f29h85x-sdk_1_01_00_00\tools\boot\signing.

By default, the mcu_gpkey key is used. During SDK validation, clear Use dummy certificate from C29x SDK to enable certificate generation using the signing tools.

This approach supports secure boot requirements and production-ready deployment workflows.

Update Memory Configuration

C28x and C29x devices use different memory architectures. These differences affect how applications allocate memory, share data across cores, and load executables during startup. Review the changes to determine how to adapt existing memory configurations for C29x targets.

C28x Memory Model

C28x multicore devices use multiple memory categories with explicit ownership and mapping:

• CPU-dedicated RAM, such as M0 and M1

• CPU-mapped RAM, such as Dx memory, configured through the MCUCNF register

• Global shared RAM (GSRAM), owned by CPU subsystems using GSxMSEL registers

• Local shared RAM (LSx), shared between the CPU and CLA through LSxMSEL registers

• Dedicated message RAM for inter-CPU and CPU-to-CLA communication

This model requires explicit configuration to assign memory ownership and control access across processing units.

C29x Memory Model

C29x devices use a unified memory architecture.

• All RAM regions are shared and accessible by all CPUs. Memory is not allocated to a specific CPU, unlike C28x devices.

• C29x devices provide two types of shared RAM:

  • Local shared RAM (LSRAM)

  • Common shared RAM (CSRAM)

• All CPUs can access the entire RAM, but access latency varies by region due to different wait-state configurations.

• Some RAM regions are optimized for data access, while others are optimized for program execution.

The CPU2 application code resides in the CPU1 flash memory and is copied to CPU2 RAM by the CPU1 application during initialization. Direct booting from RAM is not supported, so CPU2 execution always depends on this copy process from CPU1. When running from RAM, the available RAM size limits the maximum supported model size for CPU2 applications.

Update Peripheral Ownership and Sequencing

Peripheral ownership and initialization order differ between C28x and C29x devices.

• On C28x devices, most peripherals are assigned to CPU2 by default, with the exception of GPIO.

• On C29x devices, all peripherals are assigned to CPU1 by default. CPU1 has the highest priority for peripheral ownership. When a peripheral is shared across CPUs, priority is enforced in the order: CPU1, then CPU2, then CPU3.

Update Multicore Boot Sequence

C29x devices use a CPU1-managed boot model. CPU1 controls the boot and initialization of all other CPUs and must always contain a valid executable. CPU2 and CPU3 cannot boot or initialize independently.

During startup, CPU1 boots the remaining cores, coordinates their initialization, and establishes peripheral ownership before completing its own initialization. This sequence ensures a consistent system state and prevents peripheral access conflicts across cores.

The following pseudocode illustrates the required CPU1 boot and initialization sequence:

init_board_CPU1()
{
    statusCPU3 = bootCPU3();   // Boot CPU3 and return status
    statusCPU2 = bootCPU2();   // Boot CPU2 and return status

    if (statusCPU3)
        sendInitCommandToCPU3();  // Trigger CPU3 initialization
    end

    if (statusCPU2)
        sendInitCommandToCPU2();  // Trigger CPU2 initialization
    end

    UpdatePeripheralStructureForCPU1();  // Assign and configure peripherals
    initCPU1();                           // Complete CPU1 initialization
}

CPU2 and CPU3 update their peripheral structures and perform initialization only after receiving initialization commands from CPU1. This dependency ensures that CPU1 establishes system-level configuration before other CPUs begin execution.

Understand SoC Builder Workflow Differences

C28x and C29x targets use different SoC Builder deployment models, which affects how you build and flash applications.

• For C28x targets, the SoC Builder workflow generates a separate executable for each CPU core. Each core is built, flashed, and managed independently.

• For C29x targets, the workflow generates a single executable that contains code for all CPU cores. CPU1 manages boot sequencing and initialization for CPU2 and CPU3.

Troubleshoot Migration Issues

Use the following guidance to diagnose common migration issues:

• If the device does not boot after a power cycle, verify that the executable is certified and correctly flashed to the device.

• If CPU2 or CPU3 does not start, confirm that CPU1 boots secondary CPUs in the required order and sends initialization commands successfully.

• If peripherals do not respond, verify that CPU1 establishes peripheral ownership before secondary CPUs access shared peripherals and that initialization occurs after ownership is assigned.