‫دستورالعمل اولیه استفاده از بورد‬AM572x
‫محسن فاریابی‬

Building the SDK
o
o
o
o
Makefile and environment setup script are found in the RTOS SDK directory:
 [SDK Install Path]/processor_sdk_rtos_[soc]_[version]/
Setup Environment
 ~/ti/processor_sdk_rtos_[soc]_[version]$ source setupenv.sh
Top-Level Makefile
 all - This will call the build target for each component defined in the Makefile
 clean - This will call the clean target for each component defined in the Makefile
 pdk - Builds the Platform Development Kit that includes CSL and low level drivers
Rebuild PDK
 Navigate to pdk_[soc]_[version]/packages and Run pdksetupenv.sh
 ~/ti/pdk_[soc]_[version]/packages$ source pdksetupenv.sh
 entire PDK, or individual components, can be rebuilt through the top-level makefile
in pdk_[soc]_[version]/packages
 Discovering SDK products
 Add the path to the search path for CCS to locate the new packages.
1. From CCS, select “Window -> Preferences”,
2. In the Preferences window, select “Code Composer Studio -> RTSC > Products” Then, press the “Add” button,
3. verify the newly discovered products.
 PDK Example and Test Project Creation
 Starting CCS after installing the Processor SDK products will cause CCS to find
and register any new products.
 Navigate to pdk_[soc]_[version]/packages
 ensure that the pdkProjectCreate script has this location correctly specified
by updating the CCS_INSTALL_PATH
 When soc is “AM572x” and board is “all”, the script uses evmAM572x as the
default platform. Please specify board to idkAM572x to create the project for
AM572x IDK EVM.
 Run the pdkProjectCreate script.
o CCS projects created during the search will be placed into
~/ti/pdk_[soc]_[version]/packages/MyExampleProjects/ in Linux.


run example and/or unit test projects on C66x/A15 Target
o Import Project
Browse the top level directory where the project is present. For
example C:\ti\pdk_[soc]_[version]\packages\MyExampleProjects\.
Under the projects section you should see the project.
o Build Project
o Error for mono command:
 sudo apt install gnupg ca-certificates
 sudo
apt-key
adv
–keyserver
hkp://keyserver.ubuntu.com:80
--recv-keys
3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF
 echo
"deb
https://download.monoproject.com/repo/ubuntu stable-bionic main" | sudo tee
/etc/apt/sources.list.d/mono-official-stable.list
 sudo apt update
o Run Project
 Launch the Debugger and switch to the Debug Perspective.
 Click on Target -> Reset CPU
 Click on Target -> Load Program
 Select the executable file to be loaded. Example:
C:\ti\pdk_[soc]_[version]\packages\MyExampleProjects\GPI
O_LedBlink_AM572X_GpEvm_c66xExampleProject\Debug\
GPIO_LedBlink_evmAM572x_c66xExampleProject.out
Once the project is loaded; click on Target -> Run to execute.

Template Application Workshop
o
o
o
o
o
Software
 Processor SDK RTOS, CCS
 Install Latest Emulation Package and Sitara Device Support Package
 navigate to Help -> Check for Updates and select “Sitara device support” and
“TI Emulators” and click Next.
 Click “Next” again, select “I accept the terms of the license agreements” and
click Finish to begin the installation.
 Click “Restart Now” when prompted to complete the installation.

Hardware
 Sitara Evaluation Module, JTAG Debug Probe for AM572x EVM (XDS200), Serial UART
Components
 SYS/BIOS (RTOS only), XDCTools (RTOS only), Processor SDK RTOS PDK
Software Design
Importing and Building the Template Application
 go to the Project –> Import CCS Projects... menu
 import SDK projects from either the pdk_<platform>_<version> or
processor_sdk_rtos_<platform>_<version> directories
 pdk_<platform>_<version> directory contains Chip Support Library (CSL),
Low Level Drivers (LLDs), Boot, Diagnostics, and other functions. It is also
where LLD example projects are created.
 processor_sdk_rtos_<platform>_<version> directory contains demos
(including the Template App), documentation, and resources for creating
bootable SD cards.

o
locate
the
template
app
which
can
be
found
at:
processor_sdk_rtos_<platform>_<version>/demos/rtos_template_app/<soc_name>
/<evm_name>/<core_name>.
 Build Project
Loading and Running the Template Application
 Creating a Target Configuration File
 File –> New –> Target Configuration
 choose your connection and board: JTAG Debug Probe (for example, the
XDS200) and the board is the name of your EVM (either EVMAM3358,
EVMAM437X, or GPEVM_AM572x_SiRevA).
 Clike the Save button
 click Test Connection (The JTAG DR Integrity scan-test has succeeded.)
 Connecting to the Target
 set up the UART connection
 click on View –> Target Configurations in CCS
 right click on the target configuration and click Launch Selected Configuration
 In the top left corner of CCS you should see a list of all of the available cores
on your device. Right click on the primary core (listed below) and choose the
Connect Target option. During this process you should see GEL output in the
CCS console and the status of the core should change from “Disconnected”
to “Suspended”.
 For AM572x EVM, the template application can also run on the M4 and DSP
cores. If you intend to run the application on one of these cores you must still
connect to the main A15_0 core first. After connecting to the A15_0 core you
can then follow the same procedure as above to connect to the secondary
core where you would like to run the application. Do not attempt to load and
run the template application on two cores simultaneously.
 Typically the slave cores will wait in reset state until the master core wakes
up the slave core to run code. To connect to the slave core on AM57x, go to
Scripts menu in CCS Debug View and under AM572x MULTICORE Initialization
enable the corresponding sub system clock. For example, enable
DSP11SSClkEnable_API for the first DSP core. After running the clock enable
option, you can connect to the core.
 Running the Application
 Run –> Load –> Load Program menu in CCS
 click the Browse project... button and choose the [rtos or
baremetal]_template_app_<board>_<core>.out executable
 The application will begin running and print progress over the UART
 Examining the Template Application
 main.c file:
1. header files:
(RTOS only) XDCtools provides configuration tools to create and build
a static configuration as part of your application. These headers are
necessary for the *.cfg configuration files.
(RTOS only) BIOS is a synonym for TI-RTOS. These headers are
necessary for accessing common RTOS features such as tasks.
The Board Library is a thin utility layer on top of CSL and other board
utilities. It provides uniform Application Programming Interfaces
(APIs) for all supported boards. It aims to assist the user to quickly
write portable applications for supported boards by hiding board
level details from the user.
The app.h header file includes header files for drivers used in the
application code as well as macros and function prototypes.
Specifically, app.h includes headers for the following LLDs which are
used by the application:
/* Low level driver header files */
#include <ti/drv/gpio/GPIO.h>
#include <ti/drv/uart/src/UART_utils_defs.h>
#include <ti/drv/uart/UART_stdio.h>
#include <ti/drv/uart/UART.h>
#include <ti/drv/i2c/I2C.h>
#include <ti/drv/spi/MCSPI.h>
2. Initialize the board:
Board_initCfg boardCfg;
boardCfg =
BOARD_INIT_PINMUX_CONFIG |
BOARD_INIT_MODULE_CLOCK |
BOARD_INIT_UART_STDIO;
Board_init(boardCfg);
3. Intialize the peripherals:
UART_init();
I2C_init();
GPIO_init();
MCSPI_init();

4. (RTOS only) Create the application tasks. We will discuss this further
in the section covering the app.c file.
5. Start BIOS (RTOS) or start the application tasks directly (Bare-metal):
BIOS_start();
or
appRunTasks();
app.c File (RTOS)
1. Create task variables
Task_Params taskParams;

Error_Block eb;
Task_Handle task;
2. Initialize Error_Block and Task_Params to their default values
Error_init(&eb);
Task_Params_init(&taskParams);
3. Apply user arguments for stack name, priority, and stack size
taskParams.instance->name = taskName;
taskParams.priority = taskPriority;
taskParams.stackSize = stackSize;
4. Create the task
task = Task_create(taskFunctionPtr, &taskParams, &eb);
The tasks themselves are simply functions in your code following the
format below: void myTaskFunc(UArg arg0, UArg arg1)
App.c File (Bare-metal)
1. Create driver handle and params structure
I2C_Handle handle;
I2C_Params params;
2. Initialize and set the driver parameters
I2C_Params_init(&params);
params.transferMode = I2C_MODE_CALLBACK;
params.transferCallbackFxn = someI2CCallbackFunction;
// etc...
3. Open the driver
handle = I2C_open(someI2C_configIndexValue, &params);
if (!handle) {
System_printf("I2C did not open");
}
 IPC





Minimal use Scenario. (BIOS-to-BIOS only): This scenario performs inter-processor notification
using a Notify driver, which is used by the Notify module. This scenario is best used for simple
synchronization in which you want to send a message to another processor. you make API calls to
the Notify module such as Notify_sendEvent() function sends an event to the specified processor.
Data Passing Scenario (BIOS-to-BIOS only): you can use the ListMP module to share a linked list
between processors. In this scenario, you make API calls to the Notify and ListMP modules.
Dynamic Allocation Scenario (BIOS-to-BIOS only): To the previous scenario, you can add dynamic
allocation of ListMP elements using one of the Heap*MP modules.
Powerful But Easy-to-Use Messaging with MessageQ (HLOS and BIOS): In this scenario, you make
API calls to the MessageQ module. API calls made to the Notify, ListMP, and Heap*MP modules
in the previous scenarios are not needed. Instead, your application only needs to configure the
MultiProc and the SharedRegion modules.
The Ipc_start() API call configures all the necessary underlying modules
o Initializes a number of objects and modules used by IPC
o Synchronizes multiple processors so they can boot in any order
 SYS/BIOS







SYS/BIOS is a scalable real-time kernel. It is designed for applications that require real-time
scheduling and synchronization or real-time instrumentation. SYS/BIOS provides preemptive
multithreading, hardware abstraction, real-time analysis, and configuration tools. SYS/BIOS helps
minimize memory and CPU requirements on the target.
SYS/BIOS is the "TI-RTOS Kernel" component of the TI-RTOS product. Both names refer to the
same component.
TI-RTOS is a scalable, one-stop embedded tools ecosystem for TI devices. It scales from a realtime multitasking kernel (SYS/BIOS) to a complete RTOS solution including additional middleware
components and device drivers.
XDCtools provides the underlying core tooling needed by TI-RTOS and its components, including
SYS/BIOS. You must have both XDCtools and SYS/BIOS installed in order to use SYS/BIOS.
XDCtools is sometimes referred to as "RTSC" (pronounced "rit-see"—Real Time Software
Components), which is the name for the open-source project within the Eclipse.org ecosystem for
providing reusable software components (called "packages") for use in embedded systems.
You can picture the architecture of the tools used to create applications as shown in the following
figure. The xdc.runtime package provided by XDCtools contains modules and APIs your application
can use along with the modules and APIs in SYS/BIOS.
Configuring SYS/BIOS Using XDCtools
o It specifies the modules and packages that will be used by the application
o It can statically create objects for the modules that are used by the application.
o It validates the set of modules used to make sure they are compatible.
o It statically sets parameter, modules, and objects to change their runtime behavior.
o An application's configuration is stored in one or more script files with a file extension of
*.cfg. These are parsed by XDCtools to generate corresponding C source code, C header, and
linker command files that are then compiled and linked into the end application.
o


The configuration (*.cfg) file uses simple JavaScript-like syntax to set properties and call
methods provided by objects. You can create and modify a configuration file in the following
ways:
 Using the visual configuration tool (XGCONF) in CCS.
 Editing the text of the configuration in the cfg Script tab in the XGCONF editor in CCS
 Editing the *.cfg file directly with a text editor.
XDCtools Modules and Runtime APIs
o XDCtools contains several modules that provide basic system services your SYS/BIOS
application will need to operate successfully. Most of these modules are located in the
xdc.runtime package in XDCtools.
SYS/BIOS Packages and APIs
o Each SYS/BIOS package provides one or more modules. Each module, in turn, provides APIs
for working with that module.
o
o

In order to use a module, your application must include the standard SYS/BIOS header file and
the header file for that module.
Several modules support the creation of instance objects. Such modules include Hwi, Task,
Swi, Semaphore, Mailbox, Queue, Event, Clock, Timer, and various types of Gate and Heap
modules. For example, the Task module allows you to create several Task objects. Each Task
object corresponds to a thread that has its own function, priority, and timing.
 Static creation allows you to specify the object in the application’s *.cfg file. No heap
is needed if you are statically allocating objects. A structure for the object is added to
the source file generated for the configuration.
SYS/BIOS Startup Sequence
o The SYS/BIOS startup sequence is logically divided into two phases—those operations that
occur prior to the application's "main()" function being called and those operations that are
performed after the application's "main()" function is invoked.
 The "before main()" startup sequence is governed completely by the XDCtools runtime

package.
The "after main()" startup sequence is governed by SYS/BIOS and is initiated by an
explicit call to the BIOS_start() function at the end of the application's main() function.
The SYS/BIOS startup sequence that run when BIOS_start() is called is as follows:
1. Startup Functions. Run the user-supplied "startup functions" (see
BIOS.startupFxns). If the system supports Timers, all statically created timers
are initialized at this point using their static configuration. If a timer was
configured to start "automatically," it is started here.
2. Enable Hardware Interrupts.
3. Enable Software Interrupts.
4. Task Startup. If the system supports Tasks hen task scheduling begins
here. If there are no statically or dynamically created Tasks in the system, then
execution proceeds directly to the idle loop

Threading Modules
o The thread types (from highest to lowest priority) are:
 Hardware interrupts (Hwi), which includes Timer functions
 Software interrupts (Swi), which includes Clock functions
 Tasks (Task)
 Background thread (Idle)
o