3. Getting Started With F29x MCAL

3.1. Getting access to MCAL

F29H85x MCAL can be requested from ti.com

3.2. Package installer

3.2.1. Installation Procedure

1.Run the installer executable & Click Next

Fig. 3.1 Installation Step1

2.Accept the license agreement & Click Next

Fig. 3.2 Installation Step2

3.Specify the installation directory & Click Next

Fig. 3.3 Installation Step3

4.Click Next to begin installation

Fig. 3.4 Installation Step4

5.Wait until the Setup complete the installation

Fig. 3.5 Installation Step5

6.Click Finish to complete the Setup

Fig. 3.6 Installation Step6

3.2.2. Un-installation Procedure

1.Check the installation directory (which is selected in Installation Procedure step3) for the package contents F29xxxxMCAL_xx_xx_xx & uninstall executable.

Fig. 3.7 Installation Step7

2.To uninstall the package, Run the uninstall executable & Click Yes

Fig. 3.8 Uninstallation Step1

Fig. 3.9 Uninstallation Step2

3.To complete the un-installation process, click OK

Fig. 3.10 Uninstallation Step3

3.3. F29H85x MCAL overview

F29H85x MCAL consists of three main components, Micro-controller abstraction layer (MCAL Driver code), Bare metal Example applications & EB Tresos studio Plugins.

• drivers: The drivers folder includes driver code of MCAL modules. The MCAL drivers implement the Software specification as mentioned in the AUTOSAR 4.3.1 release. It also contains basic software stubs and hardware register information.

• examples: The examples folder includes bare metal example applications for the MCAL driver modules that can be compiled and run on hardware. Additionally, the device support and AppUtils folders are included to support Flash-programming and UART console functionality.

• plugins: The plugins folder includes plugins for the MCAL modules that can be loaded, compiled and generate configuration files with EB Tresos Studio software.

3.4. Folder structure

📦F29x_MCAL
┣ 📂build
┣ 📂docs
┣ 📂drivers
┃ ┣ 📂ModuleName
┃ ┃ ┣ 📂include
┃ ┃ ┃ ┣ 📜ModuleName.h : Contains the API declarations of the driver to be used by upper layers.
┃ ┃ ┃ ┣ 📜ModuleName_Priv.h : Contains data structures and Internal function declarations.
┃ ┃ ┣ 📂src
┃ ┃ ┃ ┣ 📜ModuleName.c : Contains the implementation of the API for driver.
┃ ┃ ┃ ┗ 📜ModuleName_Priv.c : Contains Functions that support the API for driver
┃ ┃ ┗ 📜CMakeLists.txt
┣ 📂examples
┃ ┣ 📂ModuleName
┃ ┃ ┣ 📂ModuleName_Example
┃ ┃ ┃ ┣ 📂CCS
┃ ┃ ┃ ┃ ┗ 📜ModuleName_Example.projectspec : Project template which can be imported into CCS
┃ ┃ ┃ ┣ 📂ModuleName_config
┃ ┃ ┃ ┃ ┣ 📂config
┃ ┃ ┃ ┃ ┃ ┣ 📜ModuleName.xdm : Generated EB Tresos config file in .xdm format
┃ ┃ ┃ ┃ ┣ 📂include
┃ ┃ ┃ ┃ ┃ ┣ 📜ModuleName_Cfg.h : Contains the generated pre-complier configuration header.
┃ ┃ ┃ ┃ ┣ 📂src
┃ ┃ ┃ ┃ ┃ ┣ 📜ModuleName_Cfg.c or ModuleName_LCfg.c or ModuleName_PBCfg.c : Contains the pre/Link/Post build configuration parameters.
┃ ┃ ┃ ┃ ┗ 📜CMakeLists.txt
┃ ┃ ┃ ┣ 📜ModuleName_example.c : Example application for driver
┃ ┃ ┃ ┗ 📜CMakeLists.txt
┃ ┗ 📜CMakeLists.txt
┣ 📂plugins
┃ ┣ 📂ModuleName_TI_DeviceName
┃ ┃ ┣ 📂config
┃ ┃ ┃ ┣ 📜ModuleName.arxml : Vendor Specific Module Description : ECU Configuration and ECU Parameter definitions for the MCAL module
┃ ┃ ┃ ┗ 📜ModuleName.xdm : ECU Parameter definition for the MCAL module.
┃ ┃ ┣ 📂generate
┃ ┃ ┃ ┣ 📂include
┃ ┃ ┃ ┃ ┗ 📜ModuleName_Cfg.h :Provides template to generate header file
┃ ┃ ┃ ┗ 📂src
┃ ┃ ┃ ┃ ┣ 📜ModuleName_Cfg.c : Provides template to generate Compile Time module configurations
┃ ┃ ┃ ┃ ┗ 📜ModuleName_PBCfg.c : Provides template to generate Post Build module configurations
┃ ┃ ┣ 📂generate_swcd
┃ ┃ ┃ ┗ 📂swcd
┃ ┃ ┃ ┃ ┗ 📜ModuleName_BSWMD.arxml :Base Software Module Description : Contains details such exclusive area, Module Entries, Interrupts, MemMap etc…
┃ ┃ ┣ 📂META-INF
┃ ┃ ┃ ┗ 📜MANIFEST.MF : Licensing and module include information
┃ ┃ ┗ 📜plugin.xml :XML file used to register resources with EB Tresos Studio
┣ 📜CMakeLists.txt
┗ 📜CMakePresets.json

3.5. Getting access to CSP

Will be added in later release.

3.6. Compiler and Linker Settings

Compiler Option	Description
-mcpu	Target processor version : c29.c0
-mfpu	Floating-Point Support Option : Use native 32-bit floating-point hardware operations, but emulate 64-bit floating-point operations in software. none
-g	Debug information : The c29clang compiler generates DWARF debug information if the -g option is selected.
-Wall	Enable most warning categories
-D	Predefined Symbol Options : -DDEBUG -DASSERT_ENABLE
-O	Level of optimization -O1 (for Debug build type) -O2 (for Release build type)
-I	Option to add directories to the include file directory path
-cl-single-precision-constant	Option with the c29clang compiler to treat double precision floating-point constants as single precision constants
-Werror	Treat detected warnings in the specified category as errors.

Linker Option	Description
–map_file	Produces a map or listing of the input and output sections, including holes, and places the listing in filename : Project_name.map (as file name)
–stack_size	Sets C system stack size to size bytes and defines a global symbol that specifies the stack size. Note : specific for application
–heap_size	Sets heap size (for the dynamic memory allocation in C) to size bytes and defines a global symbol that specifies the heap size. Note : specific for application
–entry_point	Defines a global symbol that specifies the primary entry point for the output module
–xml_link_info	Generates a well-formed XML file containing detailed information about the result of a link : Project_name._linkInfo.xml (as file name)
–reread_libs	Forces rereading of libraries, which resolves back references
–warn_sections	Option to cause the linker to display a message when it creates a new output section
–rom_model	Tells the linker to auto initialize variables at run time
–display_error_number	Displays a diagnostic’s identifiers along with its text
–diag_wrap	Wrap diagnostic messages in the output display. This option is enabled by default

Refer this link to get more information on C29 Compiler options

Note

Please refer release notes for C29 compiler version details.

3.7. Modules Supported

Driver	Comments	Supported SoC	Available Cores	MCAL Supported Cores
Mcu	Driver for Mcu module	F29H85x	CPU 1 / CPU 2 / CPU 3	CPU 1 / CPU 2
Dio	Driver for DIO module	F29H85x	CPU 1 / CPU 2 / CPU 3	CPU 1 / CPU 2
Gpt	Driver for GPT module	F29H85x	CPU 1 / CPU 2 / CPU 3	CPU 1 / CPU 2
Port	Driver for PORT module	F29H85x	CPU 1 / CPU 2 / CPU 3	CPU 1 / CPU 2
Can	Driver for CAN module	F29H85x	CPU 1 / CPU 2 / CPU 3	CPU 1 / CPU 2
Wdg	Driver for Wdg module	F29H85x	CPU 1 / CPU 2 / CPU 3	CPU 1 / CPU 2
Lin	Driver for Lin module	F29H85x	CPU 1 / CPU 2 / CPU 3	CPU 1 / CPU 2
Spi	Driver for Spi module	F29H85x	CPU 1 / CPU 2 / CPU 3	CPU 1 / CPU 2
Cdd_Adc	Driver for Cdd_Adc module	F29H85x	CPU 1 / CPU 2 / CPU 3	CPU 1 / CPU 2
Cdd_Sent	Driver for Cdd_Sent module	F29H85x	CPU 1 / CPU 2 / CPU 3	CPU 1 / CPU 2
Cdd_Xbar	Driver for Cdd_Xbar module	F29H85x	CPU 1 / CPU 2 / CPU 3	CPU 1 / CPU 2

3.8. Multi-core support & resource allocator

3.8.1. Supported Devices

Device Family	Devices
F29x	F29H85x

3.8.2. Core Naming Conventions

SoC Family	Cores Names	Referred as	Comments
F29H85x	C29xx_CPU1	CPU 1	Supported in F29H85x MCAL
F29H85x	C29xx_CPU2	CPU 2	Not supported in F29H85x MCAL
F29H85x	C29xx_CPU3	CPU 3	Not supported in F29H85x MCAL

3.9. Dependencies

3.9.1. Hardware Dependencies

3.9.1.1. Emulator

F29x EVMs includes an XDS110 USB emulator which could be used with CCS.

Note

Please refer to ti.com or contact your FAE for documents describing the EVM.

3.9.2. Software Dependencies

3.9.2.1. IDE (CCS)

Code Composer Studio is an integrated development environment (IDE) that supports TI’s Micro-controller and Embedded Processors portfolio.

Note

Please refer release notes for CCS version details.

You can download CCS from ti.com

3.10. Start-up & AppUtils

3.10.1. Start-up code

📦F29x_MCAL
┣ 📂build
┣ 📂docs
┣ 📂drivers
┣ 📂examples
┃ ┣ 📂AppUtils
┃ ┣ 📂Can
┃ ┣ 📂Cdd_Adc
┃ ┣ 📂Cdd_Sent
┃ ┣ 📂Cdd_Xbar
┃ ┣ 📂DeviceSupport
┃ ┃ ┣ 📂include
┃ ┃ ┣ 📂LinkerCMD
┃ ┃ ┣ 📂src
┃ ┃ ┃ ┣ 📜codestartbranch.asm
┃ ┃ ┃ ┗ 📜DeviceSupport.c : Contains functions that Flash intialize wait states
┃ ┃ ┣ 📂targetconfigs
┃ ┃ ┣ 📜CMakeLists.txt
┃ ┃ ┗ 📜makefile.defs
┃ ┣ 📂Dio
┃ ┣ 📂Gpt
┃ ┣ 📂Lin
┃ ┣ 📂Mcu
┃ ┣ 📂Port
┃ ┣ 📂Spi
┃ ┗ 📂Wdg
┣ 📂plugins
┣ 📜CMakeLists.txt : Top-level CMake file
┗ 📜CMakePresets.json

• codestartbranch.asm: Defines the code start point, it disables watchdog and calls the _c_int00 function. The _c_int00 function is the startup/boot routine responsible for setting up the C environment. Refer compiler user guide to know more details about _c_int00 function.

• DeviceSupport.c: Defines DeviceSupport_Init function that initializes the required flash wait states(only for FLASH build configuration).

Attention

Start-up code is for reference only, it should not be used as-is in a typical AUTOSAR applications.

3.10.2. AppUtils

📦F29x_MCAL
┣ 📂build
┣ 📂docs
┣ 📂drivers
┣ 📂examples
┃ ┣ 📂AppUtils
┃ ┃ ┣ 📜AppUtils.c : Contains AppUtils function definitions
┃ ┃ ┣ 📜AppUtils.h
┃ ┃ ┗ 📜CMakeLists.txt
┃ ┣ 📂Can
┃ ┣ 📂Cdd_Adc
┃ ┣ 📂Cdd_Sent
┃ ┣ 📂Cdd_Xbar
┃ ┣ 📂DeviceSupport
┃ ┣ 📂Dio
┃ ┣ 📂Gpt
┃ ┣ 📂Lin
┃ ┣ 📂Mcu
┃ ┣ 📂Port
┃ ┣ 📂Spi
┃ ┗ 📂Wdg
┣ 📂plugins
┣ 📜CMakeLists.txt : Top-level CMake file
┗ 📜CMakePresets.json

AppUtils provides functions for baremetal MCAL examples.

Below are all the functions that are defined by AppUtils:

• AppUtils_Init: This function configures UART by setting the baudrate, clock, parity, data length and stop bits. It enables UART transmission and reception.

• AppUtils_Printf: This function internally uses UART to print a message or text on the serial console. This function has a limitation of printing a maximum of 1000 characters for each function call.

• AppUtils_DeInit: This function disables UART, which basically disables both transmission & reception of the UART after the it completes the transmission of the data, if there are any pending.

• AppUtils_GetChar: This function allows user to enter a character on the serial console.

• AppUtils_GetNum: This function allows user to enter a 32-bit number on the serial console.

• AppUtils_AssertFunc: This is a macro defined to check if the condition passed to the macro is TRUE at runtime.

Attention

AppUtils source code is for reference only, it should not be used as-is in a typical AUTOSAR applications.

3.11. Build system

3.11.1. CMake (Cross-Platform Make)

CMake is an open-source cross-platform build system generator for software projects that allows developers to specify build parameters in a simple, portable, text file format. This file is then used by CMake to generate project files for native build tools. CMake is not a build system itself; it generates another system’s build files. It can generate native build files for different platforms and compilers, such as Makefiles, Ninja files, Visual Studio solutions, or Xcode projects.

The build of a program or library with CMake is a two-stage process.

• Stage 1: CMake input files (.txt and .cmake) are processed to generate build tool files based on the selected build system (make, ninja,Xcode or Visual Studio).

• Stage 2: The generated build tool files are used to compile and build source files to generate binaries (executables or libraries).

Fig. 3.11 CMake Stage Flow

Note

For more information on CMake, please refer CMake official documentation

3.11.1.1. F29x MCAL CMake Architecture

📦F29x_mcal
┣ 📂build
┃ ┣📂artefacts : CMake generated configuration files
┃ ┣📂assets : Built assets
┃ ┣📂toolchain
┃ ┃ ┣ 📂signing
┃ ┃ ┣ 📜c2000-f29h85x.cmake : Toolchain CMake file
┃ ┃ ┗ 📜ti-cgt-c29-clang.cmake : Toolchain CMake file
┣ 📂drivers
┃ ┣ 📂BSW_Stubs
┃ ┣ 📂Can
┃ ┃ ┣ 📂include
┃ ┃ ┃ ┣ 📜Can.h
┃ ┃ ┃ ┣ 📜Can_Priv.h
┃ ┃ ┃ ┗ 📜Can_Reg_Access.h
┃ ┃ ┣ 📂src
┃ ┃ ┃ ┣ 📜Can.c
┃ ┃ ┃ ┣ 📜Can_Irq.c
┃ ┃ ┃ ┗ 📜Can_Priv.c
┃ ┃ ┗ 📜CMakeLists.txt : CAN driver CMake file
┃ ┣ 📂Cdd_Adc
┃ ┣ 📂Cdd_Sent
┃ ┣ 📂Cdd_Xbar
┃ ┣ 📂Dio
┃ ┣ 📂Gpt
┃ ┣ 📂hw_include
┃ ┣ 📂Lin
┃ ┣ 📂Mcal_Lib
┃ ┣ 📂Mcu
┃ ┣ 📂Port
┃ ┣ 📂Spi
┃ ┗ 📂Wdg
┣ 📂examples
┃ ┣ 📂AppUtils
┃ ┣ 📂Can
┃ ┃ ┣ 📂Can_Example_Classic
┃ ┃ ┃ ┣ 📂CCS
┃ ┃ ┃ ┣ 📂f29h85x_config
┃ ┃ ┃ ┃ ┣ 📂config
┃ ┃ ┃ ┃ ┣ 📂include
┃ ┃ ┃ ┃ ┃ ┣ 📜Can_Cfg.h
┃ ┃ ┃ ┃ ┃ ┣ 📜Dem_Cfg.h
┃ ┃ ┃ ┃ ┃ ┣ 📜EcuM_Cfg.h
┃ ┃ ┃ ┃ ┃ ┣ 📜Mcu_Cfg.h
┃ ┃ ┃ ┃ ┃ ┣ 📜Os_Cfg.h
┃ ┃ ┃ ┃ ┃ ┗ 📜Port_Cfg.h
┃ ┃ ┃ ┃ ┣ 📂src
┃ ┃ ┃ ┃ ┃ ┣ 📜Can_Cfg.c
┃ ┃ ┃ ┃ ┃ ┣ 📜Can_PBcfg.c
┃ ┃ ┃ ┃ ┃ ┣ 📜Dem_Cfg.c
┃ ┃ ┃ ┃ ┃ ┣ 📜EcuM_Cfg.c
┃ ┃ ┃ ┃ ┃ ┣ 📜Mcu_PBcfg.c
┃ ┃ ┃ ┃ ┃ ┣ 📜Os_Cfg.c
┃ ┃ ┃ ┃ ┃ ┗ 📜Port_PBcfg.c
┃ ┃ ┃ ┃ ┗ 📜CMakeLists.txt : CMake file for f29h85x_config folder
┃ ┃ ┃ ┣ 📜Can_Example_Classic.c
┃ ┃ ┃ ┣ 📜Can_Example_Classic.h
┃ ┃ ┃ ┗ 📜CMakeLists.txt : Can_Example_Classic CAN example CMake file
┃ ┃ ┣ 📂Can_Example_Icom
┃ ┃ ┗ 📂Can_Example_loopback
┃ ┣ 📂Cdd_Adc
┃ ┣ 📂Cdd_Sent
┃ ┣ 📂Cdd_Xbar
┃ ┣ 📂DeviceSupport
┃ ┣ 📂Dio
┃ ┣ 📂Gpt
┃ ┣ 📂Lin
┃ ┣ 📂Mcu
┃ ┣ 📂Port
┃ ┣ 📂Spi
┃ ┣ 📂Wdg
┃ ┗ 📜CMakeLists.txt : Examples CMake file
┣ 📜CMakeLists.txt : Root-Level CMake file
┗ 📜CMakePresets.json : CMake preset json file

F29x MCAL specific CMake files are described below -

• CMakePresets.json

  • This file contains recommended presets configured for F29x MCAL projects, users can continue to use the presets as-is or choose to override them with their project specific requirements by adding a CMakeUserPresets.json file.

  • It also define all the compiler and linker options as defined in Compiler and Linker Settings

  • The presets file defines support for different generators -

    1. mingw-c2000-f29h85x: Preset for MinGW Makefiles generator - works on Windows based system

    2. unix-c2000-f29h85x: Preset for Unix Makefiles generator - works on Linux based system

    3. ninja-c2000-f29h85x: Preset for Ninja generator - works on both Windows and Linux based system.

    Note

    The options set in CMakePresets.json file can be overridden using CMakeUserPresets.json file. For more information about CMake Presets refer cmake-presets.

• Toolchain

  • Since we need to perform cross-compilation toolchain files are defined to ease the compiler integration in CMake.

  • c2000-f29h85x.cmake : This file defines the required CPU Flags and is device / core specific.

  • ti-cgt-c29-clang.cmake : This file defines all necessary information required to use C29Clang compiler including Compiler path handling, standard library inclusion etc.

• CMakelists.txt file at Root-level

  • This file defines the minimum required CMake version for the project.

  • It defines the BUILD_CONFIGURATION which controls whether the executable runs from FLASH or RAM on the target.

  • It also provides Signing function which is needed to sign the generated executable when FLASH mode is selected.

• CMakelists.txt file at MCAL Driver level

  • This file is used to create interface library for each MCAL / CDD for easy inclusion in Application.

  • The library is defined using the add_library.

  • All the source files in the driver are added using target_sources.

  • All header file include paths are added to the library using target_include_directories.

  • Any application wanting to use the MCAL / CDD can do so by adding this file into their CMakelists.txt.

• CMakelists.txt file at config level

  • This file is used to create an interface library for the generated config file from EB Tresos.

  • It is recommended to use this file for easier management of files generated from the Configurator.

  • Any application wanting to use the MCAL / CDD needs to also include this file along with the driver level CMakelists.txt to compile MCAL / CDD correctly.

  • Reference for this file can be found in all of the provided MCAL / CDD examples.

• CMakelists.txt file at Example level

  • This file defines the actual executable target to be created by using add_executable.

  • All required interface libraries are add using add_subdirectory.

  • To protect against re-inclusion of a library / target an IF check is added.

  • Additional Linker options are defined using add_link_options command.

  • Required interface libraries are linked using target_link_libraries command.

  • add_custom_command is used to move the generated files to a different location.

3.11.1.2. CMake options

3.11.1.2.1. F29x MCAL Specific options during CMake configure (Stage 1)

To configure CMake following command can be executed in terminal - cmake -S {source_dir_path} –preset {preset_name} -DCMAKE_BUILD_TYPE = {build_type} -DBUILD_CONFIGURATION = {build_configuration} -DTCP={path-to-the-compiler}

Configure Option	Description
TCP	Compiler path can be specified with this parameter, if the compiler is not already on the system’s PATH environment variable.
CMAKE_BUILD_TYPE	Defines the build type for the project. Possible options are - Debug : Includes debug information in the compiled files (allowing easy debugging). Release : Has optimizations enabled (default)
BUILD_CONFIGURATION	Controls which memory area application executes from. Possible options are - RAM : Application executes from RAM. Recommended with Debug mode for small size applications. FLASH : Application executes from internal FLASH. Recommended with Release mode. (default)

3.11.1.2.2. F29x MCAL Specific options during CMake build (Stage 2)

To build following command can be executed in terminal - cmake –build {path-to-the-CMake-generated-files} -t {target}

Configure Option	Description
path-to-the-CMake-generated-files	Path to CMake generated files from stage 1. This is located at build/artefacts folder.
target	Name of the target to be built (default : all)

Note

–clean-first option can be appended to the target build command to clean the build before re-building a target.

3.11.1.3. How to link F29x MCAL / CDD CMake to your application

Any MCAL example CMake file can be used as reference.

1. Create a main CMake file to handle CMake build for your application.

2. Include required MCAL / CDD drivers using add_subdirectory.

3. Add generated code from MCAL Configurator by creating a separate CMakelists.txt for the generated files and including this file in your application CMakelists.txt using add_subdirectory.

4. Add required compiler and linker options.

5. Link all the added interface libraries in Step 2 and 3 by using target_link_libraries.

Note

For more information on CMake support by the C29Clang compiler you can refer compiler documentation

3.11.2. Code Composer Studio (CCS)

3.11.2.1. Importing projects into CCS

📦F29x_mcal
┣ 📂build
┣ 📂drivers
┣ 📂examples
┃ ┣ 📂AppUtils
┃ ┣ 📂Can
┃ ┃ ┣ 📂Can_Example_Classic
┃ ┃ ┃ ┣ 📂CCS
┃ ┃ ┃ ┃ ┗ 📜Can_Example_Classic.projectspec : Project template which can be imported into CCS
┃ ┃ ┃ ┣ 📂f29h85x_config
┃ ┃ ┃ ┣ 📜Can_Example_Classic.c
┃ ┃ ┃ ┣ 📜Can_Example_Classic.h
┃ ┃ ┃ ┗ 📜CMakeLists.txt
┃ ┃ ┣ 📂Can_Example_Icom
┃ ┃ ┗ 📂Can_Example_loopback
┃ ┣ 📂Cdd_Adc
┃ ┣ 📂Cdd_Sent
┃ ┣ 📂Cdd_Xbar
┃ ┣ 📂DeviceSupport
┃ ┣ 📂Dio
┃ ┣ 📂Gpt
┃ ┣ 📂Lin
┃ ┣ 📂Mcu
┃ ┣ 📂Port
┃ ┣ 📂Spi
┃ ┣ 📂Wdg
┃ ┗ 📜CMakeLists.txt
┣ 📜CMakeLists.txt
┗ 📜CMakePresets.json

Every F29x MCAL example comes with a projectspec file which can be imported in CCS.

1. Open CCS and select Import Project -

   

   Fig. 3.12 CCS Import Step 1

2. Browse to the folder containing Projectspec file and select the desired CCS Project to be imported.

   

   Fig. 3.13 CCS Import Step 2

3. Once project is imported you can continue to build and debug the project.

   

   Fig. 3.14 CCS Project Imported

3.11.2.2. Loading generated executable file using CCS

1. Import any example project to CCS, right click on the ccxml file and ‘Start project-less Debug’.

   

   Fig. 3.15 CCS Loading Executable Step1

2. Right click on the C29xx_CPU1 THREAD and ‘Connect Target’.

   

   Fig. 3.16 CCS Loading Executable Step2

3. Go to Run - Load - Load Program.

   

   Fig. 3.17 CCS Loading Executable Step3

4. Browse to the folder containing the generated executable, select the desired executable to be loaded and click on OK.

   

   Fig. 3.18 CCS Loading Executable Step4

5. Once the executable is loaded you can continue to run and debug the project.

   

   Fig. 3.19 CCS Executable Loaded

Note

For more information on projectspec and it’s use in CCS refer documentation.

3.11.2.3. Building and Debugging projects in CCS

Note

For information on how to build and debug any project in CCS refer documentation.

3.12. Information on the F29x device family

3.12.1. F29x CPU Architecture

The F29x CPU is a VLIW (Very Long Instruction Word) architecture with a fully protected pipeline. The CPU supports multiple instruction sizes (16/32/48 bits). The CPU also supports variable instruction packet size, with each packet able to contain up to eight instructions that execute in parallel.

Following are the list of F29H85x CPU major features:

• Ease of use

• Improved parallelism

• Improved bus throughput

• Code efficiency

• ASIL-D safety capability with code isolation in hardware

• Multi-zone security in hardware

• Enhanced debug and trace capabilities

You can downloaded TRM from ti.com

3.13. Boot Modes

Will be added in later release.

3.14. Loading example configs to EB tresos

• Create and load the plugins required for the example by following the steps in Create an EB project and Load plugins and close the EB tresos.

Fig. 3.20 EB Tresos Example Project Created

• Copy the ECU Parameter definition files(.xdm) of the specific example.

Fig. 3.21 MCAL Example ECU Parameter definition files

• Go to the EB tresos project workspace and replace the generated ECU Parameter definition files (.xdm) with the ECU Parameter definition files of your specific example.

Fig. 3.22 EB Tresos ECU Parameter definition files

• Launch the EB Tresos tool again to see the example configurations.