### BoosterPack Configuration File Schema Example Source: https://deepwiki.com/TexasInstruments/c2000ware-core-sdk/3-boosterpack-configuration-system An example illustrating the structure of a BoosterPack configuration file in JSON format, used by the SysConfig tool. It includes metadata fields like 'name', 'displayName', 'description', and 'components' to define a specific BoosterPack board. ```json { "name": "BOOSTXL_EXAMPLE", "displayName": "BOOSTXL-EXAMPLE", "description": "EXAMPLE Boosterpack", "longDescription": "EXAMPLE Boosterpack", "headerType": "BoosterPack 40 pin", "components": {} } ``` -------------------------------- ### Example BoosterPack Configuration Source: https://deepwiki.com/TexasInstruments/c2000ware-core-sdk/3-boosterpack-configuration-system This JSON snippet demonstrates a complete BoosterPack configuration, defining an SPI bus and an LED component with their respective pin connections. It highlights the structure of the 'components' object, including 'displayName', 'description', 'definition', and 'connections'. ```json { "name": "BOOSTXL_EXAMPLE", "displayName": "BOOSTXL-EXAMPLE", "description": "EXAMPLE Boosterpack", "longDescription": "EXAMPLE Boosterpack", "headerType": "BoosterPack 40 pin", "components": { "BOOSTXL_SPI": { "displayName": "BOOSTXL SPI Bus", "description": "BOOSTXL SPI bus", "longDescription": "BOOSTXL SPI bus", "definition": "/boards/components/boostxl_spi_bus.json", "connections": { "SCLK": 7, "SIMO": 15, "SOMI": 14, "STE": 19 } }, "PIN": { "displayName": "PIN LED", "definition": "/boards/components/led.json", "connections": { "OUTPUT": 4 } } } } ``` -------------------------------- ### Multiple PWM Component Instances Source: https://deepwiki.com/TexasInstruments/c2000ware-core-sdk/3-boosterpack-configuration-system This JSON example demonstrates how to instantiate the same component definition ('boostxl_pwm_pair.json') multiple times with different pin assignments to create independent PWM pairs. This showcases component reuse for multi-phase control systems. ```json "components": { "BOOSTXL_PWMA": { "displayName": "Phase A PWM", "definition": "/boards/components/boostxl_pwm_pair.json", "connections": { "PWM_POS": 40, "PWM_NEG": 39 } }, "BOOSTXL_PWMB": { "displayName": "Phase B PWM", "definition": "/boards/components/boostxl_pwm_pair.json", "connections": { "PWM_POS": 38, "PWM_NEG": 37 } }, "BOOSTXL_PWMC": { "displayName": "Phase C PWM", "definition": "/boards/components/boostxl_pwm_pair.json", "connections": { "PWM_POS": 36, "PWM_NEG": 35 } } } ``` -------------------------------- ### Configure SDK Include Paths in .metadata/sdk.json Source: https://deepwiki.com/TexasInstruments/c2000ware-core-sdk/9-development-workflow This snippet shows how to configure the SDK's base include path within the `.metadata/sdk.json` file. This allows referencing SDK files relatively, facilitating project setup for build systems. ```json { "includePaths": [ ".." ] } ``` -------------------------------- ### Specify Migration Products in .metadata/sdk.json Source: https://deepwiki.com/TexasInstruments/c2000ware-core-sdk/9-development-workflow This configuration within `.metadata/sdk.json` lists products for migration support, specifying the target product name and its compatible version range. This helps the SysConfig tool guide users when migrating to newer device families. ```json { "migrationProducts": [ { "name": "MCU_SDK_F29H85x", "versionRange": "^1.0.0" } ] } ``` -------------------------------- ### SDK Migration Product Declaration (JSON) Source: https://deepwiki.com/TexasInstruments/c2000ware-core-sdk/9 Example of how an SDK declares compatible products for migration purposes within its `sdk.json` metadata file. This JSON snippet specifies product names and version ranges that can be migrated to. It aids in understanding SDK interdependencies during updates. ```json "migrationProducts": [ { "name": "MCU_SDK_F29H85x", "versionRange": "^1.0.0" } ] ``` -------------------------------- ### Peripheral Initialization Configuration (C) Source: https://deepwiki.com/TexasInstruments/c2000ware-core-sdk/9 Example structure of peripheral configuration arrays, specifically for GPIO, generated by the PeripheralComponents.js module. This code defines how peripherals are configured during initialization. It includes declarations for peripheral handles and configuration arrays. ```c // Example generated structure in ti_drivers_config.c const GPIO_Config GPIO_config[GPIO_COUNT] = { { .fxnTablePtr = &GPIODxxxFxnTable, .pinConfig = ..., .callbackFunction = NULL } }; ``` -------------------------------- ### DRV8301 PWMA Component Definition Example Source: https://deepwiki.com/TexasInstruments/c2000ware-core-sdk/4-motor-control-boosterpacks An example demonstrating the structure of a component definition for the DRV8301 BoosterPack, specifically for the PWMA pair. This includes display name, descriptions, the path to the reusable definition file, and pin connections. ```json "BOOSTXL_PWMA": { "displayName": "BOOSTXL-DRV8301 PWMA Pair", "description": "BOOSTXL-DRV8301 PWMA Pair Pins", "longDescription": "Pins used by BOOSTXL-DRV8301 for PWMHA/PWMLA", "definition": "/boards/components/boostxl_pwm_pair.json", "connections": { "EPWM_A": 40, "EPWM_B": 39 } } ``` -------------------------------- ### Generated Code Initialization Error Handling (C) Source: https://deepwiki.com/TexasInstruments/c2000ware-core-sdk/9 An example pattern for initialization functions in generated code, illustrating error checking. The GPIO_init function demonstrates how return values should be checked by application code to handle initialization failures. ```c // Example pattern in generated code bool GPIO_init(void) { GPIO_setConfig(GPIO_PIN_0, GPIO_CFG_OUT); if (!GPIO_verify(GPIO_PIN_0)) { return false; // Initialization failed } return true; } ``` -------------------------------- ### Component Definition Paths Reference Source: https://deepwiki.com/TexasInstruments/c2000ware-core-sdk/3-boosterpack-configuration-system This list shows example relative paths to reusable component definition files within the SDK root directory. These paths are used in the 'definition' field of component declarations to specify which component logic to use. ```json "/boards/components/boostxl_spi_bus.json" "/boards/components/led.json" "/boards/components/boostxl_gpio.json" "/boards/components/boostxl_adc.json" "/boards/components/boostxl_pwm_pair.json" ``` -------------------------------- ### Typical main.c Integration of Generated Code Source: https://deepwiki.com/TexasInstruments/c2000ware-core-sdk/9-development-workflow Demonstrates how to include and call initialization functions generated by SysConfig within the main C file of an application. This includes initializing the device, drivers, and board-specific configurations. ```c #include "ti_drivers_config.h" // Generated header #include "Board.h" // Generated board support void main(void) { // Initialize device clocks and peripherals (generated) Device_init(); // Initialize drivers (generated) Drivers_init(); // Initialize board (generated) Board_init(); // User application code // ... } ``` -------------------------------- ### Configuration Extensibility - Board Configurations Source: https://deepwiki.com/TexasInstruments/c2000ware-core-sdk/2-sdk-configuration-system Explains how to add support for new BoosterPacks or evaluation modules. This is achieved by creating `.syscfg.json` files in the `/boards/` directory without modifying the main `sdk.json`. ```json { "boards": { "new_board": "path/to/new_board.syscfg.json" } } ``` -------------------------------- ### Configuration Extensibility - Device Support Source: https://deepwiki.com/TexasInstruments/c2000ware-core-sdk/2-sdk-configuration-system Shows how to add support for new device families by including their identifiers in the 'devices' array and implementing corresponding device-specific modules. ```json { "devices": [ "new_device_family" ] } ``` -------------------------------- ### Specifying Minimum SysConfig Tool Version Source: https://deepwiki.com/TexasInstruments/c2000ware-core-sdk/2 The `minToolVersion` field defines the minimum required SysConfig tool version for the SDK. SysConfig enforces this, displaying an error if the installed version is older, ensuring the SDK can utilize necessary features. ```json "minToolVersion": "1.24.0" ``` -------------------------------- ### Define SDK Product Migration Paths (JSON) Source: https://deepwiki.com/TexasInstruments/c2000ware-core-sdk/2-sdk-configuration-system This JSON array defines migration paths to other SDK products, suggesting or facilitating transitions from C2000WARE to other SDKs like the F29H85x MCU SDK. It specifies the target product name and a version range for compatibility. ```json { "migrationProducts": [ { "name": "MCU_SDK_F29H85x", "versionRange": "^1.0.0" } ] } ``` -------------------------------- ### Linker Command File Integration (Assembly) Source: https://deepwiki.com/TexasInstruments/c2000ware-core-sdk/9 The generated linker command file (.cmd) must be passed to the linker to define memory sections, section placement, stack/heap sizes, and boot code. This example shows how to add the generated .cmd file to the CCS project build properties. ```assembly # CCS Project Properties -> Build -> C2000 Linker -> File Search Path # Add generated .cmd file: "${PROJECT_ROOT}/f28004x_flash.cmd" ``` -------------------------------- ### Configuration Extensibility - Multi-Core Contexts Source: https://deepwiki.com/TexasInstruments/c2000ware-core-sdk/2-sdk-configuration-system Demonstrates how to support new multi-core architectures by defining contexts within the 'contexts' object. This is crucial for managing separate debug connections to multiple CPU cores. ```json { "contexts": { "new_context": { "targetdbId": "C28xx_CPU3" } } } ``` -------------------------------- ### Custom Post-Initialization for GPIO (C) Source: https://deepwiki.com/TexasInstruments/c2000ware-core-sdk/9 Shows how to extend generated initialization code with custom logic, specifically for GPIO callbacks and interrupts. This pattern allows users to add specific event handling after the basic peripheral initialization is complete. It's recommended to keep this custom code in user source files. ```c // Generated init GPIO_init(); // User post-init customization GPIO_setCallback(GPIO_LED, myLedHandler); GPIO_enableInt(GPIO_LED); ``` -------------------------------- ### Configuration Extensibility - Component Modules Source: https://deepwiki.com/TexasInstruments/c2000ware-core-sdk/2-sdk-configuration-system Illustrates how to extend the SDK configuration by adding new peripheral drivers or utilities. This involves creating a JavaScript module and updating the 'components' array in the configuration. ```javascript { "components": [ "path/to/new/module" ] } ``` -------------------------------- ### Path Configuration Metadata - JSON Source: https://deepwiki.com/TexasInstruments/c2000ware-core-sdk/2 Specifies the locations of SDK resources that SysConfig needs to access. This includes documentation, include paths for code generation, and BoosterPack board definitions. ```json { "documentationPath": "./doc", "includePaths": [".."], "boardPath": "/boards/" } ``` -------------------------------- ### Runtime Peripheral Initialization Control (C) Source: https://deepwiki.com/TexasInstruments/c2000ware-core-sdk/9 Illustrates how to selectively initialize peripherals at runtime based on application needs. This allows for optimizing resource usage by only calling initialization functions for required modules. `Board_init()` is typically called first, followed by conditional initialization of other peripherals like GPIO and SPI. ```c // Initialize only required peripherals Board_init(); // Always call GPIO_init(); // Required if (needsSPI) { SPI_init(); // Conditional } // Skip ADC_init() if not needed this run ``` -------------------------------- ### Dual-Core Context Configuration in sdk.json Source: https://deepwiki.com/TexasInstruments/c2000ware-core-sdk/9-development-workflow Defines CPU contexts for dual-core devices, mapping context names to target database IDs for debugging. Each context requires separate SysConfig configuration and generates independent initialization code. This configuration is stored in the sdk.json file. ```json { "contexts": { "F2837xD": [ {"name": "CPU1", "targetdbId": "C28xx_CPU1"}, {"name": "CPU2", "targetdbId": "C28xx_CPU2"} ], "F2838x": [ {"name": "CPU1", "targetdbId": "C28xx_CPU1"}, {"name": "CPU2", "targetdbId": "C28xx_CPU2"} ], "F28P65x": [ {"name": "CPU1", "targetdbId": "C28xx_CPU1"}, {"name": "CPU2", "targetdbId": "C28xx_CPU2"} ] } } ``` -------------------------------- ### Defining Migration Paths to Future Device Families Source: https://deepwiki.com/TexasInstruments/c2000ware-core-sdk/2 The `migrationProducts` field specifies upgrade paths to newer device families. It includes the target product name and a version range using semantic versioning, aiding in project conversion workflows. ```json "migrationProducts": [ { "name": "MCU_SDK_F29H85x", "versionRange": "^1.0.0" } ] ```