3. Getting Started With AM263Px MCAL

3.1. Getting access to MCAL

AM263Px MCAL can be requested from ti.com

3.2. Package installer

None

3.3. AM263Px MCAL Overview

AM263Px is an SOC from TI targeted to address various AUTOMOTIVE markets. AUTOSAR is a key software which needs to run on ARM Cortex-R5 so that it can enable communication with other ECUs in the system. TI needs to provide the MCAL drivers for the AUTOSAR to run on the SOCs. Customers will need to procure the other AUTOSAR SW stack either internally or from third parties.

AM263Px 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.
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

📦AM263Px
┣ 📂build : Make files for building the MCAL library. MCAL supports make based build
┣ 📂mcal
┃ ┣ 📂ModuleName
┃ ┃ ┣ 📂include
┃ ┃ ┃ ┗ 📜ModuleName.h : Contains the API declarations of the driver to be used by upper layers
┃ ┃ ┣ 📂src
┃ ┃ ┃ ┗ 📜ModuleName.c : Contains the implementation of the API’s for driver
┃ ┃ ┣ 📂Vx : Contains other supporting SOC files for driver
┃ ┃ ┗ 📜Makefile
┃ ┣ 📂autosar_include : These included files part of the AUTOSAR BSW core. These should replace with the header files part of the AUTOSAR stack into which the MCAL is integrated
┃ ┣ 📂examples : The contents of this directory SHOULD NOT be used in an AUTOSAR stack integration. It contains the utility API’s for ISR’s and enabling/disabling interrupts used, commonly across the examples when used in a non-AUTOSAR context
┃ ┃ ┣ 📂ModuleName
┃ ┃ ┃ ┣ 📂soc
┃ ┃ ┃ ┣ 📜ModuleNameApp.c : Contains test example
┃ ┃ ┃ ┣ 📜ModuleNameApp.h : Contains example header file
┃ ┃ ┃ ┗ 📜Makefile
┃ ┣ 📂examples_config
┃ ┃ ┣ 📂ModuleName_Demo_Cfg
┃ ┃ ┃ ┣ 📂soc
┃ ┃ ┃ ┃ ┣ 📂am263px
┃ ┃ ┃ ┃ ┃ ┗ 📂r5f0_0
┃ ┃ ┃ ┃ ┃ ┃ ┣ 📂include
┃ ┃ ┃ ┃ ┃ ┃ ┃ ┗📜ModuleName_Cfg.h : Contains the configuration parameters
┃ ┃ ┃ ┃ ┃ ┃ ┗ 📂src
┃ ┃ ┃ ┃ ┃ ┃ ┃ ┗ 📜ModuleName_Cfg/PBCfg/Lcfg.c : Contains all Pre-Compile/Post build/Link Time Configured parameters
┣ 📂mcal_config
┃ ┣ 📂plugins
┃ ┃ ┣ 📂AM263Px
┃ ┃ ┃ ┣ 📂ModuleName_TI_AM263Px
┃ ┃ ┃ ┃ ┣ 📂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.
┃ ┃ ┃ ┃ ┃ ┗ 📜ModuleName_NonEB.xdm : ECU Parameter definition for the NON EB
┃ ┃ ┃ ┃ ┣ 📂config_ext
┃ ┃ ┃ ┃ ┃ ┗ 📜ModuleName_Rec.xdm : Sample 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
┃ ┃ ┃ ┃ ┃ ┣ 📜CRYPTOMANIFEST.MF
┃ ┃ ┃ ┃ ┃ ┣ 📜CRYPTOMANIFESTSIG.MF
┃ ┃ ┃ ┃ ┃ ┗📜MANIFEST.MF : Licensing and module include information
┃ ┃ ┃ ┃ ┗ 📜plugin.xml : XML file used to register resources with EB Tresos Studio
┣ 📂mcal_docs
┃ ┣ 📂csp : Contains test reports of all supported modules
┃ ┗ 📂userguide : Contains userguide of all supported modules
┗ 📜README.txt

3.5. Getting access to CSP

Will be added in later release.

3.6. Compiler and Linker Settings

3.6.1. Compiler Variants

MCAL package can be built with the following compiler variant: TI ARM CLANG 4.0.0.LTS.

Users can build with either compiler variants.

gmake all PLATFORM=am263px PROFILE=<release/debug> COMPILER_VARIANT=<CLANG>

COMPILER_VARIANT can take the following value(s): CLANG

If COMPILER_VARIANT is not specified during the build, MCAL will be built for CLANG by default.

3.6.2. Compiler Options

Below are the compiler flags used:

Compiler Option	Description
-c	Stop compilation after emitting compilergenerated object files; do not call linker.
-mlittle-endian	Select little-endian; default
-mcpu=cortex-r5	ARM R5 architecture
-mfpu=vfpv3-d16	Select appropriate floating-point hardware
-mfloat-abi=hard	Floating-point hardware is available; select appropriate hardware with -mfpu option
-ffunction-sections	Instructs the tiarmclang compiler to generate code for a function definition into its own section
-gdwarf-3	Emit DWARF version 3 debug information
-Werror	Treat detected warnings in the specified category as errors
-Os	Most optimizations enabled, especially optimizations that are designed to reduce code size while mitigating negative impacts on performance
-x	Decides the compile mode (c / c++ / ti-asm …)
-save-temps	Keeps all temporary files generated during compilation and linking without halting either the compiler or the linker
-mthumb	Recognized when using armclang as a compiler,but not when using it as a assembler

3.6.3. Linker Options

Below are the linker flags used

Linker Options	Description
–emit_warnings_as_errors -WL	Treats warnings as errors
–warn_sections	Displays a message when an undefined output section is created
-qq	Super quiet mode(quiet: Suppresses progress messages)
–diag_suppress=10068	suppress error “no matching section”
-mcpu=cortex-r5	ARM R5 architecture
–diag_suppress=10063	supresses ‘warning: entry point other than _c_int00 specified
–ram_model	Initializes variables at load time
–reread_libs -wl	Forces rereading of libraries, which resolves back references

3.7. Modules Supported

A set of MCAL included in the package each controlling a specific peripheral. MCAL drivers included are

Driver	Comments
MCU	Driver to control enabling of modules, PLL setting and basic microcontroller initialization
PORT	Driver for control of PinMux
SPI	SPI handler and driver for Serial Peripheral Interfaces: McSPI
CAN	Driver for the on-chip MCAN controller peripheral
GPT	Driver that controls the internal timer of the controller
WDG	Driver for controlling the watchdog when controller goes into continuous loop
DIO	Driver to read and write the data from the Channels / Port
FLS	Driver provides services for reading, writing, erasing flash memory for external flash device
ETH	Driver provides services to transmit and receive data with the external devices
ETHTRCV	Driver for Physical Layer Transceiver
ADC	Driver converts the analog value applied to ADC pin to its equivalent digital value
PWM	Driver provides the pulse width modulated signal
EPWM	Driver provides the enhanced pulse width modulated signal
ICU	The ICU driver is a module using the input capture unit (ICU) counting pulses, measuring of frequency and duty cycle
IPC	Make the initialization of mailbox driver and provides read and write APIs to perform inter processor communication
UART	Driver provides serial communication using UART
I2C	Driver provides support for transferring data between an external I2C device and the chip running this driver
DMA	Provides direct memory access
FsiRx	Provides fast serial data reception service with the external devices
FsiTx	Provides fast serial data transmission service with the external devices
LIN	Driver for the on-chip Lin controller peripheral
CMPSS	Driver consists of analog comparators and supporting circuits that are useful for power applications
FLC	Driver provides support to accelerate boot up

The MCAL drivers implement the Software specification as mentioned in the AUTOSAR 4.3.1 release. Additionally, examples to demonstrate MCAL driver usages have also been included.

3.8. Multi-core support

3.8.1. Supported Devices/Platforms

AM263Px: This release supports AM263Px SoC

3.8.2. Core Naming Conventions

SoC Family	Cores Names	Referred as	Comments
AM263Px	CORTEX_R5_0	R5_0	Supported in AM263Px MCAL
AM263Px	CORTEX_R5_1	R5_1	Not supported in AM263Px MCAL
AM263Px	CORTEX_R5_2	R5_2	Not supported in AM263Px MCAL
AM263Px	CORTEX_R5_3	R5_3	Not supported in AM263Px MCAL

3.9. Dependencies

3.9.1. Hardware Dependencies

3.9.1.1. Hardware Setup

List of hardware required for AM263Px EVM:

1.AM263Px CC / EVM

2.5V 3Amp USB Type-C Power Adaptor.

3.Micro USB Cable.

3.9.1.2. Cable Connections

Important cable connections, ports and switches.

3.9.1.2.1. AM263PX-CC

1.System Power On/Off

5V power through Type-C 5V/3A
HSEC 5V power is available only if Type-C is unavailable
No mechanical on/off switch on this EVM

3.9.1.2.2. AM263PX-LP

3.9.1.3. Setup UART Terminal

3.9.1.3.1. AM263PX-CC

1.Many examples use a standard UART terminal to log the output from the examples. You can use any UART terminal program for the same. Below steps show how to setup the UART terminal from CCS.

2.First identify the UART port as enumerated on the host machine.

Make sure that the EVM and UART cable connected as shown in Cable Connections
In windows, you can use the “Device Manager” to see the detected UART ports
Search “Device Manager” in Windows Search Box in the Windows taskbar.
If you don’t see any USB serial ports listed in “Device Manager” under “Ports (COM & LPT)”, then make sure you have installed the UART to USB driver from FTDI, https://www.ftdichip.com/FTDrivers.htm.

Fig. 3.3 Identify UART Port in Windows Device Manager

3.In CCS, goto “View > Terminal”

4.Open a new UART terminal

5.Select the UART port, keep other options to default, i.e 115200 baud rate - 8 data bits - No parity - 1 stop bit,

We use this serial port, as seen in the device manager, for below in the SDK
- Flashing application via UART
- Booting application via UART
- Console output for examples

6.In this screenshot this happens to be COM5/COM11 however on your machine this could be different. One tip to make sure there is no mistake in identifying the UART port is to disconnect all other UART to USB devices other than this EVM before checking in device manager.

3.9.1.3.2. AM263PX-LP

1.Many examples use a standard UART terminal to log the output from the examples. You can use any UART terminal program for the same. Below steps show how to setup the UART terminal from CCS. 2.First identify the UART port as enumerated on the host machine.

Make sure that the EVM and UART cable connected as shown in :ref:Cable Connections_p.
In windows, you can use the “Device Manager” to see the detected UART ports.
Search “Device Manager” in Windows Search Box in the Windows taskbar.
If dont see any USB serial ports listed in “Device Manager” under “Ports (COM & LPT)”, then make sure you have installed the UART to USB driver from FTDI, https://www.ftdichip.com/FTDrivers.htm.

3.In CCS, goto “View > Terminal”

4.Open a new UART terminal

5.Select the UART port, keep other options to default, i.e 115200 baud rate - 8 data bits - No parity - 1 stop bit,

We use this serial port, as seen in the device manager, for below in the SDK
- Flashing application via UART
- Booting application via UART
- Console output for examples

6.In this screenshot this happens to be COM5/COM11 however on your machine this could be different. One tip to make sure there is no mistake in identifying the UART port is to disconnect all other UART to USB devices other than this EVM before checking in device manager.

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 downloaded CCS from ti.com

3.9.2.1.1. Installation Steps

1.Use TI CCS v12.5.0 or later

2.After the package is downloaded, you will be prompted to restart CCS to complete the installation.

3.The installer will install the Emulation package and complete installation.

3.10. Start-up & AppUtils

3.10.1. Start-up code

📦AM263Px
┣ 📂build
┣ 📂mcal
┃ ┣ 📂ModuleName
┃ ┣ 📂autosar_include
┃ ┣ 📂examples
┃ ┣ 📂examples_config
┃ ┣ 📂include : Contains the Startup Code
┣ 📂mcal_config
┣ 📂mcal_docs
┗ 📜README.txt

Attention

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

3.10.2. Apputils

📦AM263Px
┣ 📂build
┣ 📂mcal
┃ ┣ 📂ModuleName
┃ ┣ 📂autosar_include
┃ ┣ 📂examples
┃ ┃ ┣ 📂ModuleName
┃ ┃ ┣ 📂Utils : Contains AppUtils functions
┃ ┣ 📂examples_config
┃ ┣ 📂include
┣ 📂mcal_config
┣ 📂mcal_docs
┗ 📜README.txt

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. AM26x MCAL Make Architecture

📦AM263Px
┣ 📂build
┃ ┣ 📂bootimage_scripts
┃ ┣ 📂makerules
┃ ┃ ┣ 📜build_config.mk
┃ ┃ ┣ 📜build_config_CLANG.mk
┃ ┃ ┣ 📜common.mk
┃ ┃ ┣ 📜component.mk
┃ ┃ ┣ 📜env.mk
┃ ┃ ┣ 📜platform.mk
┃ ┃ ┣ 📜rules_r4_TI_COMPILER.mk
┃ ┃ ┣ 📜rules_r5f.mk
┃ ┃ ┣ 📜rules_r5f_CLANG.mk
┃ ┃ ┣ 📜rules_r5f_DIAB.mk
┃ ┃ ┗ 📜rules_r5f_TI_COMPILER.mk
┃ ┣ 📜ccs_makefile
┃ ┣ 📜makefile
┃ ┗ 📜Rules.make
┣ 📂mcal
┃ ┣ 📂ModuleName
┃ ┃ ┣ 📂include
┃ ┃ ┣ 📂src
┃ ┃ ┣ 📂Vx
┃ ┃ ┗ 📜Makefile
┃ ┣ 📂autosar_include
┃ ┣ 📂examples
┃ ┃ ┣ 📂ModuleName
┃ ┃ ┃ ┣ 📂soc
┃ ┃ ┃ ┣ 📜ModuleNameApp.c
┃ ┃ ┃ ┣ 📜ModuleNameApp.h
┃ ┃ ┃ ┗ 📜Makefile
┃ ┃ ┣ 📂Utils
┃ ┃ ┃ ┗ 📜Makefile
┃ ┣ 📂examples_config
┃ ┣ 📂include
┃ ┣ 📜mcal_component.mk
┣ 📂mcal_config
┣ 📂mcal_docs
┗ 📜README.txt

makefile at Root level

Invoke configuration parameters, internal make files of libraries and examples of different modules for building the source code.

Rules.make

Dependent details for the Makefile to execute like Path for compiler, library, configurations are provided in Rules.mak. Default values for build environment, compiler and SOC are defined here. The build environment/Compiler/SOC will be chosen as Windows/CLANG/am263 if the user has not specified any. Rules.mak shall be included in the Makefile at Root level.

mcal_component.mk

Contains the mcal_libs and mcal_examples list which is build as part of building libs and examples respectively. The user can add or delete MCAL components that need to be built.

Makefile at MCAL driver level

All the source and header files of respective modules are included in the Module makefile to support build.

3.11.2. Build Steps

This section describes how to build the MCAL package. The package is built using “gmake” from Cygwin. Make sure that the Cygwin tools location is added to the PATH variable. Also, make file internally uses some binaries like rm, mkdir, echo etc. from Cygwin. Standard CCS installation comes with Cygwin, gmake and other utils as required to build MCAL modules.

Edit the Rules. Make file present in <MCAL_INSTALL_PATH>/build/Rules.make to give the appropriate paths for the tool chains and the current working directory. Make sure that CCS_PATH, and the TOOLCHAIN_PATH_R5 are updated with the proper path.

Edit paths for the below variables according to your system environment

1.In case of windows machine edit CCS path according to CCS version,

CCS_PATH := C:/ti/ccs1250/ccs
TOOLCHAIN_PATH_R5 := $(CCS_PATH)/Compilers/ti-cgt-armllvm_4.0.0.LTS

2.In case of Linux machine edit CCS path according to CCS version,

CCS_PATH := /opt/ti/ccs1250/ccs
TOOLCHAIN_PATH_R5 := $(CCS_PATH)/Compilers/ti-cgt-armllvm_4.0.0.LTS

3.By default the above are for CLANG compiler, modify respective paths accordingly for using other compilers.

4.Install dependencies required for MCELF image format
Install Python3
Install Pip
Make sure pyelftools and construct is installed from pip. This package is required for encrypting MCELF application images.
pip install pyelftools construct
Install openssl v3 from here https://slproweb.com/products/Win32OpenSSL.html

By default, MCAL package provides pre-generated config headers under <MCAL_INSTALL_PATH>/examples_config/<Module>_Demo_Cfg/soc/<SOC>/<Core>/include.

<SOC> should be with the following value(s): am263px in folder structure.

Go to <MCAL_INSTALL_PATH>/build directory and type below commands:

Description	Commands
Command to build all the libraries	gmake -s all PLATFORM=am263px
Command to build an application given in examples folder	gmake -s <app_name> PLATFORM=am263px app_name can be found in the make file of the respective examples folder.
Command to clean all targets	gmake -s clean PLATFORM=am263px
Command to clean individual targets	gmake -s $(target)_clean PLATFORM=am263px
Command to build an application for Resolver Package	gmake -s <app_name> PLATFORM=am263px PACKAGE=R
Command to build an application for Compatible Package	gmake -s <app_name> PLATFORM=am263px PACKAGE=C
Command to build an application for SIP Package	gmake -s <app_name> PLATFORM=am263px PACKAGE=SIP

3.11.3. Build Platform

PLATFORM makefile macro can take the name of the SOC which needs to be build. The possible values are as below

am263
am263px
am261

If no value is mentioned explicitly, it will take the default value as am263.

3.11.4. Build Package

Below packages are available for AM263Px.

SIP
C
R

User can build using below commands for the respective package:

gmake -s <app_name> PLATFORM=am263px PACKAGE=SIP for SIP package

gmake -s <app_name> PLATFORM=am263px PACKAGE=C for C package

gmake -s <app_name> PLATFORM=am263px PACKAGE=R for R package

3.11.5. Build Profiles

MCAL package can be built in two profiles:

Release Profile
Debug Profile

Users can build in mode by setting parameter PROFILE while building.

gmake all PLATFORM=am263px PROFILE=<release/debug>

PROFILE makefile macro can take either of the following values:

release for Release Profile
debug for Debug Profile

If PROFILE is not set during build, MCAL will be built for release profile by default.

To build all the examples and libraries in debug mode, you can give the following command.

gmake -s all PLATFORM=am263px PROFILE=debug

Similarly, PROFILE can be set in all the above build commands.

3.11.6. Multicore ELF Image Format

Note

By default, MCELF is OFF. User can enable it with the macro MCELF_ENABLE (yes/no) as yes.

Give the following command to enable MCELF:

gmake -s dio_app MCELF_ENABLE=yes

Multicore ELF, or MCELF is a new application image format different from the existing RPRC format. Unlike a proprietary format like RPRC, multicore elf is based on the widely recognized ELF (Executable and Linkable format) standard. This ensures seamless compatibility with industry-standard tools and platforms.
For more information on ELF format please refer: https://man7.org/linux/man-pages/man5/elf.5.html
For more information on MCELF image format please refer: AM263Px MCU SDK: Understanding Multicore ELF image format

3.11.7. Code Composer Studio (CCS)

3.11.7.1. Importing projects into CCS

📦AM263Px
┣ 📂build
┣ 📂mcal
┃ ┣ 📂autosar_include
┃ ┣ 📂examples
┃ ┃ ┣ 📂Can
┃ ┃ ┃ ┣ 📂soc
┃ ┃ ┃ ┃ ┣ 📂am263px
┃ ┃ ┃ ┃ ┃ ┣ 📂r5f0_0
┃ ┃ ┃ ┃ ┃ ┃ ┣ 📂ti-arm-clang\ ┃ ┃ ┃ ┃ ┃ ┃ ┃ ┗ 📜can_app.projectspec : Project template which can be imported into CCS
┃ ┃ ┃ ┃ ┃ ┃ ┣ 📜CanApp_Startup.c
┃ ┃ ┃ ┃ ┃ ┃ ┣ 📜CanApp_Startup.h
┃ ┃ ┃ ┣ 📜CanApp.c
┃ ┃ ┃ ┗ 📜Makefile
┃ ┃ ┣ 📂Utils
┃ ┣ 📂examples_config
┃ ┣ 📂include
┣ 📂mcal_config
┣ 📂mcal_docs
┗ 📜README.txt

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

Open CCS and select Import Project -

Fig. 3.11 CCS Import Step 1
Browse to the folder containing Projectspec file and select the desired CCS Project to be imported.

Fig. 3.12 CCS Import Step 2
Once project is imported you can continue to build and debug the project.

Fig. 3.13 CCS Project Imported

3.11.7.2. Loading generated executable file using CCS

Import any example project to CCS, right click on the xer5f file and select ‘Debug as Code Composer Debug Session’.

Fig. 3.14 CCS Loading Executable Step1
Right click on the Texas Instruments XDS110 USB Debug Probe/Cortex_R5_0 and ‘Connect Target’.

Fig. 3.15 CCS Loading Executable Step2
Go to Run - Load - Load Program.

Fig. 3.16 CCS Loading Executable Step3
Browse to the folder containing the generated executable, select the desired executable to be loaded and click on OK.

Fig. 3.17 CCS Loading Executable Step4
Once the executable is loaded you can continue to run and debug the project.

Note

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

3.11.7.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 AM263Px device family

3.12.1. AM26x CPU Architecture

Am263Px is a Single-core Arm® Cortex®-R5F MCU up to 400 MHz with real-time control and security. AM263Px combines up to four Cortex-R5F MCUs, a real-time control subsystem (CONTROLSS), a Hardware Security Module (HSM), and one instance of Sitara’s PRU-ICSS, making AM263Px designed for advanced motor control and digital power control applications.

The ARM Dual-Core Cortex-R5F processor subsystem (R5FSS) supports the following main features:

Armv7-R architecture
Support Dual Core mode, Single Core mode and Lockstep mode
Full-precision Floating Point (VFPv3)
4/8/16-region Memory Protection Unit (MPU)
8 breakpoints, 8 watch points
CoreSight Debug Access Port (DAP)
CoreSight ETM-R5 interface (CTI, ETM, ATB)
Performance Monitoring Unit (PMU)
Integrated Vectored Interrupt Manager (VIM) per core with 256 Interrupt Inputs each

3.13. Boot Modes

Note

–This section has more details on AM263PX-CC. This is mainly for reference. Make sure boot mode switch is setup to NOBOOT mode to use with CCS.

3.13.1. OSPI BOOT MODE

3.13.1.1. AM263PX-CC

This mode is used to boot flashed applications via EVM flash like OSPI flash.

BOOTMODE [ 1 : 4 ] (SW3) = 1100

3.13.1.2. AM263PX-LP

This mode is used to boot flashed applications via EVM flash like OSPI flash.

3.13.2. UARTBOOT MODE

3.13.2.1. AM263PX-CC

This mode is used to flash files to the EVM flash via UART. It can also be used to boot applications via UART.

BOOTMODE [ 1 : 4 ] (SW3) = 1000

3.13.2.2. AM263PX-LP

This mode is used to flash files to the EVM flash via UART. It can also be used to boot applications via UART.

3.13.3. NOBOOT MODE

3.13.3.1. AM263PX-CC

This mode is used in CCS.

BOOTMODE [ 1 : 4 ] (SW3) = 1101

3.13.3.2. AM263PX-LP

This mode is used in CCS.

3.14. Running the examples

Connect the CC or EVM board to your computer through JTag (USB Port)

Before running the binary file on target H/W follow the steps mentioned below:
Launch CCS, Go to View > Target Configuration
Create a new target configuration
Give a nice name to the new target configuration, typically {SOC name} _ {JTAG type}
Select connection as XDS110 USB Debug Probe
In “Board or Device” type “@VAR_SOC_NAME” and select “AM263Px”
Click “Save” to save the newly created target configuration.
Under Advanced tab – Select Cortex_R5_0
Make sure the device gel file path is in the Initialization script field (C:/ti/ccs1250/ccs/ccs_base/emulation/gel/AM263Px/AM263Px.gel)
Click “Save” to save the newly created target configuration
Launch the target configuration for AM263Px
Connect to Cortex_R5_0 core
Connect UART USB cable to the serial UART terminal (with appropriate port) and select UART1 serial port for viewing the UART logs and providing user input. By default, configuration may be matched by selecting baud rate as 115200, 8-bit Data Size, Parity None and 1 Stop Bit as the serial port settings.
Load binary files using Load Program option
Run the application and follow the prompts and output on CCS console/UART serial console.