10.1. Target

10.1.1. Run IPC Examples on AM572x

10.1.1.1. DRA7xx/AM572xx IPC Examples

IPC Hello Example:

ex01_hello


The following examples demonstrate some of the rudimentary IPC capabilities. They are mostly two processors examples. These examples may be built for any two processors on your device, but only for two at a time. An IPC Ping example using three processors is also presented at the end.

Hello example uses the reader/writer design pattern. One processor will be the reader and the other will be the writer. The reader creates a message queue and waits on it for messages. The writer opens the reader’s message queue and sends messages to it. The writer allocates the message from a shared message pool and the reader returns the message to the pool. Thus, messages are sent in only one direction. Default settings of the Hello world example configures DSP1 as the writer and DSP2 as the reader.

Note

if Windows 7 machine is used for building these examples, GnuWin32 make utility needs to be installed to run make which can be downloaded from this link http://gnuwin32.sourceforge.net/packages/make.htm

Set GnuWin32\bin folder on file path and add a system variable XDCTOOLS_JAVA_HOME to point to “c:\ti\ccsv6\eclipse\jre

set PATH=<YOUR_PROCEEDING_PATH>\GnuWin32\bin;%PATH%
set XDCTOOLS_JAVA_HOME=c:\ti\ccsv6\eclipse\jre

1. Change to the example folder by entering: cd ~/ti/ipc_nn_nn_nn_nn/examples/DRA7xx_bios_elf/ex01_hello

2. Open readme.txt file and follow build instructions step-by-step. If build this example on Ubuntu PC, make sure there is no spaces between variable name and its value.


DEPOT (your depository folder ex: DEPOT=/Your_Ubuntu_home_folder/ti)
BIOS_INSTALL_DIR=$(DEPOT)/bios_n_nn_nn_nn
IPC_INSTALL_DIR=$(DEPOT)/ipc_n_nn_nn_nn
XDC_INSTALL_DIR=$(DEPOT)/xdctools_n_nn_nn_nn
gnu.targets.arm.A15F=$(DEPOT)/ccsv6/tools/compiler/gcc-arm-none-eabi-4_8-2014q3
ti.targets.elf.C66=$(DEPOT)/ccsv6/tools/compiler/c6000_7.4.14
ti.targets.arm.elf.M4=$(DEPOT)/ccsv6/tools/compiler/arm_5.2.4
ti.targets.arp32.elf.ARP32_far=$(DEPOT)/ccsv6/tools/compiler/arm_5.2.4
See the following example, and ensure you are using the latest version
of folder names present in ~/ti folder:

DEPOT=/home/Your_Ubuntu_home_folder/ti

# Use the following environment assignment  (Note you must use 32 bit Java even in Ubuntu 14.04 64 bit OS environment)
export XDCTOOLS_JAVA_HOME=/home/Your_Ubuntu_home_folder/ti/ccsv6/eclipse/jre

#### BIOS-side dependencies ####
BIOS_INSTALL_DIR=$(DEPOT)/bios_6_41_04_54
IPC_INSTALL_DIR=$(DEPOT)/ipc_3_36_01_11
XDC_INSTALL_DIR=$(DEPOT)/xdctools_3_31_02_38

#### BIOS-side toolchains ####
gnu.targets.arm.A15F=$(DEPOT)/ccsv6/tools/compiler/gcc-arm-none-eabi-4_8-2014q3
ti.targets.elf.C66=$(DEPOT)/ti-cgt-c6000_8.0.3
ti.targets.arm.elf.M4=$(DEPOT)/ccsv6/tools/compiler/ti-cgt-arm_5.2.4
ti.targets.arp32.elf.ARP32_far=$(DEPOT)/ccsv6/tools/compiler/ti-cgt-arm_5.2.4
  1. Run make command in current folder to build DSP1 and DSP2 hello examples. Output files are created under debug sub folders.
  • ex01_hello\dsp1\bin\debug
  • ex01_hello\dsp2\bin\debug
  1. Launch target configurations.
  2. Right click CortexA15_0 and connect target.
  3. On CCS –> Scripts –> AM572 Multicore Initialization –> Run AM572x Multicore EnableAllCore
  4. Initialize DDR configuration. On CCS –> Scripts –> DDR configurations –> AM572_DDR3_532MHz_config
  5. Load DSP1 Hello Example hello_dsp1.xe66 (writer)file on DSP1.
  6. Load DSP2 Hello Example hello_dsp2.xe66 (reader) file on DSP2.
  7. Run both DSP1 and DSP2.
  8. On CCS –> Tools –> RTOS Object view (ROV).
  9. Suspend (halt) DSP1 to view test messages on ROV Viewable Modules –>LoggerBuf Refer below image of ROV log messages.
../_images/Hello_dsp2.png
  1. Suspend (halt) DSP2 and click on ROV icon to view log messages.

IPC Message Queue Example:

ex02_messageq

Message queue example sends round-trip message from client to server and back. MessageQ example uses client/server pattern. It is a two processors example: the HOST and DSP processors. Either DSP1 or DSP2 can be built for testing.

The DSP processor is configured as server. It creates a named message queue. The server does not open any queues because it extracts the return address from the message header. The server returns all messages to the sender. It does not access the message pool.

The HOST processor is configured as client application. The client creates an anonymous message queue. The client also creates and manages the message pool. The client’s return address is set in the message header for each message before sending it to the server.

  1. Change to messageQ folder example by enter:

    cd ~/ti/ipc_nn_nn_nn_nn/examples/DRA7xx_bios_elf/ex02_messageQ

2. Open readme.txt file and follow build instructions step-by-step. Make sure there is no spaces between variable name and its value. See Hello World example environment varaible settings for reference.

  1. Run make command in current folder to build DSP1 and HOST hello examples. Output files are created under debug sub folders
  • ex02_messageq\host\bin\debug : HOST A15 binary
  • ex02_messageq\dsp1\bin\debug : C66x binary
  1. Launch target configurations. Note that BH560USB_M is emulator is used to connect to AM572X EVM.
  2. Right click CortexA15_0 and connect target.
  3. On CCS –> Scripts –> AM572 Multicore Initialization –> Run AM572x Multicore EnableAllCore
  4. Initialize DDR configuration. On CCS –> Scripts –> DDR configurations –> AM572_DDR3_532MHz_config
  5. Load DSP1 messageQ Example out file(server_dsp1.xe66) onto DSP1.
  6. Load HOST messageQ Example out file(app_host.xa15fg) onto ARM CortexA15_0.
  7. Run both DSP1 and HOST.
  8. On CCS –> Tools –> RTOS Object view (ROV).
  9. Suspend (halt) ARM Cortex_A15 to view test messages on ROV Viewable Modules –>LoggerBuf Refer the following ROV message queue screenshot
../_images/MesgQ_arm0.png
  1. Suspend (halt) DSP1 and click on ROV icon to view log messages.

IPC Notify Peer Example:

ex13_notifypeer

Notify peer example only uses notify to communicate to a peer processor. This is an example of IPC Scalability. It uses the client/server design pattern. Initially, the example builds only for two processors: HOST and DSP1. The client runs on HOST and the server runs on DSP1.

The client (HOST) creates an anonymous message queue. The client also creates and manages its own message pool. And it opens the server message queue using its name. The client initiates the data flow by allocating a message from the pool, placing its return address in the message header and sending the message to the server. It then waits for the message to be returned. When it receives the return message, the message is returned to the pool. The client repeats this in a loop.

The server (DSP1) creates a named message queue, then waits on it for messages. When a message arrives, the server performs the requested work. When the work is done, the server extracts the return address from the message header and sends the message back to the client. The server never opens any message queues and does not access the message pool.

Since DSP1 will need to wait on both the message queue and the notify queue, we introduce events. The SYS/BIOS event object can be used to wait on multiple input sources.

  1. Change to notify_peer folder example by enter: cd ~/ti/ipc_nn_nn_nn_nn/examples/DRA7xx_bios_elf/ex13_notifypeer
  2. Open readme.txt file and follow build instructions step-by-step. Make sure there is no spaces between variable name and its value.
  3. Run make command in current folder to build DSP1 and HOST notifypeer examples. Output files are created under debug subfolder.
  4. Launch target configurations. Note that BH560USB_M is emulator is used to connect to AM572X EVM.
  5. Right click CortexA15_0 and connect target.
  6. On CCS –> Scripts –> AM572 Multicore Initialization –> Run AM572x Multicore EnableAllCore
  7. Initialize DDR configuration. On CCS –> Scripts –> DDR configurations –> AM572_DDR3_532MHz_config
  8. Load DSP1 notifypeer Example out file on DSP1.
  9. Load HOST notifypeer Example out file on ARM CortexA15_0.
  10. Run both DSP1 and CortexA15_0.
  11. On CCS –> Tools –> RTOS Object view (ROV).
  12. Suspend (halt) ARM CortexA15_0 to view test messages on ROV Viewable Modules –>LoggerBuf. Refer the following image of ROV log messages
../_images/Notify_peer_arm0.png
  1. Suspend (halt) DSP2 and click on ROV icon to view log messages.

IPC Ping Example:

ex11_ping

ping example sends a message between all cores in the system. This example is used to exercise every communication path between all processors in the system (including local delivery on the current processor). Ping example is also organized in a suitable manner to develop an application with different compute units on each processor.

Each executable will create two tasks: 1) the server task, and 2) the application task. The server task creates a message queue and then waits on that queue for incoming messages. When a message is received, the server task simply sends it back to the original sender.

The application task creates its own message queue and then opens every server message queue in the system (including the server queue on the local processor). The task sends a message to a server and waits for the message to be returned. This is repeated for each server in the system (including the local server).

Note

Note that presently EVE is not yet supported and therefore, DSP1/DSP2/HOST are built for testing.

1. Change to ping folder example by enter: cd ~/ti/ipc_nn_nn_nn_nn/examples/DRA7xx_bios_elf/ex11_ping

2. Open readme.txt file and follow build instructions step-by-step. Make sure there is no space between variable name and its value.

  1. Open makefile and remove EVE and IPU from PROC build list.
  2. Run make command in current folder to build DSP1, DSP2 and HOST ping examples. Output files are created under debug subfolder.
  3. Launch target configurations. Note that BH560USB_M is emulator is used to connect to AM572X EVM.
  4. Right click CortexA15_0 and connect target.
  5. On CCS –> Scripts –> AM572 Multicore Initialization –> Run AM572x Multicore EnableAllCore
  6. Initialize DDR configuration. On CCS –> Scripts –> DDR configurations –> AM572_DDR3_532MHz_config
  7. Load DSP1 Ping Example out file on DSP1.
  8. Load DSP2 Ping Example out file on DSP2.
  9. Load HOST ping Example onto ARM CortexA15_0
  10. Run DSP1, DSP2, and HOST images.
  11. On CCS –> Tools –> RTOS Object view (ROV).
  12. Halt DSP1 to view test messages on ROV Viewable Modules –>LoggerBuf Refer below image of ROV log messages
../_images/Ping_dsp1.png
  1. Suspend (halt) DSP2 and click on ROV icon to view log messages.
  2. Suspend (halt) ARM CortexA15_0 and click on ROV icon to view log messages.

Expanding IPC Ping Example:

To demonstrate the flexibility of IPC architecture, you may include additional cores to the above example by modifying the make file. For example, you may add IPU1 in the list of processor in the make file as: DSP1, DSP2, IPU1, HOST. After a clean build, the appropriate configuration and output executable files will be generated that allow passing messages between DSP1, DSP2, IPU1 and Host. Procedures are the same as described in the previous example with the exception of additional steps to load the IPU1 core with the corresponding executable and running it in conjunction with DSP1, DSP2 and HOST.

Note

During build process using IPU1, you may encounter a message indicating rtsv7M4_T_le_eabi.lib library is missing. This is a know issue and is being tracked by SDCOM00118417 IR. However, you may create this missing library by going to the compiler installation’s lib directory and execute the following command to regenerate all required libraries:

./mklib --all

The following example depicts a typical host communications protocol with other IPC apps (dsp1, dsp2, ipu1) Note that the following HOST communications list has been rearranged to further clarify the type of communications between various cores. Typically these messages arrive at different intervals depending on each core processes execution time.

1    xdc.runtime.Main    --> main:
2    xdc.runtime.Main    main: ipc ready
3    xdc.runtime.Main    MainHost_svrTskFxn:
4    SvrHost    --> SvrHost_setup:
5    SvrHost    SvrHost_setup: slave is ready
6    SvrHost    <-- SvrHost_setup:
7    SvrHost    --> SvrHost_run:
8    xdc.runtime.Main    --> MainHost_appTskFxn:
9    AppHost    --> AppHost_setup:

10    AppHost    AppHost_setup: procId=0     opened server queue
11    AppHost    AppHost_setup: procId=1     opened server queue
12    AppHost    AppHost_setup: procId=2     opened server queue
28    AppHost    AppHost_setup: procId=3     opened server queue

32    AppHost    AppHost_run: ping procId=0
34    AppHost    AppHost_run: ping procId=0
36    AppHost    AppHost_run: ping procId=0
38    AppHost    AppHost_run: ping procId=0
40    AppHost    AppHost_run: ping procId=0

33    AppHost    AppHost_run: ack received     procId=0
35    AppHost    AppHost_run: ack received     procId=0
37    AppHost    AppHost_run: ack received     procId=0
39    AppHost    AppHost_run: ack received     procId=0
41    AppHost    AppHost_run: ack received     procId=0

13    SvrHost    SvrHost_run: message received     procId=0
14    SvrHost    SvrHost_run: message received     procId=0
15    SvrHost    SvrHost_run: message received     procId=0
16    SvrHost    SvrHost_run: message received     procId=0
17    SvrHost    SvrHost_run: message received     procId=0

42    AppHost    AppHost_run: ping procId=1
44    AppHost    AppHost_run: ping procId=1
46    AppHost    AppHost_run: ping procId=1
48    AppHost    AppHost_run: ping procId=1
50    AppHost    AppHost_run: ping procId=1

43    AppHost    AppHost_run: ack received     procId=1
45    AppHost    AppHost_run: ack received     procId=1
47    AppHost    AppHost_run: ack received     procId=1
49    AppHost    AppHost_run: ack received     procId=1
51    AppHost    AppHost_run: ack received     procId=1

18    SvrHost    SvrHost_run: message received     procId=1
19    SvrHost    SvrHost_run: message received     procId=1
20    SvrHost    SvrHost_run: message received     procId=1
21    SvrHost    SvrHost_run: message received     procId=1
22    SvrHost    SvrHost_run: message received     procId=1

52    AppHost    AppHost_run: ping procId=2
55    AppHost    AppHost_run: ping procId=2
58    AppHost    AppHost_run: ping procId=2
61    AppHost    AppHost_run: ping procId=2
64    AppHost    AppHost_run: ping procId=2

54    AppHost    AppHost_run: ack received     procId=2
57    AppHost    AppHost_run: ack received     procId=2
60    AppHost    AppHost_run: ack received     procId=2
63    AppHost    AppHost_run: ack received     procId=2
66    AppHost    AppHost_run: ack received     procId=2

53    SvrHost    SvrHost_run: message received     procId=2
56    SvrHost    SvrHost_run: message received     procId=2
59    SvrHost    SvrHost_run: message received     procId=2
62    SvrHost    SvrHost_run: message received     procId=2
65    SvrHost    SvrHost_run: message received     procId=2

67    AppHost    AppHost_run: ping procId=3
69    AppHost    AppHost_run: ping procId=3
71    AppHost    AppHost_run: ping procId=3
73    AppHost    AppHost_run: ping procId=3
75    AppHost    AppHost_run: ping procId=3

68    AppHost    AppHost_run: ack received     procId=3
70    AppHost    AppHost_run: ack received     procId=3
72    AppHost    AppHost_run: ack received     procId=3
74    AppHost    AppHost_run: ack received     procId=3
76    AppHost    AppHost_run: ack received     procId=3

23    SvrHost    SvrHost_run: message received     procId=3
24    SvrHost    SvrHost_run: message received     procId=3
25    SvrHost    SvrHost_run: message received     procId=3
26    SvrHost    SvrHost_run: message received     procId=3
27    SvrHost    SvrHost_run: message received     procId=3

29    AppHost    AppHost_setup: slave is ready
30    AppHost    <-- AppHost_setup:
31    AppHost    --> AppHost_run:
77    AppHost    <-- AppHost_run: 0
78    AppHost    --> AppHost_destroy:
79    AppHost    <-- AppHost_destroy: status=0
80    xdc.runtime.Main    <-- MainHost_appTskFxn: 0
81    xdc.runtime.Main    MainHost_done:

10.1.2. Run IPC Examples on AM65XX

10.1.2.1. AM65xx IPC Examples

In the processor SDK release ipc examples can be built from the Processor SDK top level makefile.

See link for building IPC examples

ipc-rtos-examples

Once the examples are built, they can be run by loading and running the binaries using CCS through JTAG. Please refer to the section “Advanced AM65x Debug Setup with DMSC Firmware Load” of the TMDX654 EVM Hardware Setup Guide for setting up the JTAG.

Advanced AM65x Debug Setup with DMSC Firmware Load

IPC Message Queue Example:

ex02_messageq

Message queue example sends round-trip message from client to server and back. MessageQ example uses client/server pattern. It is a two processors example: the HOST and R5F-0 processor.

The R5F-0 processor is configured as server. It creates a named message queue. The server does not open any queues because it extracts the return address from the message header. The server returns all messages to the sender. It does not access the message pool.

The HOST processor is configured as client application. The client creates an anonymous message queue. The client also creates and manages the message pool. The client’s return address is set in the message header for each message before sending it to the server.

Here are the steps to run the example.

  1. Follow instructions above to build the IPC examples. The build will create the R5F-0 and HOST binaries under debug and release sub folders For example
  • AM65XX_bios_elf\ex02_messageq\host\bin\debug\app_host.xa53fg : HOST A15 binary
  • AM65XX_bios_elfex02_messageq\r5f-0\bin\debug\server_r5f-0.xer5fg : R5 binary
  1. Follow procedure to initialize platform and launch target configuration through steps outlined in the hardware setup guide referred above.
  2. Right click R5 core 0 and connect target.
  3. Load R5F-0 messageQ Example out file(server_r5f-0.xer5fg) onto R5F core 0.
  4. Right click CortexA53_0 and connect target.
  5. Load HOST messageQ Example out file(app_host.xa53fg) onto ARM CortexA53_0.
  6. Run both R5F-0 and HOST.
  7. On CCS –> Tools –> RTOS Object view (ROV).
  8. Suspend (halt) ARM Cortex_53 to view test messages on ROV Viewable Modules –>LoggerBuf
  9. Suspend (halt) R5F-0 and click on ROV icon to view log messages.

10.1.3. Taking the C66x Out Of Reset with Linux Running on the ARM A15

10.1.3.1. How to take the C66x DSP out of reset with Linux running on A15

This document describes the procedure to bring the C66x core out of reset after booting Linux, or at the u-boot prompt.These steps are necessary in to order to load an application on the C66x core, without interfering with the operation of Linux running on the A15.

Note

Prior to proceeding with the below instructions, please ensure that the latest Emulation Package is downloaded/installed through CCS. This will ensure the GEL files in your machine has the reset routines described below.

  1. Once Linux has booted, launch the target configuration.
../_images/Outofreset_1_lali.JPG
  1. With the target configuration launched, right click on K2x.ccxml and select “Show all cores”
../_images/Outofreset_2_lali.JPG
  1. This will bring up the Non-Debuggable Devices section. Right click and connect the CS_DAP_Debug_SS core.
../_images/Outofreset_3_lali.JPG
  1. Go to Tools>GEL files and load the evmk2x.gel file by right clicking on the GEL file window. The Gel file would typically be located in the CCS installation under \ccsv6\ccs_base\emulation\boards\evmk2x\gel\
../_images/Outofreset_4_lali.png
  1. Once the GEL has been successfully loaded, go to Scripts>default and select K2x_TakeDSPOutofReset.
../_images/Outofreset_5_lali.png
  1. At this point the console would indicate that the DSP is out of reset.
../_images/Outofreset_6_lali.png
  1. Now the DSP cores can be right-clicked and connected successfully.
../_images/Outofreset_7_lali.png

10.1.3.2. Target Configuration

Note

Once the DSP core is connected following the above out of reset routine, the DDR and PLL settings done by u-boot would be overwritten by what’s in the GEL. In order to avoid this, please ensure that the gel is NOT preloaded on the DSP core in the ccxml by leaving the initialization script blank.

../_images/Outofreset_8_lali.JPG

10.1.4. RTOS Customization: using an external input to trigger an interrupt on AM57x

This note explains how to develop an example using a General-Purpose Input/Output (GPIO) pin to capture an external input event and generate an interrupt by modifying an existing RTOS GPIO driver LED blinking example. The hardware setup, software development procedures and testing are done using TI AM572x IDK EVM. The same process can be extended to other TI Sitara devices, TI EVMs or custom platforms as well.

10.1.4.1. Hardware

The AM572x Industrial Development Kit (IDK) is used here for developing the example. The same expect to work with the AM574x IDK as well.

From the AM572x IDK EVM hardware user guide, the card has 3 push buttons: SW1, SW2 and SW3, but they all are used for different purposes. However, the card has a 60-pin female expansion connector J21, pins that are not used may be dedicated for GPIO input test purpose. Here J21 pin 4 is selected based on the following analysis:

  • The Pin 4 signal is labeled as GPMC_CS0 and is connected to AM572x chip ball T1 as shown in the schematic:
../_images/J21_gpio_input.png ../_images/gpmc_cs0_t1.png
  • From the AM5728 datasheet, T1 ball can be configured as GPMC_CS0 or GPIO2_19 based on different PINMUX modes.

10.1.4.2. Software

The GPIO LED blink example is served as the reference example and the test is developed on the ARM A15 core, it should work for other cores. This section discusses several typical steps involved in the software development work:

  • PinMux configuration
  • PRCM setup
  • Re-build board library
  • Application software development

PinMux configuration

The default PinMux file has to be modified for GPIO2_19 pin usage:

  • Use the PinMux Utility to open the default PinMux file pdk_am57xx_1_0_x\packages\ti\board\src\idkAM572x\idkAM572x_SR2.0.pinmux (for the latest Rev 1.3B EVM)
  • Select GPIO, then MyGPIO2:
../_images/pinmux_gpio_1.png
  • Then, scroll down, set gpio2_19 with ball #T1, pull up and Rx direction.
  • Finally, select Category filter as “SR2.0 – Platform Development Kit (PDK) and download the generated files.
../_images/pinmux_gpio_2.png
  • Four new files should be generated, with the only difference being a new pin configuration added in boardPadDelayInit.c file:
 /* GPIO2 - gpio2_19 on T1 - MyGPIO2 */
{0x14B4, 0x6000E, {0x0, 0, 0}, {0x0, 0, 0}, {0x0, 0, 0}},
  • Replace the same files under pdk_am57xx_1_0_x\packages\ti\board\src\idkAM572x with the new ones.

PRCM setup

Setup of the Power, Reset and Clock Management (PRCM) domain for newly added GPIO2 is required. The application code calls Board_init() API with a BOARD_INIT_MODULE_CLOCK flag to enable the clock domain. It is implemented in the Board_moduleClockInit() function inside pdk_am57xx_1_0_x\packages\ti\board\source\idkAM572x\idkAM572x_clock.c. It is found that GPIO2 is enabled already and no further code needed.

Re-build board library

The board library must be recompiled for the changes to take effect. This has several major steps:

  • Setup the build environment by running setupenv script
  • Build the library with make command (e.g. “make board”) and the output will be under pdk_am57xx_1_0_x\packages\ti\board\lib\idkAM572x\a15\release

10.1.4.3. Application software development

The GPIO LED blinking example (GPIO_LedBlink_idkAM572x_armTestProject) is used as the reference. The CCS project can be created by using pdkprojectcreate script, such as “pdkprojectcreate AM572x idkAM572x little gpio all arm”. Check PDK Example and Test Project Creation for details.

This LED blink example uses 2 GPIO pins. The first pin is used to periodically generate an interrupt. The second pin is an output pin connected to an onboard LED, which toggles between low and high inside the interrupt ISR, thus driving the LED. Note the first pin doesn’t accept any external input, but using software to write a register (GPIO_IRQSTATUS_RAW_n) to generate interrupt.

Also note from GPIO_idkAM572x_board.c, the rising edge is configured to generate interrupt:

GPIO_PinConfig gpioPinConfigs_1p3[] = {
  /* Input pin with interrupt enabled */
  GPIO_DEVICE_CONFIG(GPIO_GRN_LED_PORT_NUM_1P3, GPIO_GRN_LED_PIN_NUM_1P3) |
  GPIO_CFG_IN_INT_RISING | GPIO_CFG_INPUT,
 }

After understanding how the reference example works, the code can be modified to use the first pin to receive external input and trigger the interrupt, then the second pin works the same way to toggle the LED, visualizing the event input.

Code modifications: • GPIO_board.h: this file defines the GPIO pins for the test, the first pin needs to be updated

#define GPIO_INTR_LED_BASE_ADDR_1P3      (CSL_MPU_GPIO2_REGS)
#define GPIO_LED_PIN_NUM_1P3             (0x13U)
  • GPIO_idkAM572x_board.c: this file also defines the GPIO pins for the test, the first pin needs to be updated
/* GPIO Definitions specific Rev1p3 Board */
/* GPIO pin number connected to the green LED */
#define GPIO_GRN_LED_PIN_NUM_1P3    (0x13)

/* GPIO port number connected to the green LED */
#define GPIO_GRN_LED_PORT_NUM_1P3   (0x02)
  • main_led_blink.c: this is the main test program. The change is high-lighted in black, while the original code is in grey.
  1. Inside void gpio_test(UArg arg0, UArg arg1) routine there is a while(1) loop that continuously triggers the interrupt by software write. Since the new example relies on the external input event to trigger it, one can simply add another while(1) in front of it to block the original loop:
while(1);  //New added loop
while(1)
    {
            if defined(SOC_AM574x) || defined(SOC_AM572x) || defined(SOC_AM571x)|| defined(SOC_AM335x) || defined(SOC_AM437x)
            #if defined (idkAM572x) || defined (idkAM574x)
              ….
}
  1. Also inside the same void gpio_test(UArg arg0, UArg arg1) routine, one may add a debounce control before the test loop:
/* Write high to gpio pin to control LED1 */
GPIO_write((USER_LED1), GPIO_PIN_VAL_HIGH);

/* Add new debounce code here */
GPIOAppUpdateConfig(&gpioBaseAddr, &gpioPin);
GPIODebounceFuncControl(gpioBaseAddr, gpioPin, 1);
GPIODebounceTimeConfig(gpioBaseAddr, 255);

AppDelay(DELAY_VALUE);

GPIO_log("\n GPIO Led Blink Application \n");

After all the code changes, rebuild the test application. A GPIO_LedBlink_idkAM572x_armTestProject.out should be generated.

10.1.4.4. Test

Test Setup The test setup using AM572x IDK EVM is depicted below:

../_images/gpio_test.png
  • The EVM is powered with a +5V power supply
  • A micro USB cable is connected to the host PC for on-board XDS100v2 JTAG connection and UART console.
  • A wire is connected to J21 pin4 as the event input. Another wire is connected to J21 pin 60 as the digital ground. When the two wires touch each other, pin 4 goes low, creating a GPIO falling edge. On the other hand, when the two wires are not touching, pin 4 goes high, creating a GPIO rising edge.

Test Procedure

  • Connect to the A15_0 with a JTAG emulator and use the default GEL file to initialize the SOC.
  • Load the test application (GPIO_LedBlink_idkAM572x_armTestProject.out) and run.
  • Touch the two wires, then un-touch, the LED should flip the status and keep steady until next touch, un-touch cycle.

10.1.5. Run applications from DDR on R5 cores

Once the R5 core is out of reset, the R5 defaults to no execute permissions for the DDR memory space. The side effect of this is, that all code, from entry point till the code that sets up the MPU (Memory Protection Unit), has to be run from internal memory.

10.1.5.1. Run BIOS Applications from DDR on R5

In BIOS, the application sets up the MPU as per the memory configuration specified in the *.xs file (that is referred to in the applications bios config file). Once the MPU is setup by the app, the rest of the code can run from DDR.

To ensure that all code from entry point to MPU setup is run from internal memory, the text sections of the following libs must be placed in internal memory using the application’s linker command file.

  • *sysbios.aer5f(.text)
  • *boot.aer5f(.text)
  • *auto_init.aer5f(.text)
  • *<app>_per5f.oer5f(.text)

Refer emac_linker_r5.lds for an example.

Note

Please note that you need to replace *<app>_per5f.oer5f with the corresponding file for your application. For eg, if the application’s .cfg file is emacUnitTest_r5.cfg, then the .oer5f file will be named emacUnitTest_r5_per5f.oer5f

You also need to update the *.xs file referred to by the applications .cfg file to make sure that the DDR has execute privileges. Please refer r5_mpu.xs for an example memory configuration. You could also make the applications .cfg file refer to the common .xs file, as shown in the example emacUnitTest_r5.cfg.

Warning

Once you update the .xs file, please note remember to delete *<app>_per5f.oer5f from the applications *configuro directory, so that it is autogenerated again. If you simply do a clean build, *<app>_per5f.oer5f will not be updated to reflect the changes in the *.xs file.

10.1.5.2. Run Baremetal Applications from DDR on R5

Baremetal applications have similar restrictions on running code from internal memory till the MPU is configured, just like BIOS applications. For best comaptibility, however, make sure that the entry point is always the reset vector, and that the code that sets up the DDR access permissions in the MPU resides completely within 0x100 bytes of the entry point.

For applications that find the default R5 configuration setup by the CSL sufficient, there is another method that can be used to execute an application from DDR. If the bootloader (SBL) is re-built using the SBL_SKIP_MCU_RESET compile option (by enabling the corresponding line in sbl_component.mk, then SBL will branch to the application entry point without resetting the R5 core.

In this scenario, as the R5 core was already setup when the SBL invoked CSL init, the app can execute directly from DDR, right from its entry point. However, the app must take care not to redo the R5 initialization using CSL init, as the CSL initialization code assumes that the R5 registers are at their reset default values. This can be done by simply defining an empty __mpu_init function in the baremetal application. Refer sbl_smp_r5.asm for an example.

10.2. Host

10.2.1. Setup

10.2.1.1. Setup CCS for EVM and Processor-SDK RTOS

10.2.1.1.1. Overview

This page provides information on configuring CCS to work with both the EVM and the Processor-SDK for RTOS.

10.2.1.1.2. Discovering SDK products

10.2.1.1.2.1. CCS and SDK installed in same directory

After installing the Processor-SDK RTOS, start CCS and it will automatically detect the newly installed components (products):

../_images/CCS-discovered-products.png

10.2.1.1.2.2. CCS and SDK installed in different directories

If you chose to install the SDK package in a different folder from where CCS is installed (e.g. C:\TEMP\RTOS-SDK\am57x), then you will need to add the path to the search path for CCS to locate the new packages. The screenshots below demonstrate the process to setup the CCS environment; the sequence for a Linux host is the same.

10.2.1.1.2.2.1. Go to product preference

From CCS, select “Window -> Preferences”:

../_images/CCS-GP57x-EVM-Custom-Preferences.png

10.2.1.1.2.2.2. Enter path to SDK

In the Preferences window, select “Code Composer Studio -> RTSC -> Products” in the panel on the left. Then, press the “Add” button on the panel on the right:

../_images/CCS-GP57x-EVM-Custom-Add.png

10.2.1.1.2.2.3. Verify components

Next, verify the newly discovered products. If everything is correct, press the “Finish” button on the bottom:

../_images/CCS-GP57x-EVM-Custom-Finish.png

10.2.1.1.2.2.4. Restart CCS

When prompted, restart CCS for changes to take effect. You will see newly discovered products from the custom path.

../_images/CCS-GP57x-EVM-Custom-Confirm.png

10.2.1.1.2.3. Install Latest Emulation Package and Sitara Device Support Package

1. In CCS, navigate to Help -> Check for Updates and select “Sitara device support” and “TI Emulators” and click Next.

../_images/CCS_Check_for_Updates.PNG

2. Click “Next” again, select “I accept the terms of the license agreements” and click Finish to begin the installation.

../_images/CCS_Updating_Software.png

3. You may be prompted to restart CCS for the updates to take effect. Click “Restart Now” when prompted to complete the installation.

10.2.1.1.2.4. Create Target Configuration File for EVM

In CCS, you need to create a Target Configuration for your EVM to be able to connect to the target. This configuration defines your:

  • Connection to the target (XDS, FET, etc.)
  • Target device (AM437x GP EVM, AM57x GP EVM, etc.)
  • GEL file for hardware initialization. A GEL file is basically a “batch file” that sets up the CCS debug environment including memory map, PLL, clock, etc.

CCS comes with basic configuration that can be used to configure your particular setup. In the example below, we provide details for a GP AM437x EVM; configuration information for other supported EVMs are also provided as needed.

For EVM specific instructions, refer to the Hardware User’s Guide for your EVM

Note

Note for K2G devices: If using CCS v6.1.2 and Keystone2 device support v1.1.7, 66AK2G02 would not show up in the list of devices when creating the target configuration. This is due to an incompatibility in the XML parser in CCS v6.1.2 with the K2G device xml. In order to work-around this issue, make the change in 66AK2G02.xml as illustrated below in order to have 66AK2G02 display in the device list. This problem does not exist in CCS v6.1.3 onwards as the XML parser has been updated.

C:\ti\ccsv6\ccs_base\common\targetdb\devices\66AK2G02.xml

Line #1

<?xml version="1.1" encoding="UTF-8" standalone="no"?>
to
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
10.2.1.1.2.4.1. Open new target configuration file

From CCS, select “File -> New -> Target Configuration File”:

../_images/CCS-GP437x-EVM-New-Target.png

10.2.1.1.2.4.2. Select target configuration options

The AM437x GP EVM supports embedded XDS100V2 USB Emulation through the MicroUSB AB connector. Select

  • Connection: Texas Instruments XDS100v2 USB Debug Probe
  • Board or Device: EVMAM437X
../_images/CCS-GP437x-EVM-Configure-Target.png

Useful Tip

If you enter the starting numbers of your device in the Board or Device field, the list will show the relevant subset.

Here is a table showing configuration information for all supported EVMs in the Processor-SDK RTOS:

EVM Connection Board
AM65x EVM Texas Instruments XDS110 USB Debug Probe GPEVM_AM65x
AM65x IDK Texas Instruments XDS110 USB Debug Probe IDK_AM65x
GP335x External Emulator Supplied by User. EVM includes a TI 20 pin JTAG connector. EVMAM3358
ICE335x Texas Instruments XDS100v2 USB Debug Probe ICE_AM3359
SK335x Texas Instruments XDS100v2 USB Debug Probe SK_AM3358
BBB External Emulator Supplied by User. EVM includes a TI 20 pin JTAG connector. BeagleBone_Black
GP437x Texas Instruments XDS100v2 USB Debug Probe EVMAM437X
IDK437x Texas Instruments XDS100v2 USB Debug Probe IDK_AM437X
GP572x External Emulator Supplied by User. EVM includes a TI 20 pin JTAG connector. GPEVM_AM572X
X15 External Emulator Supplied by User. EVM includes a TI 20 pin JTAG connector. GPEVM_AM572X
IDK572x/IDK574x Texas Instruments XDS100V2 USB Debug Probe External Emulator Supplied by User. EVM includes a 60-pin MIPI JTAG connector IDK_AM572X/IDK_AM574X
C665x EVM Texas Instruments XDS2xx USB Onboard Debug Probe TMS320C6657
C667x EVM L w/ XDC100: Texas Instruments XDS100v1 USB Emulator LE/LXE with XDS560: Blackhawk XDS560v2-USB Mezzanine Emulator TMS320C6678
K2E EVM Texas Instruments XDS2xx USB Onboard Debug Probe 66AK2E05
K2H EVM Texas Instruments XDS2xx USB Onboard Debug Probe 66AK2H12
K2L EVM Texas Instruments XDS2xx USB Onboard Debug Probe TCI6630K2L
K2G GP EVM Texas Instruments XDS2xx USB Onboard Debug Probe 66AK2G02
OMAPL137 EVM Spectrum Digital XDS510USB Emulator OMAPL137SK
OMAPL138 LCDK External Emulator Supplied by User. EVM includes a TI 14 pin JTAG connector. OMAPL138LCDK

10.2.1.1.2.4.3. Save target configuration

Next, save the target configuration by pressing the Save button:

../_images/CCS-GP437x-EVM-Save-Target.png

10.2.1.1.2.4.4. Test target configuration

Next, test the target configuration by pressing the Test Connection button. This will confirm that you have successfully created an emulator connection with your board.

../_images/AM4-GP-test-connection.png

10.2.1.1.2.4.5. View target configurations

From CCS, select “View -> Target Configurations”:

../_images/CCS-GP437x-EVM-View-Target.png

10.2.1.1.2.4.6. Launch target configuration

Open “User Defined” list and right click on the target configuration file that was just saved and select “Launch Selected Configuration”:

../_images/CCS-GP437x-EVM-Launch-Target.png

10.2.1.1.2.4.7. Connect target

After launch, you can connect to a core. For GP AM437x EVM, select Cortex A9 and select “Connect Target”:

../_images/CCS-GP437x-EVM-Connnect-Target.png

10.2.1.1.2.4.8. Success!

After connecting to target, check the console for status. Typically, the end of the configuration will indicate success or failure. For GP AM437x EVM, you will see the message “AM437x GP EVM Initialization is Done”:

../_images/CCS-GP437x-EVM-Run-Target.png

10.2.1.1.2.5. Additional Notes for AM57x
10.2.1.1.2.5.1. Connect to AM57x Slave Cores

After connecting to the boot master core – typically the ARM core – you may need to connect to a slave core in order to run code. Depending on your SOC, the slave core can be

  • DSP C66x
  • ARM M4
  • PRUSS
  • IVAHD

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.

../_images/Multicore-Enable.jpg

10.2.1.1.2.5.2. Timer Suspend Control Options for DSP

On AM57xx devices, all the timers on the chip have their suspend control signal routed to the A15 core. Which means that if any of the slave cores are using these timers, the timers will continue to run even when the slave core has been paused. The timer will only pause when the A15 core is halted.

This is confusing while debugging code on slave cores if you are relying on timer for logging, inserting delays or if the timer keeps firing interrupts even when the core is halted. One such scenario occurs with GPtimer5 when DSP developers are using SYS/BIOS. The OS uses GPtimer5 on the DSP and forces a frequency check to confirm the timer configuration, however the OS can’t gain access to the timer due to the hook up of the suspend control signals.

Due to this issue the SYS/BIOS developers will need to configure an additional CCS configuration check to connect the GPTimer suspend control signal to the DSP as shown in the image below:

../_images/GPtimer5_DSPConnect.png

10.2.1.1.2.6. Troubleshooting

If you face any problems, first check these basic items:

  • Power cycle your target.
  • Check the USB cable. One simple way to do this is to connect another device to the USB and ensure the cable works.
  • Check host driver. Even with CCS turned off, your host should list the TI XDS as a USB device. If this does not work, try a different USB port.
  • Latest emulation package. Ensure that you have the latest emulation files as specified in the Getting Started Guide.

If this does not resolve your problem, see these additional resources:


10.2.1.2. Update environment when installing to a custom path

10.2.1.2.1. Overview

This page will provide configuration information if the SDK is installed in a custom path.

Useful Tip

To avoid changing environment variable for each new shell, modify environment variable file directly. This file is the setupenv file located in the SDK root directory.

10.2.1.2.2. Changes to CCS Configuration

Installing the SDK in a folder other than where CCS is installed will require modifications to CCS to be able to discover the SDK. See the Setup CCS How To page explaining how to update CCS configuration.

10.2.1.2.3. Rebuilding the SDK RTOS

Installing the SDK in a folder other than the default (C:\TI for Windows, /home/[user]/ti for Linux) requires modifications to SDK RTOS scripts in order for recompilation and example/test creation to work properly.

In all the commands below, replace [version] with the appropriate version of the software/tool.

10.2.1.2.3.1. CCS in Custom Path and SDK RTOS in Default Path

CCS installation and toolchain paths can be customized by setting the TOOLS_INSTALL_PATH environment variable prior to running the SDK level setupenv script. This feature is used if CCS and the toolchains are installed somewhere other than the default C:\ti location.

For example, environment configuration assuming CCS is installed to [os_base]\ti_temp and SDK RTOS has been installed to default path, [os_base]\ti :

  • Windows
C:\> set TOOLS_INSTALL_PATH=C:\ti_temp
C:\> cd C:\ti\processor_sdk_rtos_[soc]_[version]
C:\ti\processor_sdk_rtos_[soc]_[version]> setupenv.bat

Gives the output:

Optional parameter not configured : CG_XML_BIN_INSTALL_PATH
REQUIRED for xdc release build
Example: set CG_XML_BIN_INSTALL_PATH=C:/ti/cg_xml/bin
Optional parameter not configured : DOXYGEN_INSTALL_PATH
REQUIRED for xdc release build
Example: set DOXYGEN_INSTALL_PATH=C:/ti/Doxygen/doxygen/1.5.1-p1/bin
**************************************************************************
Environment Configuration:
    PDK Directory             : /ti/PDK_AM~3/packages/
    CGTOOL INSTALL Directory  : C:/ti_temp/ccsv6/tools/compiler/ti-cgt-c6000_[version]
    TOOLCHAIN A15 Directory   : C:/ti_temp/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
    TOOLCHAIN A8 Directory    : C:/ti_temp/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
    TOOLCHAIN A9 Directory    : C:/ti_temp/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
    TOOLCHAIN M4 Directory    : C:/ti_temp/ccsv6/tools/compiler/ti-cgt-arm_[version]
    FPULIB_PATH               : C:/ti_temp/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]/lib/gcc/arm-none-eabi/[version]/fpu
    CROSS_TOOL_PRFX           : arm-none-eabi-
    XDC_INSTALL_PATH          : C:/ti/xdctools_[version]_core
    BIOS_INSTALL_PATH         : C:/ti/bios_[version]
    IPC_INSTALL_PATH          : C:/ti/ipc_[version]
    EDMA3LLD_BIOS6_INSTALLDIR : C:/ti/edma3_lld_[version]
    NDK_INSTALL_PATH          : C:/ti/ndk_[version]
    IMGLIB_INSTALL_PATH       : C:/ti/imglib_c66x_[version]
    UIA_INSTALL_PATH          : C:/ti/uia_[version]
    PROC_SDK_INSTALL_PATH     : C:/ti/processor_sdk_rtos_[soc]_[version]
**************************************************************************
Changing to short name to support directory names containing spaces
current directory: C:/ti/processor_sdk_rtos_[soc]_[version]
PROCESSOR SDK BUILD ENVIRONMENT CONFIGURED
**************************************************************************
  • Linux
$ export TOOLS_INSTALL_PATH=~/ti_temp
$ cd ~/ti/processor_sdk_rtos_[soc]_[version]/
~/ti/processor_sdk_rtos_[soc]_[version]$ source setupenv.sh

Gives the output:

Optional parameter not configured : CG_XML_BIN_INSTALL_PATH
REQUIRED for xdc release build
Example: export CG_XML_BIN_INSTALL_PATH="~/ti/cg_xml/bin"
Optional parameter not configured : DOXYGEN_INSTALL_PATH
REQUIRED for xdc release build
Example: export DOXYGEN_INSTALL_PATH="~/ti/Doxygen/doxygen/1.5.1-p1/bin"
**************************************************************************
Environment Configuration:
    PDK Directory             : /home/[user]/ti/pdk_[soc]_[version]/packages
    CGTOOL INSTALL Directory  : /home/[user]/ti_temp/ccsv6/tools/compiler/ti-cgt-c6000_[version]
    TOOLCHAIN A15 Directory   : /home/[user]/ti_temp/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
    TOOLCHAIN A8 Directory    : /home/[user]/ti_temp/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
    TOOLCHAIN A9 Directory    : /home/[user]/ti_temp/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
    TOOLCHAIN M4 Directory    : /home/[user]/ti_temp/ccsv6/tools/compiler/ti-cgt-arm_[version]
    FPULIB_PATH               : /home/[user]/ti_temp/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]/lib/gcc/arm-none-eabi/[version]/fpu
    CROSS_TOOL_PRFX           : arm-none-eabi-
    XDC_INSTALL_PATH          : /home/[user]/ti/xdctools_[version]_core
    BIOS_INSTALL_PATH         : /home/[user]/ti/bios_[version]
    IPC_INSTALL_PATH          : /home/[user]/ti/ipc_[version]
    EDMA3LLD_BIOS6_INSTALLDIR : /home/[user]/ti/edma3_lld_[version]
    NDK_INSTALL_PATH          : /home/[user]/ti/ndk_[version]
    IMGLIB_INSTALL_PATH       : /home/[user]/ti/imglib_c66x_[version]
    UIA_INSTALL_PATH          : /home/[user]/ti/uia_[version]
    PROC_SDK_INSTALL_PATH     : /home/[user]/ti/processor_sdk_rtos_[soc]_[version]

PROCESSOR SDK BUILD ENVIRONMENT CONFIGURED
*******************************************************************************

The RTOS SDK top level Makefile can now be used to rebuild SDK RTOS components with CCS and toolchains installed in a custom installation path.

10.2.1.2.3.2. CCS in Default Path and SDK RTOS in Custom Path

SDK RTOS component installation paths can be customized by setting the SDK_INSTALL_PATH variable prior to running the SDK level setupenv script. This feature is used if the SDK is installed somewhere other than the default C:\ti location.

For example, environment configuration assuming CCS is installed to the default path, [os_base]\ti and SDK RTOS has been installed to [os_base]\ti_temp:

  • Windows
C:\> set SDK_INSTALL_PATH=C:/ti_temp
C:\> cd C:\ti_temp\processor_sdk_rtos_[soc]_[version]
C:\ti_temp\processor_sdk_rtos_[soc]_[version]> setupenv.bat

Gives the output:

Optional parameter not configured : CG_XML_BIN_INSTALL_PATH
REQUIRED for xdc release build
Example: set CG_XML_BIN_INSTALL_PATH=C:/ti/cg_xml/bin
Optional parameter not configured : DOXYGEN_INSTALL_PATH
REQUIRED for xdc release build
Example: set DOXYGEN_INSTALL_PATH=C:/ti/Doxygen/doxygen/1.5.1-p1/bin
**************************************************************************
Environment Configuration:
    PDK Directory             : /ti_temp/PDK_AM~3/packages/
    CGTOOL INSTALL Directory  : C:/ti/ccsv6/tools/compiler/ti-cgt-c6000_[version]
    TOOLCHAIN A15 Directory   : C:/ti/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
    TOOLCHAIN A8 Directory    : C:/ti/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
    TOOLCHAIN A9 Directory    : C:/ti/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
    TOOLCHAIN M4 Directory    : C:/ti/ccsv6/tools/compiler/ti-cgt-arm_[version]
    FPULIB_PATH               : C:/ti/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]/lib/gcc/arm-none-eabi/[version]/fpu
    CROSS_TOOL_PRFX           : arm-none-eabi-
    XDC_INSTALL_PATH          : C:/ti_temp/xdctools_[version]_core
    BIOS_INSTALL_PATH         : C:/ti_temp/bios_[version]
    IPC_INSTALL_PATH          : C:/ti_temp/ipc_[version]
    EDMA3LLD_BIOS6_INSTALLDIR : C:/ti_temp/edma3_lld_[version]
    NDK_INSTALL_PATH          : C:/ti_temp/ndk_[version]
    IMGLIB_INSTALL_PATH       : C:/ti_temp/imglib_c66x_[version]
    UIA_INSTALL_PATH          : C:/ti_temp/uia_[version]
    PROC_SDK_INSTALL_PATH     : C:/ti_temp/processor_sdk_rtos_[soc]_[version]
**************************************************************************
Changing to short name to support directory names containing spaces
current directory: C:/ti_temp/processor_sdk_rtos_[soc]_[version]
PROCESSOR SDK BUILD ENVIRONMENT CONFIGURED
**************************************************************************
  • Linux
$ export SDK_INSTALL_PATH=~/ti_temp
$ cd ~/ti_temp/processor_sdk_rtos_[soc]_[version]/
~/ti_temp/processor_sdk_rtos_[soc]_[version]$ source setupenv.sh

Gives the output:

Optional parameter not configured : CG_XML_BIN_INSTALL_PATH
REQUIRED for xdc release build
Example: export CG_XML_BIN_INSTALL_PATH="~/ti/cg_xml/bin"
Optional parameter not configured : DOXYGEN_INSTALL_PATH
REQUIRED for xdc release build
Example: export DOXYGEN_INSTALL_PATH="~/ti/Doxygen/doxygen/1.5.1-p1/bin"
**************************************************************************
Environment Configuration:
    PDK Directory             : /home/[user]/ti_temp/pdk_[soc]_[version]/packages
    CGTOOL INSTALL Directory  : /home/[user]/ti/ccsv6/tools/compiler/ti-cgt-c6000_[version]
    TOOLCHAIN A15 Directory   : /home/[user]/ti/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
    TOOLCHAIN A8 Directory    : /home/[user]/ti/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
    TOOLCHAIN A9 Directory    : /home/[user]/ti/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
    TOOLCHAIN M4 Directory    : /home/[user]/ti/ccsv6/tools/compiler/ti-cgt-arm_[version]
    FPULIB_PATH               : /home/[user]/ti/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]/lib/gcc/arm-none-eabi/[version]/fpu
    CROSS_TOOL_PRFX           : arm-none-eabi-
    XDC_INSTALL_PATH          : /home/[user]/ti_temp/xdctools_[version]_core
    BIOS_INSTALL_PATH         : /home/[user]/ti_temp/bios_[version]
    IPC_INSTALL_PATH          : /home/[user]/ti_temp/ipc_[version]
    EDMA3LLD_BIOS6_INSTALLDIR : /home/[user]/ti_temp/edma3_lld_[version]
    NDK_INSTALL_PATH          : /home/[user]/ti_temp/ndk_[version]
    IMGLIB_INSTALL_PATH       : /home/[user]/ti_temp/imglib_c66x_[version]
    UIA_INSTALL_PATH          : /home/[user]/ti_temp/uia_[version]
    PROC_SDK_INSTALL_PATH     : /home/[user]/ti_temp/processor_sdk_rtos_[soc]_[version]

PROCESSOR SDK BUILD ENVIRONMENT CONFIGURED
*******************************************************************************

The RTOS SDK top level Makefile can now be used to rebuild SDK RTOS components installed in the custom installation path.

Note

The following known issue impacts this step: PRSDK-1263: PDK AM437x: Make fails on Windows if CCS is installed in custom path. Workaround: Edit the UTILS_INSTALL_DIR variable in <pdk_root_dir>/packages/ti/starterware/Rules.make to point to the CCS installation on your Windows PC.

10.2.1.2.3.3. CCS and SDK RTOS in Custom Path

When CCS and the SDK RTOS are both installed to custom paths the SDK can be rebuilt by setting the SDK_INSTALL_PATH and TOOLS_INSTALL_PATH variables prior to running the SDK RTOS top level environment setup script. The Windows and Linux environment setup scripts can be found in the following locations, respectively:

  • Windows - C:\custom\install\path\processor_sdk_rtos_[soc]_[version]\setupenv.bat
  • Linux - /home/[user]/custom/install/path/processor_sdk_rtos_[soc]_[version]/setupenv.sh

The SDK_INSTALL_PATH and TOOLS_INSTALL_PATH environment variables must be set to the custom install path prior to running the environment setup script.

For example, environment configuration assuming CCS and the SDK have been installed to [os_base]\new_sdk_release\ :

  • Windows
C:\> set SDK_INSTALL_PATH=C:\new_sdk_release
C:\> set TOOLS_INSTALL_PATH=C:\new_sdk_release
C:\> cd C:\new_sdk_release\processor_sdk_rtos_[soc]_[version]
C:\new_sdk_release\processor_sdk_rtos_[soc]_[version]> setupenv.bat

Gives the output:

Optional parameter not configured : CG_XML_BIN_INSTALL_PATH
REQUIRED for xdc release build
Example: set CG_XML_BIN_INSTALL_PATH=C:/ti/cg_xml/bin
Optional parameter not configured : DOXYGEN_INSTALL_PATH
REQUIRED for xdc release build
Example: set DOXYGEN_INSTALL_PATH=C:/ti/Doxygen/doxygen/1.5.1-p1/bin
**************************************************************************
Environment Configuration:
    PDK Directory             : /NEW_SD~1/PDK_AM~1/packages/
    CGTOOL INSTALL Directory  : C:/new_sdk_release/ccsv6/tools/compiler/ti-cgt-c6000_[version]
    TOOLCHAIN A15 Directory   : C:/new_sdk_release/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
    TOOLCHAIN A8 Directory    : C:/new_sdk_release/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
    TOOLCHAIN A9 Directory    : C:/new_sdk_release/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
    TOOLCHAIN M4 Directory    : C:/new_sdk_release/ccsv6/tools/compiler/ti-cgt-arm_[version]
    FPULIB_PATH               : C:/new_sdk_release/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]/lib/gcc/arm-none-eabi/[version]/fpu
    CROSS_TOOL_PRFX           : arm-none-eabi-
    XDC_INSTALL_PATH          : C:/new_sdk_release/xdctools_[version]_core
    BIOS_INSTALL_PATH         : C:/new_sdk_release/bios_[version]
    IPC_INSTALL_PATH          : C:/new_sdk_release/ipc_[version]
    EDMA3LLD_BIOS6_INSTALLDIR : C:/new_sdk_release/edma3_lld_[version]
    NDK_INSTALL_PATH          : C:/new_sdk_release/ndk_[version]
    IMGLIB_INSTALL_PATH       : C:/new_sdk_release/imglib_c66x_[version]
    UIA_INSTALL_PATH          : C:/new_sdk_release/uia_[version]
    PROC_SDK_INSTALL_PATH     : C:/new_sdk_release/processor_sdk_rtos_[soc]_[version]
**************************************************************************
Changing to short name to support directory names containing spaces
current directory: C:/new_sdk_release/processor_sdk_rtos_[soc]_[version]
PROCESSOR SDK BUILD ENVIRONMENT CONFIGURED
**************************************************************************
  • Linux
$ export SDK_INSTALL_PATH=~/new_sdk_release
$ export TOOLS_INSTALL_PATH=~/new_sdk_release
$ cd ~/new_sdk_release/processor_sdk_rtos_[soc]_[version]/
~/new_sdk_release/processor_sdk_rtos_[soc]_[version]$ source setupenv.sh

Gives the output:

Optional parameter not configured : CG_XML_BIN_INSTALL_PATH
REQUIRED for xdc release build
Example: export CG_XML_BIN_INSTALL_PATH="~/ti/cg_xml/bin"
Optional parameter not configured : DOXYGEN_INSTALL_PATH
REQUIRED for xdc release build
Example: export DOXYGEN_INSTALL_PATH="~/ti/Doxygen/doxygen/1.5.1-p1/bin"
**************************************************************************
Environment Configuration:
    PDK Directory             : /home/[user]/new_sdk_release/pdk_[soc]_[version]/packages
    CGTOOL INSTALL Directory  : /home/[user]/new_sdk_release/ccsv6/tools/compiler/ti-cgt-c6000_[version]
    TOOLCHAIN A15 Directory   : /home/[user]/new_sdk_release/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
    TOOLCHAIN A8 Directory    : /home/[user]/new_sdk_release/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
    TOOLCHAIN A9 Directory    : /home/[user]/new_sdk_release/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]
    TOOLCHAIN M4 Directory    : /home/[user]/new_sdk_release/ccsv6/tools/compiler/ti-cgt-arm_[version]
    FPULIB_PATH               : /home/[user]/new_sdk_release/ccsv6/tools/compiler/gcc-arm-none-eabi-[version]/lib/gcc/arm-none-eabi/[version]/fpu
    CROSS_TOOL_PRFX           : arm-none-eabi-
    XDC_INSTALL_PATH          : /home/[user]/new_sdk_release/xdctools_[version]_core
    BIOS_INSTALL_PATH         : /home/[user]/new_sdk_release/bios_[version]
    IPC_INSTALL_PATH          : /home/[user]/new_sdk_release/ipc_[version]
    EDMA3LLD_BIOS6_INSTALLDIR : /home/[user]/new_sdk_release/edma3_lld_[version]
    NDK_INSTALL_PATH          : /home/[user]/new_sdk_release/ndk_[version]
    IMGLIB_INSTALL_PATH       : /home/[user]/new_sdk_release/imglib_c66x_[version]
    UIA_INSTALL_PATH          : /home/[user]/new_sdk_release/uia_[version]
    PROC_SDK_INSTALL_PATH     : /home/[user]/new_sdk_release/processor_sdk_rtos_[soc]_[version]

PROCESSOR SDK BUILD ENVIRONMENT CONFIGURED
*******************************************************************************

The RTOS SDK top level Makefile can now be used to rebuild SDK RTOS components installed in the custom installation path using CCS and toolchains installed in a custom path as well.

10.2.1.2.4. Rebuilding the PDK

Installing the PDK in a folder other than the default (C:TI for Windows, /home/[user]/ti for Linux) requires modifications to PDK scripts in order for recompilation and example/test creation to work properly.

10.2.1.2.4.1. CCS in Custom Path and PDK in Default Path

The instructions provided in the CCS in Custom Path and SDK RTOS in Default Path section can be used to rebuild components at the PDK level. The only difference is the PDK level setup script should be used instead of the SDK RTOS level setup script. The PDK level setup scripts are found in the following locations on Windows and Linux, respectively:

  • Windows - C:\custom\install\path\pdk_[soc]_[version]\packages\pdksetupenv.bat
  • Linux - /home/[user]/custom/install/path/pdk_[soc]_[version]/packages/pdksetupenv.sh
10.2.1.2.4.2. CCS in Default Path and PDK in Custom Path

The instructions provided in the CCS in Default Path and SDK RTOS in Custom Path section can be used to rebuild components at the PDK level. The only difference is the PDK level setup script should be used instead of the SDK RTOS level setup script. The PDK level setup scripts are found in the following locations on Windows and Linux, respectively:

  • Windows - C:\custom\install\path\pdk_[soc]_[version]\packages\pdksetupenv.bat
  • Linux - /home/[user]/custom/install/path/pdk_[soc]_[version]/packages/pdksetupenv.sh
10.2.1.2.4.3. CCS and PDK in Custom Path

The instructions provided in the CCS and SDK RTOS in Custom Path section can be used to rebuild components at the PDK level. The only difference is the PDK level setup script should be used instead of the SDK RTOS level setup script. The PDK level setup scripts are found in the following locations on Windows and Linux, respectively:

  • Windows - C:\custom\install\path\pdk_[soc]_[version]\packages\pdksetupenv.bat
  • Linux - /home/[user]/custom/install/path/pdk_[soc]_[version]/packages/pdksetupenv.sh

10.2.1.2.5. Creating PDK Example/Test Projects When CCS is Installed to Custom Path

The pdkProjectCreate scripts must be modified in order to build PDK example and test projects only if CCS has been installed to a custom path. The modification is the same for both Windows and Linux. Inside the pdkProjectCreate scripts is a CCS_INSTALL_PATH variable which points to the Code Composer Studio root directory. This variable must be redefined to the new location of the CCS root directory if CCS is installed to a custom path.

  • Windows
REM Install Location for CCS
set CCS_INSTALL_PATH="C:\ti\ccsv6"
  • Linux
# Install Location for CCS
export CCS_INSTALL_PATH=~/ti/ccsv6

Note

Prior to invoking the pdkProjectCreate script, make sure to start CCS and register the SDK RTOS components installed. Project creation will fail if the RTOS SDK components installed to the custom path have not been registered with CCS. Please see CCS and SDK installed in different directories for instructions on how to register SDK RTOS components installed to a custom path with CCS

10.2.1.4. Rebuild drivers from PDK directory

Refer Rebuilding the PDK for details on rebuilding the PDK components.

10.2.2. TI RTOS Basics

10.2.2.1. TI RTOS Tips & Tricks

10.2.2.1.1. Description

The intent of this article is to address common issues that TI RTOS users may run into while configuring SYSBIOS, XDCTools or working with RTSC packages in general on DSP and ARM devices. This is meant to provide insight into build and configuration issue nd must be used as an addendum document by Processor SDK USer to the SYSBIOS FAQs and XDCtools/RTSC documentation and TI RTOS Training

10.2.2.1.2. RTSC Diagnostics: Understanding XDC build errors

Some of the commonly observed XDC errors have been shown below. We try to explain how to understand and take corrective action.

10.2.2.1.2.1. xdc.tools.configuro: can’t locate the package ‘Package Name’ along the path: ...

This indicates that one of the packages that you linked in your BIOS configuration, can`t be located under XDCPATH. The XDC tools uses XDC paths like library search path, so if you run into this issue check that all the component packages have been added to XDCPATH and there is no typo or non-existent paths that you have added to this variable. TI RTSC packages usually have the name ti.<package name>. The packages are named to also sometimes helps locate the package inside the component. For example ‘’‘ti.platforms.evmAM335x’‘’ is located under BIOS_INSTALL_PATH/packages/’‘’ti/platforms/evmAM335x’‘’

For example if you are using packages from PDK (SOC driver packages)and BIOS (TI RTOS kernel), IPC (Interprocessor Communication) and NDK (Network development kit) then your XDCPATH needs to have following:

  • BIOS_INSTALL_PATH/packages
  • PDK_INSTALL_PATH/packages
  • IPC_INSTALL_PATH/packages
  • NDK_INSTALL_PATH/packages
10.2.2.1.2.2. xdc.cfg.SourceDir : Build of generated source libraries failed: exit status = 2:

A couple of different reasons could trigger this type of error

  • Make sure there are no whitespaces or non-ASCII characters in any paths referenced by the build tools. In other words, make sure all software packages are installed in paths without spaces, and workspace and project names also do not have spaces or non-ASCII characters. We use gmake to build makefiles, and gmake doesn’t deal well with spaces in directory and file names.
  • Take a close look at the CCS build console and ensure that the sh.exe used for the build is the one from the CCS directory. Also check your system PATH variable and see if there is another sh.exe (or gmake.exe) in your system PATH earlier than the one from the CCS installation. If there is one, then that will be used for the build and could cause build errors such as this. Some toolchains that are known to include sh.exe and could cause a conflict are Cygwin, WinAVR, Yagarto. In this case, remove those conflicting tools from the system PATH or modify the PATH so that the sh.exe and gmake.exe from CCS are seen first.
  • Another source of problems related to sh.exe runnig Windows 10 may be Windows Defender. In “Windows Defender Security Centre”, “App and browser control”, “Exploit protection settings” one can add exceptions under “Program settings”. Adding a rule for “sh.exe” to disable/override “Force randomisation for images (Mandatory ASLR)”, “Randomise memory allocations (Bottom-up ASLR)”, “Validate stack integrity (StackPivot)”.
10.2.2.1.2.3. xdc.tools.configuro: missing input config script

The XDCtools build command should normally have the configuration script (.cfg file) passed at the end of the command. If the .cfg is not getting passed correctly, then this message will appear in the CCS build console. This error will then result in other compiler errors further down in the build.

You can confirm if the root cause is the .cfg file not getting passed correctly by looking at the subdir_rules.mk file in the directory Debug (or Release) in your project. The command line that runs configuro usually looks like this: <br>

"C:/ti/xdctools_3_xx_xx_xx/xs" --xdcpath="..." xdc.tools.configuro -o configPkg -t ti.targets.elf.C674 -p ti.platforms.evm6747
-r release -c "C:/ti/ccsv5/tools/compiler/c6000_x.x.x" --compileOptions "-g --optimize_with_debug" "$<"

10.2.2.1.2.4. Schema files not found

Usually after creating a RTSC package, developers are supposed to run xdc release to generate the package that contains the .sch files but if you accidentally delete the package or the developers requires xdc release to be run in user environment, you can run into this issue. This issue can be resolved by adding XDCtools to your environment PATH variable and running the command xdc release

set PATH=$PATH;<XDC_INSTALL_PATH>
xdc release

Detailed list of ‘’‘XDC Error codes’‘’ and Troubleshoot can be found here:

10.2.2.1.3. TI RTOS Platform configuration

10.2.2.1.3.1. Where does TI RTOS application get the Platform definition and memory sections on the SOC

When creating a TI RTOS project, the user is required to specify the Platform and target core as part of their RTSC setup as shown below. This shows an example that is created for evmAM335x platform.

../_images/Platfrom_configuration.png

Selection of the platform essentially tell the build tools that the platform defintion should be picked up from the platform for evmAM335x from the directory path bios_x_xx_xx_xxpackagestiplatformsevmAM3359. If you open the Platform.xdc file under the folder path, you can see the default settings provided for this platform. This file combines the baseline AM335x SOC definition under bios_x_xx_xx_xxpackagesticatalogarmcortexa with the board specific setting like clockrate, DDR memory range.

10.2.2.1.3.2. How to create custom platform like DDRless platforms to use with TI RTOS projects

At some point in the application development process, most customers build their own boards, choosing a TI device and adding custom external memory. You will also need to create your own platform if any of the following items are true: * You want to customize cache sizes. * You want to manually override the default section placement. * You want application to run from on chip device memory.

For such custom boards you will need to create a platform using the platform wizard. The platform wizard is a GUI tool that allows you to easily create a custom platform. Creating a custom platform gives you a lot of flexibility in terms of defining the memory map and selecting default memory segments for section placement. This has been described in detail in following User guides and training links:

10.2.2.1.3.3. How to place code and data sections in different memory location than set by default TI RTOS platform configuration

User can place specific code and data sections in desired location by using the following syntax in the configuration (.cfg)

Program.sectMap[".data"] = new Program.SectionSpec();
/* Set the load address for .data section */
Program.sectMap[".data"].loadAddress = 0x82000000;
/* Set the run address for .data section */
Program.sectMap[".data"].runAddress = 0x82010000;

10.2.2.1.4. Generic TI RTOS questions

10.2.2.1.4.1. What is relationship between TI RTOS and XDCtools and RTSC

SYSBIOS uses underlying technology provided by Real Time Software Components (RTSC). * RTSC is an open-source specification within the Eclipse.org ecosystem for providing reusable software components (called “packages”) for use in embedded systems. * XDCtools is the actual product that contains all the tools necessary for you to use the SYS/BIOS components and configure your application. XDCtools is installed as part of Code Composer Studio (CCS). XDCtools is a separate software component provided by Texas Instruments that provides the underlying tooling needed for configuring and building SYS/BIOS, NDK, and UIA.

RTSC and XDCtools are important to SYS/BIOS users because:

  • SYS/BIOS_as_a_set_of_RTSC_packages containing the modules that make up the RTOS.

  • XDCtools provides configuration tools you use to create and build a static configuration as part of your application. This *.cfg configuration file specifies:

    • Which modules from XDCtools, SYS/BIOS, and other components to include in the run-time image.
    • What static instances of RTOS objects to create. For example, these include tasks and semaphores.
    • Settings for parameter values for modules and objects.
  • XDCtools provides critical APIs that are used by SYS/BIOS and other related software components. These include memory allocation, logging, and system control.

The RTSC-pedia web site describes RTSC and XDCtools in more detail. In particular, it provides information for developers planning to create RTSC packages. It is also useful if you plan to edit configuration scripts with a text editor rather than using the XGCONF graphical editor provided withing CCS.

10.2.2.1.4.2. Can you use any SYSBIOS version with any version of XDCTools when creating create or migrating to TI RTOS based application development environment

This is a frequent issue for new user of TI RTOS. SYSBIOS releases are usually validated with a specific version of XDCTools that is described in the Release notes. It is generally not recommended to mix and match SYSBIOS versions with older or newer than the versions described as you may run into incompatibility issues. TI simplifies this build environments by packaging the TI RTOS package with XDCtools or by providing SDKs with the compatible versions of SYSBIOS kernel and XDCtools.

For customers using TI DSP and ARM Processors, it is recommended to use Processor SDK RTOS for TI RTOS development and to setup the CCS environment such its Preferences are set to use the versions included in the SDK. This process has been described: Processor_SDK_RTOS_Setup_CCS

10.2.2.1.4.3. Using SYSBIOS with GNU GCC (for ARM devices only)

The key care about of using SYSBIOS kernel on ARM based devices with GNU GCC compiler have been described in the article SYS/BIOS_with_GCC_(CortexA)

This wiki answers important questions about using SYSBIOS kernel with GNU GCC compiler like: * Changing entry point to an application

10.2.2.1.4.4. How do I port existing application developed on SYSBIOS application to SMP/BIOS

SYSBIOS supports SMP mode of operation on multi-core ARM and few dual core M3/M4 (IPU) subsytem present in Keystone and Sitara processors.

Training Slides: SMP SYSBIOS Overview presentation.

To Porting existing SYS/BIOS applications to SMP/BIOS, you can use the follow steps described below: * Merge existing separate applications into a single application. * Merge separate platform memory definitions as necessary. * Add this to your existing application’s config script:

BIOS.smpEnabled = true;

  • Use these SMP-aware clone modules in place of their xdc.runtime equivalents for SysMin, SysStd, LoggerBuf (in ti.sybios.smp package)

‘’‘Note:’‘’ The existing Load module has been tweaked to provide minimal support for SMP. * For initial sanity testing, force all tasks to run on core 0:

Task.defaultAffinity = 0;

  • Once basic functionality of the merged applications has been demonstrated, either remove Task.defaultAffinity setting or replace it with

Task.defaultAffinity = Task.AFFINITY_NONE;

The above statement will guide RTOS kernel to deploy tasks based on availability in the cluster of compute cores processing in SMP mode.

10.2.2.1.4.5. Are there any Graphical tools to configure SYSBIOS configuration

The easiest way for new users to add/configure new modules in the TI RTOS BIOS configuration is to use XGCONF based graphical tool

10.2.2.1.5. Thread Types

10.2.2.1.5.1. What is the difference between SWIs and Tasks
  • A Swi is a non-blocking thread that runs to completion and can only be pre-empted by a higher priority Swi or a Hwi (interrupt). Swi’s can pre-empt a Task thread when posted and run on the ISR (system) stack (i.e. they do not have their own stack).
  • A Task thread on the other hand is a blocking thread and can be pre-empted by a higher priority Task or by Swi/Hwi. A task usually has a while loop that keeps the task executing continuously in the system as long as it is required in the application. Also, Tasks run on their own independent stack.
10.2.2.1.5.2. How to add house keeping functions in the idle Task

If you want to use the idle time of the system to do some “housekeeping” jobs in the background, when the system is not active on interrupts or tasks, TI RTOS provides option to provide a task list or point to a housekeeping function which will run when no other thread is active in the system. The simplest syntax to add this to your code is shown below:

Task.enableIdleTask = true;
var Idle = xdc.useModule('ti.sysbios.knl.Idle');
Idle.addFunc('&osTaskIdleFunc');

If you open the BIOS configuration in XGCONF, you will notice that user are allowed to enter upto 8 function in the function list.

Syntax to add idle functions is provided below

var Idle = xdc.useModule('ti.sysbios.knl.Idle');
Idle.idleFxns[0] = "&myIdle1";

10.2.2.1.6. Hardware Interrupts (HWI)

10.2.2.1.6.1. How to configure Crossbar when setting up interrupts on DRA7xx/TDA2xx/AM57xx

Some socs like AM571x and AM572x have a large number of interrupts requests to service the needs of its many peripherals and subsystems. All of the interrupt lines from the subsystems are not needed at the same time, so they have to be muxed to the irq-controller appropriately. In such places a interrupt controllers are preceded by an CROSSBAR that provides flexibility in muxing the device requests to the controller inputs.

Application developers have two options to setup interrupts on AM57xx/TDA2xx/DRA7xx devices which provide a crossbar mechanism to connect a given IRQ source to an IRQ line on the target cpu’s interrupt controller. The device level chip support library provides functional APIs to map interrupt events to target core interrupt controller line.

For example SPI3_IRQ to the CROSSBAR input on DSP and M4, you can use the following:

DSP Core1 configuration of SPI3_IRQ to crossbar input 60:

/* Configure xbar connect for MCSPI3: DSP_IRQ_43 (reserved) mapped to MCSPI3 intr */
   CSL_xbarIrqConfigure (CSL_XBAR_IRQ_CPU_ID_DSP1,
                         CSL_XBAR_INST_DSP1_IRQ_43, /* should match with C66 intc eventId used for event combiner that maps to DSP interrupts*/
                         CSL_XBAR_MCSPI3_IRQ);

IPU core1 configuration of SPI3_IRQ to crossbar input 43:

/* Configure xbar connect for MCSPI3: IPU1_IRQ_60 (reserved) mapped to MCSPI3 intr */
   CSL_xbarIrqConfigure (CSL_XBAR_IRQ_CPU_ID_IPU1,
                         CSL_XBAR_INST_IPU1_IRQ_60, /* should match with M4 intNum used for HWI_create */
                         CSL_XBAR_MCSPI3_IRQ);

Here is how you would define the same interrupt handler for IPU statically in a configuration script:

var Hwi = xdc.useModule('ti.sysbios.family.arm.m3.Hwi');
var IntXbar = xdc.useModule('ti.sysbios.family.shared.vayu.IntXbar');
// Connect IRQ 23 to Interrupt source index 86 (SPI3_IRQ)
IntXbar.connectIRQMeta(60, 86);
// Alternately, the connectIRQMeta API can be used. This
// API expects XBAR instance number as an argument.
//
// Connect Xbar Instance 1 (IRQ 60) to Interrupt
// source index 86 (MCSPI3_IRQ)
//
// IntXbar.connectMeta(1, 60);
var hwiParams = new Hwi.Params();
hwiParams.arg = 60;

10.2.2.1.7. Clocks and Timers

10.2.2.1.7.1. What are the different clock and timer modules in TI RTOS that you should be aware of?
  • Timer Module
    • Manages timer peripherals
    • Provides target/device abstraction
  • Clock Module
    • Manages BIOS “heartbeat”
    • Can schedule functions to fire in the future (one-shot or periodically)
    • Input can be configured to use Timer module “tick” or application “tick”
  • Timestamp Module
    • Provides simple time stamping services for benchmarking code
    • Allows time stamping RTA logs

BIOS Timer Architecture

../_images/BIOS_Timer_Architecture.png

BIOS Clock Architecture

../_images/BIOS_Clock_Architecture.png
10.2.2.1.7.2. How to get accurate clock ticks from the clock module?

The clock module uses the CPU clock setting that is provided by the default platform setting. For example, if the platform is set to AM335x, then the clock is assumed to be 550 MHz, so the clock ticks will be generated with period of 1.8 nanoseconds. ‘’‘TI RTOS doesn`t setup the device clocks, the device clock initiation is the responsibility of the initialization code’‘’ (GEL file in debug environment and bootloader in production environment)

After, the clocks are configured, it is the responsibility of the application developer to inform BIOS of the CPU frequency so that accurate system ticks can be generated.

Note: For example if the core clock on AM335x is set to 720 MHz instead of default 550 Mhz, then users are required to add the following like the .cfg to inform BIOS kernel of the actual CPU setting.

BIOS.cpuFreq.lo = 720000000;

We reiterate that this doesn`t change the actual frequency but only informs the OS of the change from default CPU freq setting.

10.2.2.1.7.3. How to set input frequency in SYSBIOS configuration and change timer used by clock module

Timer.intFreq[index] determines the input clock that drivers the timer. In most cases the input clock is assumed to be the input clock used in TI EVM (Example: 24 Mhz used on AM335x EVM). If you have a different input on your custom board users are required to change the input Freqency setting in their configuration. To change the dmtimer frequency in SYS/BIOS you need to add the following to your config file:

var Timer = xdc.useModule('ti.sysbios.timers.dmtimer.Timer');
Timer.intFreqs[index] = {hi: 0, lo: 19200000};

Where index is the SYS/BIOS timer ID. Please remember that timer IDs do not necessarily match the number in the peripheral name. For example on AM335x SYS/BIOS Timer 0 actually corresponds to DMTimer2 on the device. Use the Timer Mapping Table to determine which timer corresponds to each Timer ID.

The Clock module uses a Timer internally. By default, the Clock module calls Timer_create() with “ANY” which will return one of the available timers. You can specify the exact timer using the following (the default value for Clock.timerId is ANY).

To set it to a specic timer Id, you can use the following syntax.

Clock= xdc.useModule('ti.sysbios.knl.Clock');
Clock.timerId = 3;

10.2.2.1.8. SemiHosting

10.2.2.1.8.1. Why can`t I see output of System_printf on CCS console?

When getting started with TI RTOS, you may notice that the printf from your code goes to CCS console but using non-intrusive System_printf doesn`t. If you want to have System_printf output go to the same place as printf, add the following three lines to your .cfg file and re-build:

var System = xdc.useModule('xdc.runtime.System');
var SysStd = xdc.useModule('xdc.runtime.SysStd');
System.SupportProxy = SysStd;

If you don’t do this, the output will go to a circular buffer in memory. You can examine that buffer using the ROV tool (use the menu: Tools->ROV while in the debugger).

10.2.2.1.8.2. How to enable printf/System_printf to go to CCS IO console on ARM devices

Application developers need to add the SemiHosting module to the .cfg manually by editing the config script. Add the following line:

var SemiHostSupport = xdc.useModule('ti.sysbios.rts.gnu.SemiHostSupport');

This module does the required setup (install SVC_Handler and do the required file handle init) to support SemiHosting.

GNU GCC users on ARM platforms need to link to “rdimon” library to the “GNU Linker” -> “Libraries” view. If the “nosys” library is already listed in the “Libraries” view then replace it with “rdimon”. This will cause the application to link with librdimon.a library which is a Semi-Hosting enabled BSP library.

10.2.2.1.9. Exception Handling

10.2.2.1.9.1. How can I get dump of registers when an exception occurs ?

If you add this to your .cfg file:

var Exception = xdc.useModule('ti.sysbios.family.c64p.Exception');
Exception.enablePrint = true;

SYS/BIOS provides several target unique exception handlers: * ti.sysbios.family.arm.exc.Exception - used by all Arm9 and A8 targets * ti.sysbios.family.arm.m3.Hwi - used by all cortex-M3 targets * ti.sysbios.family.c64p.Exception - used by all C6x targets

a complete exception register context should be dumped to the console in addition to the Error raised by the exception handler when an exception occurs.

If you set a breakpoint at “ti_sysbios_family_c64p_Hwi_int1”, this is the function vectored to on all exceptions. No exception processing will have been performed at this point. Using CCS’ register dump, you can see the complete state of the processor. The NRP register should contain the PC at the time the exception occurred.

10.2.2.1.9.2. How do I determine the call stack at the time of crash

A detailed view of analyzing the call stack using CCS tools when your TI RTOS application throws an exception has been described in the article:

10.2.2.1.9.3. How can you route exception print to UART

The console I/O prints from TI-RTOS can be re-routed to UART. The console I/O messages are printed using the System module which can configured to call callback functions. These callback functions should be configured to write to UART. For example, in your .cfg add a configuration similar to the one below:

/* ================ System configuration ================ */
var System = xdc.useModule('xdc.runtime.System');
var SysCallback = xdc.useModule('xdc.runtime.SysCallback');
SysCallback.abortFxn = "&myUARTAbort";
SysCallback.putchFxn = "&myUARTPutch";
SysCallback.readyFxn = "&myUARTReady";
System.SupportProxy = SysCallback;

And define the functions myUARTAbort, myUARTPutch and myUARTReady in your application. For details about the SysCallback module’s callback function signature, please see this link.

For more details refer to the E2E discussion here: Redirecting Exception logs to UART

10.2.2.1.10. Logging and Trace

10.2.2.1.10.1. How get UIA logging working with TI RTOS application?

In order to get the UIA loggging enabled, you need to include the UIA module and indicate the modules on which you would like obtain the logging information in your application. For example the following configuration will enable Load, Task, Swi and Hwi logging and will enable Task profiler so that you gain visual insight into the execution of the TI RTOS application using System analyzer tools in CCS:

var LoggingSetup = xdc.useModule('ti.uia.sysbios.LoggingSetup');
LoggingSetup.loadLogging = true;
LoggingSetup.loadLoggerSize = 1024;
LoggingSetup.mainLoggerSize = 32768;
LoggingSetup.sysbiosLoggerSize = 32768;
LoggingSetup.sysbiosSwiLogging = true;
LoggingSetup.sysbiosHwiLogging = true;
LoggingSetup.sysbiosSemaphoreLogging = true;
LoggingSetup.loadTaskLogging = true;
LoggingSetup.loadSwiLogging = true;
LoggingSetup.loadHwiLogging = true;
LoggingSetup.enableTaskProfiler = true;
LoggingSetup.sysbiosHwiLoggingRuntimeControl = true;
LoggingSetup.sysbiosSwiLoggingRuntimeControl = true;
LoggingSetup.eventUploadMode = LoggingSetup.UploadMode_JTAGSTOPMODE;

System analyzer view :

../_images/System_Analyzer_Execution_log.png

For more information refer to : System Analyzer wiki

To see how XGCONF graphical tool can be used to add Logging setup, refer to TI RTOS User Section 2.2

10.2.2.1.10.2. What SYS/BIOS Debugging Tools do we have in CCS ?
  • Real Time analysis(RTA) agent
  • RTOS Object View(ROV)
10.2.2.1.10.3. Real Time analysis(RTA) agent

Note: Before Debugging the SYSBIOS Debugging options. It is recommended to set the Preferences under the Windows Tab in CCS to select the version of SYSBIOS, XDCTOOLS in Windows->Preferences->General->RTSC Options. Additionally set IPC and XDAIS if your application uses the components.

  1. Real time analysis can easily be turned on in a SYSBIOS based CCS project using the Grace tools. Select the configuration file (.cfg) in your project this will open an available Resources view inside SYSBIOS. Under diagnostics, select the RTA agent and enable it and save the configuration. Rebuild the project with the new settings.
  2. To run your project, choose Target Debug Active Project from the CCS menus. If this is the first time you are debugging a project for your target, you may need to set up a CCS Target Configuration. See the CCS help for details.
  3. In the Debug perspective, open the Runtime Object Viewer (ROV) tool by choosing Tools ROV. Also open the Raw Logs view by choosing Tools RTA Raw Logs. These tools allow you to see the activity of RTSC and SYS/BIOS modules.
  4. Set some breakpoints in the log.c source file. (You can do this by right-clicking on a line and choosing New Breakpoint &gt; Breakpoint.) For example, set a breakpoint on the last line of each function in log.c.
  5. Run the application.
  6. In the Raw Logs window, you can see the informational, warning, and error messages sent by the calls to Log module APIs in log.c. The messages that begin with LM are diagnostics provided by XDCtools. Messages that begin with “WARNING” come from calls to Log_warning2. Messages that begin with “ERROR” come from calls to Log_error2. Messages that begin with “../log.c” come from calls to Log_info0 and Log_info2 (depending on the number of arguments).</li>
../_images/SYSBIOS_Diag.jpg ../_images/SYSBIOS_Rawlog.jpg ../_images/Rta_exec2.png ../_images/SYSBIOS_CPUload.jpg

For advanced debugging options we recommend following the instructions on the BIOS_6_Real-Time_Analysis_(RTA)_in_CCSv4 wiki

10.2.2.1.10.4. RTOS Object View(ROV)
  1. Load your application for debugging. Select the device you want to debug before opening ROV.
  2. In the ROV window, expand the tree to see the ti.sysbios.knl.Task module. The right pane shows a list of the Task threads in the application. As you advance from breakpoint to breakpoint, you see the run mode of the threads change.</li></ol>
../_images/1.7.6_Image.png
scale:50 %

For more details on ROV tools, refer to the Runtime Object Viewer(ROV) article on RTSC website.

10.2.2.1.11. Memory and Heap

10.2.2.1.11.1. What kind of heap should I use in SYSBIOS application and how do I allocate Heap in my configuration

SYSBIOS Supports five different type of Heap implementation:

  • HeapMin. Very small code footprint implementation. Supports non blocking memory allocation, but does not support freeing memory.
  • HeapMem. Allocate variable-size blocks and uses Gate module to protect allocation and freeing of memory. typically Slower and non-deterministic
  • HeapBuf. Allocate fixed-size blocks. Fast deterministic and non-blocking as allocation uses same size.
  • HeapMultiBuf. Specify variable-size allocation, but internally allocate from a variety of fixed-size blocks. Good tradeoff for HeapMem and HeapBuf
  • HeapTrack. Used to detect memory allocation and deallocation problems. Good for debugging as it detects memory leaks and buffer overflows.

Typical allocation of static heap within the SYSBIOS *.cfg file is shown below:

var HeapMem = xdc.useModule('ti.sysbios.heaps.HeapMem');
/* Create a Heap. */
var heapMemParams = new HeapMem.Params();
heapMemParams.size = 0x8000000;                             // <-- edit this value to tune the size of the heap
heapMemParams.sectionName = "systemHeapMaster";
Program.global.heap0 = HeapMem.create(heapMemParams);
Memory.defaultHeapInstance = Program.global.heap0;

10.2.2.1.12. Benchmarks

10.2.2.1.12.1. Where can I find Memory foot print, Interrupt latency and performance numbers of the TI RTOS when designing my system
The Memory footprint and Interrupt latency for different processor architectures is provided in the SYSBIOS package. It can be located at
bios_6_xx_xx_xx/packages/ti/sysbios/benchmarks/doc-files

The Foot print of the OS depends on number of BIOS kernel modules used by the application but an estimate of the foot print can be computed by adding up the module footprint numbers to the base kernel footprint. The interrupt latency is mostly deterministic in the system but OS response may depend on priority of the interrupt setup. If the 2 or more interrupts occur simultaneously, the premptive BIOS scheduler will let the higher HWI to run before letting the one with lower priority so it may seem as the the lower priority interrupt response is slightly slower.

10.2.2.1.13. Debugging

10.2.2.1.13.1. How to debug common application issues like stack overflow, exception and memory leaks

Common Application debug scenarios like exception management, memory leak and stack issues have been described in the following training video: Debugging Common Application Issues TI RTOS

The training covers stack over flow, exception handling and memory management issues in detail with a Lab for TI MCU devices but the same concepts and features also apply for TI ARM and DSP processors.

10.2.2.1.13.2. How to add Custom compiler options and build custom BIOS library

Users are allowed to change the libType and specify the compiler options from their BIOS configuration using the following

BIOS.libType = BIOS.LibType_Custom;
// For Cortex A8 device like AM335x
BIOS.customCCOpts = "--endian=little -mv7A8 --abi=eabi --neon --float_support=vfpv3 -q -ms --program_level_compile -o3 --opt_for_speed=3"
// For Cortex A9 device like AM437x
BIOS.customCCOpts ="-mcpu=cortex-a9 -mfpu=neon -mfloat-abi=hard -mabi=aapcs -O3 -Wunused -Wunknown-pragmas -ffunction-sections -fdata-sections -g "

To remove a given compiler setting, you can use:

BIOS.customCCOpts = BIOS.customCCOpts.replace(" -g ","");

10.2.3. Flashing and Boot

10.2.3.1. Flash bootable images (C66x, K2H/K2E/K2L only)

10.2.3.1.1. Overview

The Processor SDK RTOS for C6657, C6678, K2H, K2E, and K2L EVMs includes a script in the directory

[SDK Install Path]/processor_sdk_rtos_<platform>_<version>/bin

named program_evm.js. The purpose of this script is to automatically flash bootable images onto your EVM.

The following sections will describe how to use this script and the default flashable binaries in the Processor SDK RTOS.

10.2.3.1.2. Requirements

  • A Windows or Linux PC
  • Processor SDK RTOS installed on your PC. The version to install must match the SOC you plan to use
  • Code Composer Studio installed on your PC
  • An USB connection to your EVM emulator

Note

Your board should be set to NO-BOOT mode. Please refer to the boot mode dip switch settings for different boot modes on your EVM Hardware User Guide. See this page for a link to all supported EVM information.

10.2.3.1.3. Directory Structure

The files used are in the Processor SDK RTOS directory. Expanded below are the relevant files and directories for flashing the bootable images for C667x, but a similar structure is used for C665x.

├── bin
│   ├── configs
│   │   └── evm6678l
│   │       ├── evm6678l.ccxml
│   │       ├── evm6678le.ccxml
│   │       ├── evm6678le-linuxhost.ccxml
│   │       └── evm6678l-linuxhost.ccxml
│   ├── logs
│   └── program_evm.js
└── prebuilt-images
    ├── eeprom50.bin
    ├── eeprom51.bin
    ├── eepromwriter_evm6678l.out
    ├── eepromwriter_input50.txt
    ├── eepromwriter_input51.txt
    ├── eepromwriter_input.txt
    ├── nandwriter_evm6678l.out
    ├── nand_writer_input.txt
    ├── norwriter_evm6678l.out
    └── nor_writer_input.txt

Below is the expanded tree for K2H. Similarly, this also applies to K2E and K2L EVMs.

├── bin
│   ├── configs
│   │   └── evmk2h
│   │       ├── evmk2h.ccxml
│   │       ├── evmk2h-linuxhost.ccxml
│   │       └── program_evm_config
│   ├── logs
│   └── program_evm.js
└── prebuilt-images
    ├── app
    ├── config
    ├── MLO
    └── spi_flash_writer.out

10.2.3.1.4. Default Binaries and Setup

Processor SDK RTOS provides the basic CCXML files to connect to your SOC. There is a separate CCXML file for each SOC, emulator, and host OS combination. These CCXML files are located in:

[SDK Install Path]/processor_sdk_rtos_<platform>_<version>/bin/config/<SOC>

Users can choose to use their own CCXML file by setting the environment variable, PROGRAM_EVM_TARGET_CONFIG_FILE, to point to their CCXML file in their terminal or command prompt.

You can create your own CCXML file by opening CCSv6 –> View –> Target Configurations, and right-clicking on the Target Configuration pane to select New Target Configuration. After selecting your SOC and emulator, remember to set the appropriate GEL file in the advance options for Core 0. The GEL file is used to do basic SOC initialization upon connecting to the core.

Processor SDK RTOS also provides the basic binaries needed to perform flashing. These are separated into two categories - flashwriters and flash images.

Flashwriters

  • [C66x] eepromwriter_<SOC>.out - writes content to your EVM EEPROM flash memory
  • [C66x] norwriter_<SOC>.out - writes content to your EVM NOR flash memory
  • [C66x] nandwriter_<SOC>.out - writes content to your EVM NAND flash memory
  • [K2H/E/L] spi_flash_writer.out - writes multiple images to your NOR flash memory

Flash images

  • [C66x] eeprom50.bin - eeprom binary for address 0x50. The default for C66x is the POST application.
  • [C66x] eeprom51.bin - eeprom binary for address 0x51. The default for C66x is the Intermediate Boot Loader (IBL).
  • [C66x] nor.bin - nor binary to be used for NOR boot. May not be provided for every EVM or release version.
  • [C66x] nand.bin - nand binary to be used for NAND boot. May not be provided for every EVM or release version.
  • [K2H/K2E/K2L] app - NOR binary to be booted by Secondary Bootloader. The default for Keystone 2 is the POST application
  • [K2H/K2E/K2L] MLO - Secondary Bootloader. The default flash location is in SPI NOR flash memory at offset 0.

10.2.3.1.5. Usage

For Windows users:

> cd [SDK Install Path]\processor_sdk_rtos_<platform>_<version>\bin
> set DSS_SCRIPT_DIR=[CCS Install Path]\ccsv6\ccs_base\scripting\bin
> %DSS_SCRIPT_DIR%\dss.bat program_evm.js [tmdx|tmds]evm(6678|6657|k2h|k2e|k2l)[l|le|ls][-le|-be]

For Linux users:

> cd [SDK Install Path]/processor_sdk_rtos_<platform>_<version>/bin
> export DSS_SCRIPT_DIR=[CCS Install Path]/ccsv6/ccs_base/scripting/bin
> $DSS_SCRIPT_DIR/dss.sh program_evm.js [tmdx|tmds]evm(6678|6657|k2h|k2e|k2l)[l|le|ls][-le|-be]

The last argument depends on the SOC that you have, concatenated with the options to select emulator and endianness:

  • l: EVM uses XDS100 on-board Emulator
  • le: EVM uses 560 Mezzanine Emulator daughter card
  • ls: EVM uses XDS200 Emulator card
  • -le: Little Endian
  • -be: Big Endian

Note

  • By default, the images provided are little endian.
  • Also by default, Keystone 2 EVMs are expected to only use the XDS2xx Emulator. You do not have to supply the emulator in the parameter for K2H/K2E/K2L.

Some examples are:

TMDXEVM6678LE little endian

> $DSS_SCRIPT_DIR/dss.sh program_evm.js tmdxevm6678le-le

TMDSEVM6657LS little endian

> $DSS_SCRIPT_DIR/dss.sh program_evm.js tmdxevm6657ls-le

EVMK2H little endian

> $DSS_SCRIPT_DIR/dss.sh program_evm.js tmdsevmk2h

EVMK2E little endian

> $DSS_SCRIPT_DIR/dss.sh program_evm.js tmdsevmk2e

10.2.3.1.6. Sample Output

C:\ti\processor_sdk_rtos_c665x_2_00_01_07\bin>%DSS_SCRIPT_DIR%\dss.bat program_evm.js tmdxevm6657ls-le
board: evm6657l
endian: Little
emulation: XDS200 emulator
binaries: ../prebuilt-images/
ccxml: C:\ti\processor_sdk_rtos_c665x_2_00_01_07\bin/configs/evm6657l/evm6657ls.ccxml
C66xx_0: GEL Output:
Connecting Target...

C66xx_0: GEL Output: DSP core #0

C66xx_0: GEL Output: C6657L GEL file Ver is 1.006

C66xx_0: GEL Output: Global Default Setup...

C66xx_0: GEL Output: Setup Cache...

C66xx_0: GEL Output: L1P = 32K

C66xx_0: GEL Output: L1D = 32K

C66xx_0: GEL Output: L2 = ALL SRAM

C66xx_0: GEL Output: Setup Cache... Done.

C66xx_0: GEL Output: Main PLL (PLL1) Setup ...

C66xx_0: GEL Output: PLL in Bypass ...

C66xx_0: GEL Output: PLL1 Setup for DSP @ 1000.0 MHz.

C66xx_0: GEL Output:            SYSCLK2 = 333.3333 MHz, SYSCLK5 = 200.0 MHz.

C66xx_0: GEL Output:            SYSCLK8 = 15.625 MHz.

C66xx_0: GEL Output: PLL1 Setup... Done.

C66xx_0: GEL Output: Power on all PSC modules and DSP domains...

C66xx_0: GEL Output: Set_PSC_State... Timeout Error #03 pd=12, md=4!

C66xx_0: GEL Output: Power on all PSC modules and DSP domains... Done.

C66xx_0: GEL Output: DDR3 PLL (PLL2) Setup ...

C66xx_0: GEL Output: DDR3 PLL Setup... Done.

C66xx_0: GEL Output: DDR3 Init begin (1333 auto)

C66xx_0: GEL Output: XMC Setup ... Done

C66xx_0: GEL Output: IFRDY bit is SET: DDR3 Interface Ready

C66xx_0: GEL Output:
DDR3 initialization is complete.

C66xx_0: GEL Output: DDR3 Init done

C66xx_0: GEL Output: DDR3 memory test... Started

C66xx_0: GEL Output: DDR3 memory test... Passed

C66xx_0: GEL Output: PLL and DDR3 Initialization completed(0) ...

C66xx_0: GEL Output: configSGMIISerdes Setup... Begin

C66xx_0: GEL Output: SGMII SERDES has been configured.

C66xx_0: GEL Output: Enabling EDC ...

C66xx_0: GEL Output: L1P error detection logic is enabled.

C66xx_0: GEL Output: L2 error detection/correction logic is enabled.

C66xx_0: GEL Output: MSMC error detection/correction logic is enabled.

C66xx_0: GEL Output: Enabling EDC ...Done

C66xx_0: GEL Output: Global Default Setup... Done.

Start writing eeprom50
Writer:../prebuilt-images/eepromwriter_evm6657l.out

Image:../prebuilt-images/eeprom50.bin

C66xx_0: GEL Output: Invalidate All Cache...

C66xx_0: GEL Output: Invalidate All Cache... Done.

C66xx_0: GEL Output: GEL Reset...

C66xx_0: GEL Output: GEL Reset... Done.

C66xx_0: GEL Output: Disable all EDMA3 interrupts and events.

EEPROM Writer Utility Version 01.00.00.05

Writing 57432 bytes from DSP memory address 0x0c000000 to EEPROM bus address 0x0050 starting from device address 0x0000
...
Reading 57432 bytes from EEPROM bus address 0x0050 to DSP memory address 0x0c010000 starting from device address 0x0000
...
Verifying data read ...
EEPROM programming completed successfully
Start writing eeprom51
Writer:../prebuilt-images/eepromwriter_evm6657l.out

Image:../prebuilt-images/eeprom51.bin

C66xx_0: GEL Output: Invalidate All Cache...

C66xx_0: GEL Output: Invalidate All Cache... Done.

C66xx_0: GEL Output: GEL Reset...

C66xx_0: GEL Output: GEL Reset... Done.

C66xx_0: GEL Output: Disable all EDMA3 interrupts and events.

EEPROM Writer Utility Version 01.00.00.05

Writing 47888 bytes from DSP memory address 0x0c000000 to EEPROM bus address 0x0051 starting from device address 0x0000
...
Reading 47888 bytes from EEPROM bus address 0x0051 to DSP memory address 0x0c010000 starting from device address 0x0000
...
Verifying data read ...
EEPROM programming completed successfully
Writer:../prebuilt-images/nandwriter_evm6657l.out

NAND:../prebuilt-images/nand.bin

Required NAND files does not exist in ../prebuilt-images/

Writer:../prebuilt-images/norwriter_evm6657l.out

NOR:../prebuilt-images/nor.bin

Required NOR files does not exist in ../prebuilt-images/

In the above example, nothing was flashed to NAND or NOR since there were no nand.bin or nor.bin binaries to flash.

10.2.4. Porting

10.2.4.1. Adding Custom Board_Library Target to Processor SDK RTOS makefiles

10.2.4.1.1. Introduction

The following article describes how a custom Board can be added to the Processor SDK RTOS. The scope of this article is to only describe how to modify the build files in the PDK to add build steps for your custom board library. The article does not describe modification of source files to reflect changes to clocking, DDR and pinmux setup for the custom board.

The instructions provided in this article uses example of AM572x custom board but the instructions apply to all the processors supported in Processor SDK RTOS. Note that the instructions on this wiki were created using Processor SDK RTOS v3.2 and PDK_AM57xx_1_0_5 and are subject to change. Also the wiki was created specifically for the newer board variants like evmAM572x, idkAM572x and evmK2G. For AM335x and AM437x variant board library has several dependencies on legacy starterware package, hence additional steps are required and not covered in the wiki.

10.2.4.1.2. Instructions to add custom Board to the PDK build

Step 1: Creating new directory for custom board library

In pdk_am57xx_x_x_x/packages/ti/board/src, Create new directory myCustomBoard and copy files from existing board library package. We recommend that you copy files from the board which closely matches your custom board design. In this case, we assume that the custom board is based on the design of evmAM572x so we copy over the files from that directory into myCustomBoard folder.

Step 2: Updating names and makefile inside the customBoard package

In pdk_am57xx_x_x_x/packages/ti/board/src/myCustomBoard, Rename file src_files_evmAM572x.mk to src_files_myCustomBoard.mk. This file will need a bit of work depending on what elements of board you need for your platform. We have left all the files evmAM572x_*.c but you can modify as needed.

Step 3: Adding MACRO based inclusion of updated board_cfg.h corresponding to custom Board

In packages/ti/board/board_cfg.h, add the lines pointing to board_cfg.h file in your customBoard package so that updated peripheral instances and board specific defines can be picked up

#if defined (myCustomBoard)
#include <ti/board/src/myCustomBoard/include/board_cfg.h>
#endif

Step 4: Update top level board package makefile to include build for customBoard Library The makefile is used to include all relevant make files for including Low level driver(LLD), source files relevant to board and the common board.c file

  • In packages/ti/board/build/makefile.mk, add board.c to the customBoard build :
ifeq ($(BOARD),$(filter $(BOARD),evmAM335x icev2AM335x skAM335x bbbAM335x evmAM437x idkAM437x skAM437x myCustomBoard evmAM572x idkAM571x idkAM572x evmK2H evmK2K evmK2E evmK2L evmK2G iceK2G evmC6678 evmC6657))
# Common source files across all platforms and cores
SRCS_COMMON += board.c
endif
  • Add board library source files and LLD files to the customBoard build

In packages/ti/board/build/makefile.mk, change

ifeq ($(BOARD),$(filter $(BOARD), evmAM572x idkAM571x idkAM572x))
include $(PDK_BOARD_COMP_PATH)/src/$(BOARD)/src_files_$(BOARD).mk
include $(PDK_BOARD_COMP_PATH)/src/src_files_lld.mk
CFLAGS_LOCAL_$(BOARD) += -D$(BOARD)
endif

to

ifeq ($(BOARD),$(filter $(BOARD), myCustomBoard evmAM572x idkAM571x idkAM572x))
include $(PDK_BOARD_COMP_PATH)/src/$(BOARD)/src_files_$(BOARD).mk
include $(PDK_BOARD_COMP_PATH)/src/src_files_lld.mk
CFLAGS_LOCAL_$(BOARD) += -D$(BOARD)
endif

Step 5: Update Global makerules

build_config.mk defines the global CFLAGS used to compile different PDK components. Add the following line in the BOARD Specific configurations.

CFLAGS_GLOBAL_customAM572x  = -DSOC_AM572x -DevmAM572x

The SOC_AM572x macro ensures that the CSL aplicable to this SOC will be included in the build and evmAM572x define will ensure all evmAM572x specific includes that apply to the customAM572x are part of the build.

Optional step to update RTSC platform definition If you have a custom RTSC platform definition for your custom board that updates the memory and platform configuration using RTSC Tool then you need to update the platform.mk file that associates the RTSC platfom with the corresponding board library

In packages/ti/buildmakerules/platform.mk, add the following lines:

ifeq ($(BOARD),$(filter $(BOARD), evmAM572x))
  PLATFORM_XDC = "ti.platforms.evmAM572X"
endif
ifeq ($(BOARD),$(filter $(BOARD), myCustomBoard))
  PLATFORM_XDC = "evmAM572XCustom"
endif

Note

The SYSBIOS platforms follow the convention to consolidate all platform definitions under SYSBIOS_INSTALL_PATH/packages/ti/platforms/* hence the convention ti.platorms.<platformName> but for custom platform, users are not required to follow this convention.

Step 6: Update source files corresponding to drivers used in board library. src_files_lld.mk file adds source files corresponding to LLD drivers used in the board library. Usually most boards utilitize control driver like I2C (for programming the PMIC or reading EEPROM), UART drivers (for IO) and boot media drivers like (SPI/QSPI, MMC or NAND). In the example below, we assume that the custom Board library has dependency on I2C, SPI and UART LLD drivers. Since the LLD drivers will be linked to the application along with board library, board library only needs <driver>_soc.c corresponding to SOC used on the custom Board.

In packages/ti/board/src/src_files_lld.mk, add the following lines:

ifeq ($(BOARD),$(filter $(BOARD), myCustomBoard))
SRCDIR +=  $(PDK_INSTALL_PATH)/ti/drv/i2c/soc/am572x \
           $(PDK_INSTALL_PATH)/ti/drv/uart/soc/am572x \
           $(PDK_INSTALL_PATH)/ti/drv/spi/soc/am572x
INCDIR +=  $(PDK_INSTALL_PATH)/ti/drv/i2c/soc/am572x \
           $(PDK_INSTALL_PATH)/ti/drv/uart/soc/am572x \
           $(PDK_INSTALL_PATH)/ti/drv/spi/soc/am572x
# Common source files across all platforms and cores
SRCS_COMMON += I2C_soc.c UART_soc.c SPI_soc.c
endif

Note

For all LLD drivers linked to the board library you need to include corresponding <drv>_soc.c file. For example if you include GPIO driver for setting board mux then GPIO_soc.c needs to be added to LLD source files.

Step 7: Add custom Board to BOARDLIST and update CORELIST

In packages/ti/board/board_component.mk, modify the build to add your custom board and specify the cores for which you want to build the board library. Example to build board library for only A15 and C66x cores, limit the build by specify only a15_0 and C66x in the CORELIST

board_lib_BOARDLIST       = myCustomBoard evmAM335x icev2AM335x skAM335x bbbAM335x evmAM437x idkAM437x skAM437x evmAM572x idkAM571x idkAM572x evmK2H evmK2K evmK2E evmK2L evmK2G iceK2G \
#board_lib_am572x_CORELIST = c66x a15_0 ipu1_0
board_lib_am572x_CORELIST = a15_0 c66x

Step 8: Update .bld files for XDCTOOL based build steps.

Make corresponding changes in packages/ti/board/config.bld, by adding the following lines:

var myCustomBoard = {
   name: "myCustomBoard",
   ccOpts: "-DevmAM572x -DSOC_AM572x",
   targets: [C66LE,A15LE ]
   lldFiles: [ "$(PDK_INSTALL_PATH)/ti/drv/i2c/soc/am572x/I2C_soc.c",
           "$(PDK_INSTALL_PATH)/ti/drv/uart/soc/am572x/UART_soc.c",
           "$(PDK_INSTALL_PATH)/ti/drv/spi/soc/am572x/SPI_soc.c"]
}
var boards = [ evmAM335x, icev2AM335x, skAM335x, bbbAM335x, evmAM437x, idkAM437x, skAM437x, myCustomBoard, evmAM572x, idkAM571x, idkAM572x, evmK2H, evmK2K, evmK2E, evmK2L, evmK2G, evmC6678, evmC6657 ];

Also, in packages/ti/board/package.bld, I added the following line:

Pkg.otherFiles[Pkg.otherFiles.length++] = "src/myCustomBoard/src_files_myCustomBoard.mk";

Step 9: Setup Top level PDK build files to add the Custom board to setup environment.

Final setup involves updating the top level setup file for PDK package to update to setup the build environment to include the custom Board in setup. This can be done by commenting out the top line and adding in the bottom line in pdksetupenv.bat:

@REM if not defined LIMIT_BOARDS set LIMIT_BOARDS=evmAM572x idkAM571x idkAM572x
if not defined LIMIT_BOARDS set LIMIT_BOARDS=myCustomBoard

Alternative: Invoke the build using command line options to limit the build to specific board, specific SOC and specific CORE. For example, if you want to build the A15 version of board library for AM572x EVM, you can invoke the build using:

gmake board_lib LIMIT_SOCS=am572x LIMIT_BOARDS=customAM572x LIMIT_CORES=a15_0

Step 10 : Building the custom board with the updated settings

To build package change directory to <SDK_INSTALL_PATH>/pdk_am57xx_x_x_x/packages, first run pdksetupenv.bat

To make just the board library: gmake board_lib

10.2.4.1.3. Example custom Board library for reference

The package provided below provides updated files for building customBoard “customAM572x” following all steps described above. Please compare the files to the evmAM57xx board library files to follow the steps to add your own board library.

File:Pdk packages ti board customAM572x.zip

Note

Due to software distribution policy on the wiki, we have removed the file linked here. Users can refer to the discussion and zipped package linked from E2E post provided below:

10.2.4.1.4. Additional steps for AM335x/AM437x users

Note

Currently the AM335x and AM437x board libraries re-use the board support that was used in legacy starterware software. AM335x and AM437x users will need to additionally modify build files in starterware to build their custom board library. Additional steps required for AM335x/AM437x will be added to this article soon in this section

10.2.4.2. Processor SDK RTOS Porting Guide for AM571x/AM570x Speed Grades

10.2.4.2.1. Description

The AM57x Family of Processors includes a wide range of operating performance to meet the needs of a number of broad applications. Among these options are a variety of speed grades to meet different performance points. These devices have a number of specialized cores to provide applications specific computation capabilities. These cores can be run at different speeds to fine tune the processor to the needs of the application, power budget, thermal characteristics, etc.

The Processor SDK for RTOS is a software development package provided to speed development by providing a software reference. This package now includes support for then entire AM57x family of processors which can be broken down into the AM572x, AM571x, and AM570x sets of devices or sub-familes. Most of the devices in this family are supported by the Processor SDK for RTOS right out of the box. This support is tested and validated on TI designed EVMs. These EVMs use the highest performance devices in the family in order to allow users to evaluate the entire spectrum of performance.

The AM571X and AM570x supports several lower power speed grades. If one of these devices is being used on the custom board, the GEL file and the board library needs to be changed to account for this difference. If this change is not made, the device could be running out of specification. These changes may reach across other cores and clocks on the device as well, depending on what speeds they need to operate at. This document is not an exhaustive list of all the changes needed for a proper board port as it focused on the changes needed to enable different speed grades.

10.2.4.2.2. Comparison of AM572x, AM571x and AM570x devices

Quick Feature Set comparison between devices in Sitara AM57xx family :

../_images/AM572x_AM571X_AM570x_Comparison.png

Supported OPP on AM57xx devices:
../_images/AM57xx_OPP.png

10.2.4.2.3. Code Composer Studio (CCS) and Emulation support

TI Supports following evaluation platform for AM57xx class of devices:

When developer selects any of the above platforms in Code composer Studio, the target configuration automatically brings in the required initialization files and GEL files to configure the clocks, slave cores, external memory.

If you are using a custom platform or AM5708 device that is not available on a TI Evaluation platform, you can follow the steps provided below to connect to the SOC by reusing the GEL files that are provided for TI evaluation platforms. For example, here we demonstrate how you can create a target configuration for AM570x and connect to the device if your board design is based of one of TI evalauation platforms listed below. The assumption here is that the custom board is based off AM571X IDK platform

Note

Support for AM5708 was added to Sitara Chip Support Package 1.3.4 in Code composer Studio. If you don`t see the device definition in CCS, then you can update the Sitara Chip Support package by going to Help->Check Updates

Step 1: Select the AM570x part number that is populated on your custom platform:

../_images/AM5708_EVM_target_configurations.png

Step 2: Setup the GEL files for the SOC Go to the Advanced Tab as shown in the previous screenshot and update startup GEL file in the A15 Core as shown in the screenshot below

../_images/Advanced_settings_GEL_setup.png

10.2.4.2.4. Board Library Changes to Consider for Using Processor SDK RTOS

10.2.4.2.4.1. Clock and PRCM Updates to consider

The board library provides setting for OPP_NOM, OPP_OD and OPP_HIGH in the PLL settings using 20 MHz input clock that has been used on the AM572x GP EVM as well as the AM571x IDK platform. This allows customers to setup the MPU to 1.5, 1.176 and 1GHz. For AM570x devices, we support the “J” and the “D” variant which support the following max speeds on the DPLLs:

../_images/AM5706_Speed_Grades.png

When using the “J” speed grade, ensure that the DPLLs in the board set the DPLL to OPP_NOM and not for OPP_OD or OPP_HIGH.

To do this, you can invoke the Board_Init from your application using either

Board_initCfg boardCfg;
boardCfg = BOARD_INIT_PLL_OPP_NOM;
boardCfg |= BOARD_INIT_UNLOCK_MMR |
       BOARD_INIT_MODULE_CLOCK |
       BOARD_INIT_PINMUX_CONFIG |
       BOARD_INIT_DDR |
       BOARD_INIT_UART_STDIO |
       BOARD_INIT_WATCHDOG_DISABLE;
/* Board Library Init. */
   Board_init(boardCfg);

Note

When bootloading direct from flash media, this change may also be required in the SBL code

When using “D” rated parts that run at 500 MHz, in addition to the above configuration, you will also need to modify OPP_NOM settings in the board library by updating the DPLL setting for MPU and DSP in the file <BoardName>_pll.c as shown below:

Step1 : Update MPU, DSP, IVA and GPU DPLL setting

  • MPU DPLL Changes:
/* Default to OPP_NOM */
     /* 500MHz at 20MHz sys_clk */
     mpuPllcParam.mult = 250U;
     mpuPllcParam.div = 9U;
     mpuPllcParam.dccEnable = 0U;
     mpuPllcParam.divM2 = 1U;
  • DSP DPLL Changes:
/* 500MHz at 20MHz sys_clk */
dspPllcParam.mult = 130U;
dspPllcParam.div = 3U;
dspPllcParam.divM2 = 1U;
dspPllcParam.divM3 = 3U;
  • Remove IVA and GPU PLL settings

Since IVA and GPU modules are not available on the device, we recommend removing the ivaPLL and gpuPLL settings in board.

              /* Default to OPP_NOM */
              /* 388.3MHz at 20MHz sys_clk */
-                ivaPllcParam.mult = 233U;
-                ivaPllcParam.div = 3U;
-                ivaPllcParam.divM2 = 3U;
             /* Default to OPP_NOM */
             /* 425MHz at 20MHz sys_clk */
-                gpuPllcParam.mult = 170U;
-                gpuPllcParam.div = 3U;
-                gpuPllcParam.divM2 = 2U;

Step 2 : Disable clocks configuration and wakeup for IVA in PRCM

  • Remove IVA wakeup and Module configuration

The following updates need to be made in the file <BoardName>_clock.c to remove IVA wakeup and clock configuration

-        CSL_FINST(ivaCmReg->CM_IVA_CLKSTCTRL_REG,
-        IVA_CM_CORE_CM_IVA_CLKSTCTRL_REG_CLKTRCTRL, SW_WKUP);
   /* PRCM Specialized module mode setting functions */
-   CSL_FINST(ivaCmReg->CM_IVA_SL2_CLKCTRL_REG,
-       IVA_CM_CORE_CM_IVA_SL2_CLKCTRL_REG_MODULEMODE, AUTO);
-  while(CSL_IVA_CM_CORE_CM_IVA_SL2_CLKCTRL_REG_IDLEST_DISABLE ==
-      CSL_FEXT(ivaCmReg->CM_IVA_SL2_CLKCTRL_REG,
-       IVA_CM_CORE_CM_IVA_SL2_CLKCTRL_REG_IDLEST));
-   CSL_FINST(ivaCmReg->CM_IVA_IVA_CLKCTRL_REG,
-       IVA_CM_CORE_CM_IVA_IVA_CLKCTRL_REG_MODULEMODE, AUTO);
-   while(CSL_IVA_CM_CORE_CM_IVA_IVA_CLKCTRL_REG_IDLEST_DISABLE ==
-      CSL_FEXT(ivaCmReg->CM_IVA_IVA_CLKCTRL_REG,
-       IVA_CM_CORE_CM_IVA_IVA_CLKCTRL_REG_IDLEST));

10.2.4.2.5. Configure DDR Interfaces

An important one to consider is the speed of the DDR memory. The clock for the DDR is selected using the same dplls structure. Some higher speed grade parts support a 667 MHz DDR clock, but some of the lower speed grade parts only support a 533 MHz DDR3 clock. Make sure to choose the appropriate DDR clock for the device on the custom board.

Over in the board/src/<BoardName>/<BoardName_ddr>.c file, make sure that the EMIF is being configured correctly for the appropriate speed, and that the appropriate number of EMIFs is being selected to match the part being used. AM572x part has 2 DDR interfaces running at 533 MHz and the AM571x (and AM570x) only have one running at 667 MHz. This code can be kept or removed by the board port. As changes are made, the code must make sure to configure the new board correctly, with the appropriate number of DDR interfaces and speed configuration.

For AM571x and AM570x, make sure to use the code for the AM571x IDK in board/src/<BoardName>/<BoardName_ddr>.c to select 1 EMIF:

/* MA_LISA_MAP_i */
hMampuLsm->MAP_0 = 0x80600100U;
/* DMM_LISA_MAP_i */
hDmmCfg->LISA_MAP[0U] = 0x80600100U;

For AM572x, this is mapped as following

/* MA_LISA_MAP_i */
hMampuLsm->MAP_0 = 0x80740300;
hMampuLsm->MAP_1 = 0x80740300;
/* DMM_LISA_MAP_i */
hDmmCfg->LISA_MAP[0U] = 0x80740300;
hDmmCfg->LISA_MAP[1U] = 0x80740300;

Note

Processor SDK RTOS provides am570x_ddr.c file in the idkAM571x board library for reference for configuring DDR on AM570x parts

10.2.4.2.6. Pinmux Changes to Consider

  • For part number where the Display subsystem or SATA is not available, the pins can be configured to any other pin functionality that may be required in the system. If you don`t need to use these pins, we recommend that you leave these pins in default MUXMODE and terminate the pinmux as recommended in the Schematics Checklist.
  • There is no pinmux setting for CSI2 module so you can leave the MUXMODE=0 on those pins if there is no instance of the peripheral

Note

Processor SDK RTOS provides board/src/idkAM571x/include/am570x_pinmux.h file in the idkAM571x board library for reference for configuring pinmux on AM570x based hardware platform

10.2.4.2.7. Driver SOC Module clock changes

Some control drivers use default Module input clock frequency settings in <module>_soc.c file that gets used by the Low level drivers to configure the peripheral clocks. The default module input clock frequency is set to the OPP_NOM values that are available on the superset variant of the device so if you are using lower speed grades. Ensure you change the default to match the module clock on the 500 MHz settings or you can use the following sequence to update the settings. Code below describes how the SPI driver module input clock frequency can be modified

SPI_v1_HWAttrs spi_cfg;
/* Get the default SPI init configurations */
SPI_socGetInitCfg(TEST_SPI_PORT, &spi_cfg);
/* Modify the default SPI configurations if necessary */
spi_cfg.inputClkFreq = 24000000;
/* Set the default SPI init configurations */
SPI_socSetInitCfg(TEST_SPI_PORT, &spi_cfg);

10.2.4.2.8. Related Article for Processor SDK Linux developers

Useful Utilities

10.2.4.2.9. Support

For any questions related Usage of AM572x, AM571x and AM570x devices, please post your question on TI E2E Forums

10.2.5. System Integration

10.2.5.1. Create DSP and IPU firmware using PDK drivers and IPC to load from ARM Linux on AM57xx devices

10.2.5.1.1. Introduction

This article is geared toward AM57xx users that are running Linux on the Cortex A15. The goal is to help users understand how to gain entitlement to the DSP (c66x) and IPU (Cortex M4) subsystems of the AM57xx.

AM572x device has two IPU subsystems (IPUSS), each of which has 2 cores. IPU2 is used as a controller in multi-media applications, so if you have Processor SDK Linux running, chances are that IPU2 already has firmware loaded. However, IPU1 is open for general purpose programming to offload the ARM tasks.

There are many facets to this task: building, loading, debugging, MMUs, memory sharing, etc. This article intends to take incremental steps toward understanding all of those pieces.

Software Dependencies to Get Started

Prerequisites

Note

Please be sure that you have the same version number for both Processor SDK RTOS and Linux.

For reference within the context of this wiki page, the Linux SDK is installed at the following location:

/mnt/data/user/ti-processor-sdk-linux-am57xx-evm-xx.xx.xx.xx
├── bin
├── board-support
├── docs
├── example-applications
├── filesystem
├── ipc-build.txt
├── linux-devkit
├── Makefile
├── Rules.make
└── setup.sh

The RTOS SDK is installed at:

/mnt/data/user/my_custom_install_sdk_rtos_am57xx_xx.xx
├── bios_6_xx_xx_xx
├── cg_xml
├── ctoolslib_x_x_x_x
├── dsplib_c66x_x_x_x_x
├── edma3_lld_2_xx_xx_xx
├── framework_components_x_xx_xx_xx
├── imglib_c66x_x_x_x_x
├── ipc_3_xx_xx_xx
├── mathlib_c66x_3_x_x_x
├── ndk_2_xx_xx_xx
├── opencl_rtos_am57xx_01_01_xx_xx
├── openmp_dsp_am57xx_2_04_xx_xx
├── pdk_am57xx_x_x_x
├── processor_sdk_rtos_am57xx_x_xx_xx_xx
├── uia_2_xx_xx_xx
├── xdais_7_xx_xx_xx

CCS is installed at:

/mnt/data/user/ti/my_custom_ccs_x.x.x_install
├── ccsvX
│   ├── ccs_base
│   ├── doc
│   ├── eclipse
│   ├── install_info
│   ├── install_logs
│   ├── install_scripts
│   ├── tools
│   ├── uninstall_ccs
│   ├── uninstall_ccs.dat
│   ├── uninstallers
│   └── utils
├── Code Composer Studio x.x.x.desktop
└── xdctools_x_xx_xx_xx_core
    ├── bin
    ├── config.jar
    ├── docs
    ├── eclipse
    ├── etc
    ├── gmake
    ├── include
    ├── package
    ├── packages
    ├── package.xdc
    ├── tconfini.tcf
    ├── xdc
    ├── xdctools_3_xx_xx_xx_manifest.html
    ├── xdctools_3_xx_xx_xx_release_notes.html
    ├── xs
    └── xs.x86U

Typical Boot Flow on AM572x for ARM Linux users

AM57xx SOC’s have multiple processor cores - Cortex A15, C66x DSP’s and ARM M4 cores. The A15 typically runs a HLOS like Linux/QNX/Android and the remotecores(DSP’s and M4’s) run a RTOS. In the normal operation, boot loader(U-Boot/SPL) boots and loads the A15 with the HLOS. The A15 boots the DSP and the M4 cores.

../_images/Normal-boot.png

In this sequence, the interval between the Power on Reset and the remotecores (i.e. the DSP’s and the M4’s) executing is dependent on the HLOS initialization time.


10.2.5.1.2. Getting Started with IPC Linux Examples

The figure below illustrates how remoteproc/rpmsg driver from ARM Linux kernel communicates with IPC driver on slave processor (e.g. DSP, IPU, etc) running RTOS.

../_images/LinuxIPC_with_RTOS_Slave.png

In order to setup IPC on slave cores, we provide some pre-built examples in IPC package that can be run from ARM Linux. The subsequent sections describe how to build and run this examples and use that as a starting point for this effort.

Building the Bundled IPC Examples

The instructions to build IPC examples found under ipc_3_xx_xx_xx/examples/DRA7XX_linux_elf have been provided in the `Processor_SDK IPC Quick Start Guide <http://processors.wiki.ti.com/index.php/Processor_SDK_IPC_Quick_Start_Guide#Build_IPC_Linux_examples>`__.

Let’s focus on one example in particular, ex02_messageq, which is located at <rtos-sdk-install-dir>/ipc_3_xx_xx_xx/examples/DRA7XX_linux_elf/ex02_messageq. Here are the key files that you should see after a successful build:

├── dsp1
│   └── bin
│       ├── debug
│       │   └── server_dsp1.xe66
│       └── release
│           └── server_dsp1.xe66
├── dsp2
│   └── bin
│       ├── debug
│       │   └── server_dsp2.xe66
│       └── release
│           └── server_dsp2.xe66
├── host
│       ├── debug
│       │   └── app_host
│       └── release
│           └── app_host
├── ipu1
│   └── bin
│       ├── debug
│       │   └── server_ipu1.xem4
│       └── release
│           └── server_ipu1.xem4
└── ipu2
    └── bin
        ├── debug
        │   └── server_ipu2.xem4
        └── release
            └── server_ipu2.xem4


Running the Bundled IPC Examples

On the target, let’s create a directory called ipc-starter:

root@am57xx-evm:~# mkdir -p /home/root/ipc-starter
root@am57xx-evm:~# cd /home/root/ipc-starter/

You will need to copy the ex02_messageq directory of your host PC to that directory on the target (through SD card, NFS export, SCP, etc.). You can copy the entire directory, though we’re primarily interested in these files:

  • dsp1/bin/debug/server_dsp1.xe66
  • dsp2/bin/debug/server_dsp2.xe66
  • host/bin/debug/app_host
  • ipu1/bin/debug/server_ipu1.xem4
  • ipu2/bin/debug/server_ipu2.xem4

The remoteproc driver is hard-coded to look for specific files when loading the DSP/M4. Here are the files it looks for:

  • /lib/firmware/dra7-dsp1-fw.xe66
  • /lib/firmware/dra7-dsp2-fw.xe66
  • /lib/firmware/dra7-ipu1-fw.xem4
  • /lib/firmware/dra7-ipu2-fw.xem4

These are generally a soft link to the intended executable. So for example, let’s update the DSP1 executable on the target:

root@am57xx-evm:~# cd /lib/firmware/
root@am57xx-evm:/lib/firmware# rm dra7-dsp1-fw.xe66
root@am57xx-evm:/lib/firmware# ln -s /home/root/ipc-starter/ex02_messageq/dsp1/bin/debug/server_dsp1.xe66 dra7-dsp1-fw.xe66

To reload DSP1 with this new executable, we perform the following steps:

root@am57xx-evm:/lib/firmware# cd /sys/bus/platform/drivers/omap-rproc/
root@am57xx-evm:/sys/bus/platform/drivers/omap-rproc# echo 40800000.dsp > unbind
[27639.985631] omap_hwmod: mmu0_dsp1: _wait_target_disable failed
[27639.991534] omap-iommu 40d01000.mmu: 40d01000.mmu: version 3.0
[27639.997610] omap-iommu 40d02000.mmu: 40d02000.mmu: version 3.0
[27640.017557] omap_hwmod: mmu1_dsp1: _wait_target_disable failed
[27640.030571] omap_hwmod: mmu0_dsp1: _wait_target_disable failed
[27640.036605]  remoteproc2: stopped remote processor 40800000.dsp
[27640.042805]  remoteproc2: releasing 40800000.dsp
root@am57xx-evm:/sys/bus/platform/drivers/omap-rproc# echo 40800000.dsp > bind
[27645.958613] omap-rproc 40800000.dsp: assigned reserved memory node dsp1_cma@99000000
[27645.966452]  remoteproc2: 40800000.dsp is available
[27645.971410]  remoteproc2: Note: remoteproc is still under development and considered experimental.
[27645.980536]  remoteproc2: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed.
root@am57xx-evm:/sys/bus/platform/drivers/omap-rproc# [27646.008171]  remoteproc2: powering up 40800000.dsp
[27646.013038]  remoteproc2: Booting fw image dra7-dsp1-fw.xe66, size 4706800
[27646.028920] omap_hwmod: mmu0_dsp1: _wait_target_disable failed
[27646.034819] omap-iommu 40d01000.mmu: 40d01000.mmu: version 3.0
[27646.040772] omap-iommu 40d02000.mmu: 40d02000.mmu: version 3.0
[27646.058323]  remoteproc2: remote processor 40800000.dsp is now up
[27646.064772] virtio_rpmsg_bus virtio2: rpmsg host is online
[27646.072271]  remoteproc2: registered virtio2 (type 7)
[27646.078026] virtio_rpmsg_bus virtio2: creating channel rpmsg-proto addr 0x3d

More info related to loading firmware to the various cores can be found here.

Finally, we can run the example on DSP1:

root@am57xx-evm:/sys/bus/platform/drivers/omap-rproc# cd /home/root/ipc-starter/ex02_messageq/host/bin/debug
root@am57xx-evm:~/ipc-starter/ex02_messageq/host/bin/debug# ./app_host DSP1
--> main:
[33590.700700] omap_hwmod: mmu0_dsp2: _wait_target_disable failed
[33590.706609] omap-iommu 41501000.mmu: 41501000.mmu: version 3.0
[33590.718798] omap-iommu 41502000.mmu: 41502000.mmu: version 3.0
--> Main_main:
--> App_create:
App_create: Host is ready
<-- App_create:
--> App_exec:
App_exec: sending message 1
App_exec: sending message 2
App_exec: sending message 3
App_exec: message received, sending message 4
App_exec: message received, sending message 5
App_exec: message received, sending message 6
App_exec: message received, sending message 7
App_exec: message received, sending message 8
App_exec: message received, sending message 9
App_exec: message received, sending message 10
App_exec: message received, sending message 11
App_exec: message received, sending message 12
App_exec: message received, sending message 13
App_exec: message received, sending message 14
App_exec: message received, sending message 15
App_exec: message received
App_exec: message received
App_exec: message received
<-- App_exec: 0
--> App_delete:
<-- App_delete:
<-- Main_main:
<-- main:

The similar procedure can be used for DSP2/IPU1/IPU2 also to update the soft link of the firmware, reload the firmware at run-time, and run the host binary from A15.

10.2.5.1.3. Understanding the Memory Map

Overall Linux Memory Map

root@am57xx-evm:~# cat /proc/iomem
[snip...]
58060000-58078fff : core
58820000-5882ffff : l2ram
58882000-588820ff : /ocp/mmu@58882000
80000000-9fffffff : System RAM
80008000-808d204b : Kernel code
80926000-809c96bf : Kernel data
a0000000-abffffff : CMEM
ac000000-ffcfffff : System RAM

CMA Carveouts

root@am57xx-evm:~# dmesg | grep -i cma
[    0.000000] Reserved memory: created CMA memory pool at 0x0000000095800000, size 56 MiB
[    0.000000] Reserved memory: initialized node ipu2_cma@95800000, compatible id shared-dma-pool
[    0.000000] Reserved memory: created CMA memory pool at 0x0000000099000000, size 64 MiB
[    0.000000] Reserved memory: initialized node dsp1_cma@99000000, compatible id shared-dma-pool
[    0.000000] Reserved memory: created CMA memory pool at 0x000000009d000000, size 32 MiB
[    0.000000] Reserved memory: initialized node ipu1_cma@9d000000, compatible id shared-dma-pool
[    0.000000] Reserved memory: created CMA memory pool at 0x000000009f000000, size 8 MiB
[    0.000000] Reserved memory: initialized node dsp2_cma@9f000000, compatible id shared-dma-pool
[    0.000000] cma: Reserved 24 MiB at 0x00000000fe400000
[    0.000000] Memory: 1713468K/1897472K available (6535K kernel code, 358K rwdata, 2464K rodata, 332K init, 289K bss, 28356K reserved, 155648K  cma-reserved, 1283072K highmem)
[    5.492945] omap-rproc 58820000.ipu: assigned reserved memory node ipu1_cma@9d000000
[    5.603289] omap-rproc 55020000.ipu: assigned reserved memory node ipu2_cma@95800000
[    5.713411] omap-rproc 40800000.dsp: assigned reserved memory node dsp1_cma@9b000000
[    5.771990] omap-rproc 41000000.dsp: assigned reserved memory node dsp2_cma@9f000000

From the output above, we can derive the location and size of each CMA carveout:

Memory Section Physical Address Size
IPU2 CMA 0x95800000 56 MB
DSP1 CMA 0x99000000 64 MB
IPU1 CMA 0x9d000000 32 MB
DSP2 CMA 0x9f000000 8 MB
Default CMA 0xfe400000 24 MB

For details on how to adjust the sizes and locations of the DSP/IPU CMA carveouts, please see the corresponding section for changing the DSP or IPU memory map.

To adjust the size of the “Default CMA” section, this is done as part of the Linux config:

linux/arch/arm/configs/tisdk_am57xx-evm_defconfig

#
# Default contiguous memory area size:
#
CONFIG_CMA_SIZE_MBYTES=24
CONFIG_CMA_SIZE_SEL_MBYTES=y

CMEM

To view the allocation at run-time:

root@am57xx-evm:~# cat /proc/cmem

Block 0: Pool 0: 1 bufs size 0xc000000 (0xc000000 requested)

Pool 0 busy bufs:

Pool 0 free bufs:
id 0: phys addr 0xa0000000

This shows that we have defined a CMEM block at physical base address of 0xA0000000 with total size 0xc000000 (192 MB). This block contains a buffer pool consisting of 1 buffer. Each buffer in the pool (only one in this case) is defined to have a size of 0xc000000 (192 MB).

Here is where those sizes/addresses were defined for the AM57xx EVM:

linux/arch/arm/boot/dts/am57xx-evm-cmem.dtsi

{
       reserved-memory {
               #address-cells = <2>;
               #size-cells = <2>;
               ranges;

               cmem_block_mem_0: cmem_block_mem@a0000000 {
                       reg = <0x0 0xa0000000 0x0 0x0c000000>;
                       no-map;
                       status = "okay";
               };

               cmem_block_mem_1_ocmc3: cmem_block_mem@40500000 {
                       reg = <0x0 0x40500000 0x0 0x100000>;
                       no-map;
                       status = "okay";
               };
       };

       cmem {
               compatible = "ti,cmem";
               #address-cells = <1>;
               #size-cells = <0>;

               #pool-size-cells = <2>;

               status = "okay";

               cmem_block_0: cmem_block@0 {
                       reg = <0>;
                       memory-region = <&cmem_block_mem_0>;
                       cmem-buf-pools = <1 0x0 0x0c000000>;
               };

               cmem_block_1: cmem_block@1 {
                       reg = <1>;
                       memory-region = <&cmem_block_mem_1_ocmc3>;
               };
       };
};

Changing the DSP Memory Map

First, it is important to understand that there are a pair of Memory Management Units (MMUs) that sit between the DSP subsystems and the L3 interconnect. One of these MMUs is for the DSP core and the other is for its local EDMA. They both serve the same purpose of translating virtual addresses (i.e. the addresses as viewed by the DSP subsystem) into physical addresses (i.e. addresses as viewed from the L3 interconnect).

../_images/LinuxIpcDspMmu.png

DSP Physical Addresses

The physical location where the DSP code/data will actually reside is defined by the CMA carveout. To change this location, you must change the definition of the carveout. The DSP carveouts are defined in the Linux dts file. For example for the AM57xx EVM:


linux/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi

{
        dsp1_cma_pool: dsp1_cma@99000000 {
                compatible = "shared-dma-pool";
                reg = <0x0 0x99000000 0x0 0x4000000>;
                reusable;
                status = "okay";
        };

        dsp2_cma_pool: dsp2_cma@9f000000 {
                compatible = "shared-dma-pool";
                reg = <0x0 0x9f000000 0x0 0x800000>;
                reusable;
                status = "okay";
        };
};

You are able to change both the size and location. Be careful not to overlap any other carveouts!

Note

The two location entries for a given DSP must be identical!


Additionally, when you change the carveout location, there is a corresponding change that must be made to the resource table. For starters, if you’re making a memory change you will need a custom resource table. The resource table is a large structure that is the “bridge” between physical memory and virtual memory. This structure is utilized for configuring the MMUs that sit in front of the DSP subsystem. There is detailed information available in the article IPC Resource customTable.

Once you’ve created your custom resource table, you must update the address of PHYS_MEM_IPC_VRING to be the same base address as your corresponding CMA.

#if defined (VAYU_DSP_1)
#define PHYS_MEM_IPC_VRING      0x99000000
#elif defined (VAYU_DSP_2)
#define PHYS_MEM_IPC_VRING      0x9F000000
#endif

Note

The PHYS_MEM_IPC_VRING definition from the resource table must match the address of the associated CMA carveout!

DSP Virtual Addresses

These addresses are the ones seen by the DSP subsystem, i.e. these will be the addresses in your linker command files, etc.

You must ensure that the sizes of your sections are consistent with the corresponding definitions in the resource table. You should create your own resource table in order to modify the memory map. This is describe in the wiki page IPC Resource customTable. You can look at an existing resource table inside IPC:

ipc/packages/ti/ipc/remoteproc/rsc_table_vayu_dsp.h

{
    TYPE_CARVEOUT,
    DSP_MEM_TEXT, 0,
    DSP_MEM_TEXT_SIZE, 0, 0, "DSP_MEM_TEXT",
},

{
    TYPE_CARVEOUT,
    DSP_MEM_DATA, 0,
    DSP_MEM_DATA_SIZE, 0, 0, "DSP_MEM_DATA",
},

{
    TYPE_CARVEOUT,
    DSP_MEM_HEAP, 0,
    DSP_MEM_HEAP_SIZE, 0, 0, "DSP_MEM_HEAP",
},

{
    TYPE_CARVEOUT,
    DSP_MEM_IPC_DATA, 0,
    DSP_MEM_IPC_DATA_SIZE, 0, 0, "DSP_MEM_IPC_DATA",
},

{
    TYPE_TRACE, TRACEBUFADDR, 0x8000, 0, "trace:dsp",
},


{
    TYPE_DEVMEM,
    DSP_MEM_IPC_VRING, PHYS_MEM_IPC_VRING,
    DSP_MEM_IPC_VRING_SIZE, 0, 0, "DSP_MEM_IPC_VRING",
},

Let’s have a look at some of these to understand them better. For example:

{
    TYPE_CARVEOUT,
    DSP_MEM_TEXT, 0,
    DSP_MEM_TEXT_SIZE, 0, 0, "DSP_MEM_TEXT",
},

Key points to note are:

  1. The “TYPE_CARVEOUT” indicates that the physical memory backing this entry will come from the associated CMA pool.
  2. DSP_MEM_TEXT is a #define earlier in the code providing the address for the code section. It is 0x95000000 by default. This must correspond to a section from your DSP linker command file, i.e. EXT_CODE (or whatever name you choose to give it) must be linked to the same address.
  3. DSP_MEM_TEXT_SIZE is the size of the MMU pagetable entry being created (1MB in this particular instance). The actual amount of linked code in the corresponding section of your executable must be less than or equal to this size.

Let’s take another:

{
    TYPE_TRACE, TRACEBUFADDR, 0x8000, 0, "trace:dsp",
},

Key points are:

  1. The “TYPE_TRACE” indicates this is for trace info.
  2. The TRACEBUFADDR is defined earlier in the file as &ti_trace_SysMin_Module_State_0_outbuf__A. That corresponds to the symbol used in TI-RTOS for the trace buffer.
  3. The “0x8000” is the size of the MMU mapping. The corresponding size in the cfg file should be the same (or less). It looks like this: SysMin.bufSize  = 0x8000;

Finally, let’s look at a TYPE_DEVMEM example:

{
    TYPE_DEVMEM,
    DSP_PERIPHERAL_L4CFG, L4_PERIPHERAL_L4CFG,
    SZ_16M, 0, 0, "DSP_PERIPHERAL_L4CFG",
},

Key points:

  1. The “TYPE_DEVMEM” indicates that we are making an MMU mapping, but this does not come from the CMA pool. This is intended for mapping peripherals, etc. that already exist in the device memory map.
  2. DSP_PERIPHERAL_L4CFG (0x4A000000) is the virtual address while L4_PERIPHERAL_L4CFG (0x4A000000) is the physical address. This is an identity mapping, meaning that peripherals can be referenced by the DSP using their physical address.

DSP Access to Peripherals

The default resource table creates the following mappings:

Virtual Address Physical Address Size Comment
0x4A000000 0x4A000000 16 MB L4CFG + L4WKUP
0x48000000 0x48000000 2 MB L4PER1
0x48400000 0x48400000 4 MB L4PER2
0x48800000 0x48800000 8 MB L4PER3
0x54000000 0x54000000 16 MB L3_INSTR + CT_TBR
0x4E000000 0x4E000000 1 MB DMM config

In other words, the peripherals can be accessed at their physical addresses since we use an identity mapping.

Inspecting the DSP IOMMU Page Tables at Run-Time

You can dump the DSP IOMMU page tables with the following commands:

DSP MMU Command
DSP1 MMU0 cat /sys/kernel/debug/omap_iommu/40d01000.mmu/pagetable
DSP1 MMU1 cat /sys/kernel/debug/omap_iommu/40d02000.mmu/pagetable
DSP2 MMU0 cat /sys/kernel/debug/omap_iommu/41501000.mmu/pagetable
DSP2 MMU1 cat /sys/kernel/debug/omap_iommu/41502000.mmu/pagetable

In general, MMU0 and MMU1 are being programmed identically so you really only need to take a look at one or the other to understand the mapping for a given DSP.

For example:

root@am57xx-evm:~# cat /sys/kernel/debug/omap_iommu/40d01000.mmu/pagetable
L:      da:     pte:
--------------------------
1: 0x48000000 0x48000002
1: 0x48100000 0x48100002
1: 0x48400000 0x48400002
1: 0x48500000 0x48500002
1: 0x48600000 0x48600002
1: 0x48700000 0x48700002
1: 0x48800000 0x48800002
1: 0x48900000 0x48900002
1: 0x48a00000 0x48a00002
1: 0x48b00000 0x48b00002
1: 0x48c00000 0x48c00002
1: 0x48d00000 0x48d00002
1: 0x48e00000 0x48e00002
1: 0x48f00000 0x48f00002
1: 0x4a000000 0x4a040002
1: 0x4a100000 0x4a040002
1: 0x4a200000 0x4a040002
1: 0x4a300000 0x4a040002
1: 0x4a400000 0x4a040002
1: 0x4a500000 0x4a040002
1: 0x4a600000 0x4a040002
1: 0x4a700000 0x4a040002
1: 0x4a800000 0x4a040002
1: 0x4a900000 0x4a040002
1: 0x4aa00000 0x4a040002
1: 0x4ab00000 0x4a040002
1: 0x4ac00000 0x4a040002
1: 0x4ad00000 0x4a040002
1: 0x4ae00000 0x4a040002
1: 0x4af00000 0x4a040002

The first column tells us whether the mapping is a Level 1 or Level 2 descriptor. All the lines above are a first level descriptor, so we look at the associated format from the TRM:

../_images/LinuxIpcPageTableDescriptor1.png

The “da” (“device address”) column reflects the virtual address. It is derived from the index into the table, i.e. there does not exist a “da” register or field in the page table. Each MB of the address space maps to an entry in the table. The “da” column is displayed to make it easy to find the virtual address of interest.

The “pte” (“page table entry”) column can be decoded according to Table 20-4 shown above. For example:

1: 0x4a000000 0x4a040002

The 0x4a040002 shows us that it is a Supersection with base address 0x4A000000. This gives us a 16 MB memory page. Note the repeated entries afterward. That’s a requirement of the MMU. Here’s an excerpt from the TRM:

Note

Supersection descriptors must be repeated 16 times, because each descriptor in the first level translation table describes 1 MiB of memory. If an access points to a descriptor that is not initialized, the MMU will behave in an unpredictable way.


Changing Cortex M4 IPU Memory Map

In order to fully understand the memory mapping of the Cortex M4 IPU Subsystems, it’s helpful to recognize that there are two distinct/independent levels of memory translation. Here’s a snippet from the TRM to illustrate:

../_images/LinuxIpcIpuMmu.png

Cortex M4 IPU Physical Addresses

The physical location where the M4 code/data will actually reside is defined by the CMA carveout. To change this location, you must change the definition of the carveout. The M4 carveouts are defined in the Linux dts file. For example for the AM57xx EVM:



linux/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi

{
        ipu2_cma_pool: ipu2_cma@95800000 {
                compatible = "shared-dma-pool";
                reg = <0x0 95800000 0x0 0x3800000>;
                reusable;
                status = "okay";
        };

        ipu1_cma_pool: ipu1_cma@9d000000 {
                compatible = "shared-dma-pool";
                reg = <0x0 9d000000 0x0 0x2000000>;
                reusable;
                status = "okay";
        };
};

You are able to change both the size and location. Be careful not to overlap any other carveouts!

Note

The two location entries for a given carveout must be identical!


Additionally, when you change the carveout location, there is a corresponding change that must be made to the resource table. For starters, if you’re making a memory change you will need a custom resource table. The resource table is a large structure that is the “bridge” between physical memory and virtual memory. This structure is utilized for configuring the IPUx_MMU (not the Unicache MMU). There is detailed information available in the article IPC Resource customTable.

Once you’ve created your custom resource table, you must update the address of PHYS_MEM_IPC_VRING to be the same base address as your corresponding CMA.

#if defined(VAYU_IPU_1)
#define PHYS_MEM_IPC_VRING      0x9D000000
#elif defined (VAYU_IPU_2)
#define PHYS_MEM_IPC_VRING      0x95800000
#endif

Note

The PHYS_MEM_IPC_VRING definition from the resource table must match the address of the associated CMA carveout!

Cortex M4 IPU Virtual Addresses

Unicache MMU

The Unicache MMU sits closest to the Cortex M4. It provides the first level of address translation. The Unicache MMU is actually “self programmed” by the Cortex M4. The Unicache MMU is also referred to as the Attribute MMU (AMMU). There are a fixed number of small, medium and large pages. Here’s a snippet showing some of the key mappings:

ipc_3_43_02_04/examples/DRA7XX_linux_elf/ex02_messageq/ipu1/IpuAmmu.cfg

/*********************** Large Pages *************************/
/* Instruction Code: Large page  (512M); cacheable */
/* config large page[0] to map 512MB VA 0x0 to L3 0x0 */
AMMU.largePages[0].pageEnabled = AMMU.Enable_YES;
AMMU.largePages[0].logicalAddress = 0x0;
AMMU.largePages[0].translationEnabled = AMMU.Enable_NO;
AMMU.largePages[0].size = AMMU.Large_512M;
AMMU.largePages[0].L1_cacheable = AMMU.CachePolicy_CACHEABLE;
AMMU.largePages[0].L1_posted = AMMU.PostedPolicy_POSTED;

/* Peripheral regions: Large Page (512M); non-cacheable */
/* config large page[1] to map 512MB VA 0x60000000 to L3 0x60000000 */
AMMU.largePages[1].pageEnabled = AMMU.Enable_YES;
AMMU.largePages[1].logicalAddress = 0x60000000;
AMMU.largePages[1].translationEnabled = AMMU.Enable_NO;
AMMU.largePages[1].size = AMMU.Large_512M;
AMMU.largePages[1].L1_cacheable = AMMU.CachePolicy_NON_CACHEABLE;
AMMU.largePages[1].L1_posted = AMMU.PostedPolicy_POSTED;

/* Private, Shared and IPC Data regions: Large page (512M); cacheable */
/* config large page[2] to map 512MB VA 0x80000000 to L3 0x80000000 */
AMMU.largePages[2].pageEnabled = AMMU.Enable_YES;
AMMU.largePages[2].logicalAddress = 0x80000000;
AMMU.largePages[2].translationEnabled = AMMU.Enable_NO;
AMMU.largePages[2].size = AMMU.Large_512M;
AMMU.largePages[2].L1_cacheable = AMMU.CachePolicy_CACHEABLE;
AMMU.largePages[2].L1_posted = AMMU.PostedPolicy_POSTED;


Page Cortex M4 Address Intermediate Address Size Comment
Large Page 0 0x00000000-0x1fffffff 0x00000000-0x1fffffff 512 MB Code
Large Page 1 0x60000000-0x7fffffff 0x60000000-0x7fffffff 512 MB Peripherals
Large Page 2 0x80000000-0x9fffffff 0x80000000-0x9fffffff 512 MB Data

These 3 pages are “identity” mappings, performing a passthrough of requests to the associated address ranges. These intermediate addresses get mapped to their physical addresses in the next level of translation (IOMMU).

The AMMU ranges for code and data need to be identity mappings because otherwise the remoteproc loader wouldn’t be able to match up the sections from the ELF file with the associated IOMMU mapping. These mappings should suffice for any application, i.e. no need to adjust these. The more likely area for modification is the resource table in the next section. The AMMU mappings are needed mainly to understand the full picture with respect to the Cortex M4 memory map.


IOMMU

The IOMMU sits closest to the L3 interconnect. It takes the intermediate address output from the AMMU and translates it to the physical address used by the L3 interconnect. The IOMMU is programmed by the ARM based on the associated resource table. If you’re planning any memory changes then you’ll want to make a custom resource table as described in the wiki page IPC Resource customTable.

The default resource table (which can be adapted to make a custom table) can be found at this location:

ipc/packages/ti/ipc/remoteproc/rsc_table_vayu_ipu.h

#define IPU_MEM_TEXT            0x0
#define IPU_MEM_DATA            0x80000000

#define IPU_MEM_IOBUFS          0x90000000

#define IPU_MEM_IPC_DATA        0x9F000000
#define IPU_MEM_IPC_VRING       0x60000000
#define IPU_MEM_RPMSG_VRING0    0x60000000
#define IPU_MEM_RPMSG_VRING1    0x60004000
#define IPU_MEM_VRING_BUFS0     0x60040000
#define IPU_MEM_VRING_BUFS1     0x60080000

#define IPU_MEM_IPC_VRING_SIZE  SZ_1M
#define IPU_MEM_IPC_DATA_SIZE   SZ_1M

#if defined(VAYU_IPU_1)
#define IPU_MEM_TEXT_SIZE       (SZ_1M)
#elif defined(VAYU_IPU_2)
#define IPU_MEM_TEXT_SIZE       (SZ_1M * 6)
#endif

#if defined(VAYU_IPU_1)
#define IPU_MEM_DATA_SIZE       (SZ_1M * 5)
#elif defined(VAYU_IPU_2)
#define IPU_MEM_DATA_SIZE       (SZ_1M * 48)
#endif

<snip...>

{
    TYPE_CARVEOUT,
    IPU_MEM_TEXT, 0,
    IPU_MEM_TEXT_SIZE, 0, 0, "IPU_MEM_TEXT",
},

{
    TYPE_CARVEOUT,
    IPU_MEM_DATA, 0,
    IPU_MEM_DATA_SIZE, 0, 0, "IPU_MEM_DATA",
},

{
    TYPE_CARVEOUT,
    IPU_MEM_IPC_DATA, 0,
    IPU_MEM_IPC_DATA_SIZE, 0, 0, "IPU_MEM_IPC_DATA",
},

The 3 entries above from the resource table all come from the associated IPU CMA pool (i.e. as dictated by the TYPE_CARVEOUT). The second parameter represents the virtual address (i.e. input address to the IOMMU). These addresses must be consistent with both the AMMU mapping as well as the linker command file. The ex02_messageq example from ipc defines these memory sections in the file examples/DRA7XX_linux_elf/ex02_messageq/shared/config.bld.

You can dump the IPU IOMMU page tables with the following commands:

IPU Command
IPU1 cat /sys/kernel/debug/omap_iommu/58882000.mmu/pagetable
IPU2 cat /sys/kernel/debug/omap_iommu/55082000.mmu/pagetable

Please see the corresponding DSP documentation for more details on interpreting the output.


Cortex M4 IPU Access to Peripherals

The default resource table creates the following mappings:

Virtual Address used by Cortex M4 Address at output of Unicache MMU Address at output of IOMMU Size Comment
0x6A000000 0x6A000000 0x4A000000 16 MB L4CFG + L4WKUP
0x68000000 0x68000000 0x48000000 2 MB L4PER1
0x68400000 0x68400000 0x48400000 4 MB L4PER2
0x68800000 0x68800000 0x48800000 8 MB L4PER3
0x74000000 0x74000000 0x54000000 16 MB L3_INSTR + CT_TBR

Example: Accessing UART5 from IPU

  1. For this example, it’s assumed the pin-muxing was already setup in the bootloader. If that’s not the case, you would need to do that here.
  2. The UART5 module needs to be enabled via the CM_L4PER_UART5_CLKCTRL register. This is located at physical address 0x4A009870. So from the M4 we would program this register at virtual address 0x6A009870. Writing a value of 2 to this register will enable the peripheral.
  3. After completing the previous step, the UART5 registers will become accessible. Normally UART5 is accessible at physical base address 0x48066000. This would correspondingly be accessed from the IPU at 0x68066000.

10.2.5.1.4. Power Management

The IPUs and DSPs auto-idle by default. This can prevent you from being able to connect to the device using JTAG or from accessing local memory via devmem2. There are some options sprinkled throughout sysfs that are needed in order to force these subsystems on, as is sometimes needed for development and debug purposes.

There are some hard-coded device names that originate in the device tree (dra7.dtsi) that are needed for these operations:

Remote Core Definition in dra7.dtsi System FS Name
IPU1 ipu@58820000 58820000.ipu
IPU2 ipu@55020000 55020000.ipu
DSP1 dsp@40800000 40800000.dsp
DSP2 dsp@41000000 41000000.dsp
ICSS1-PRU0 pru@4b234000 4b234000.pru0
ICSS1-PRU1 pru@4b238000 4b238000.pru1
ICSS2-PRU0 pru@4b2b4000 4b2b4000.pru0
ICSS2-PRU1 pru@4b2b8000 4b2b8000.pru1

To map these System FS names to the associated remoteproc entry, you can run the following commands:

root@am57xx-evm:~# ls -l /sys/kernel/debug/remoteproc/
root@am57xx-evm:~# cat /sys/kernel/debug/remoteproc/remoteproc*/name

The results of the commands will be a one-to-one mapping. For example, 58820000.ipu corresponds with remoteproc0.

Similarly, to see the power state of each of the cores:

root@am57xx-evm:~# cat /sys/class/remoteproc/remoteproc*/state

The state can be suspended, running, offline, etc. You can only attach JTAG if the state is “running”. If it shows as “suspended” then you must force it to run. For example, let’s say DSP0 is “suspended”. You can run the following command to force it on:

root@am57xx-evm:~# echo on > /sys/bus/platform/devices/40800000.dsp/power/control

The same is true for any of the cores, but replace 40800000.dsp with the associated System FS name from the chart above.

10.2.5.1.5. Adding IPC to an Existing TI-RTOS Application on slave cores

Adding IPC to an existing TI RTOS application on the DSP


A common thing people want to do is take an existing DSP application and add IPC to it. This is common when migrating from a DSP only solution to a heterogeneous SoC with an Arm plus a DSP. This is the focus of this section.


In order to describe this process, we need an example test case to work with. For this purpose, we’ll be using the GPIO_LedBlink_evmAM572x_c66xExampleProject example that’s part of the PDK (installed as part of the Processor SDK RTOS). You can find it at c:/ti/pdk_am57xx_1_0_4/packages/MyExampleProjects/GPIO_LedBlink_evmAM572x_c66xExampleProject. This example uses SYS/BIOS and blinks the USER0 LED on the AM572x GP EVM, it’s labeled D4 on the EVM silkscreen just to the right of the blue reset button.


There were several steps taken to make this whole process work, each of which will be described in following sections

  1. Build and run the out-of-box LED blink example on the EVM using Code Composer Studio (CCS)
  2. Take the ex02_message example from the IPC software bundle and turn it into a CCS project. Build it and modify the Linux startup code to use this new image. This is just a sanity check step to make sure we can build the IPC examples in CCS and have them run at boot up on the EVM.
  3. In CCS, make a clone of the out-of-box LED example and rename it to denote it’s the IPC version of the example. Then using the ex02_messageq example as a reference, add in the IPC pieces to the LED example. Build from CCS then add it to the Linux firmware folder.

TODO - Fill this section in with instructions on how to run the LED blink example using JTAG and CCS after the board has booted Linux.

Note

Some edits were made to the LED blink example to allow it to run

in a Linux environment, specifically, removed the GPIO interrupts and then added a Clock object to call the LED GPIO toggle function on a periodic bases.

Make CCS project out of ex02_messageq IPC example

TODO - fill this section in with instructions on how to make a CCS project out of the IPC example source files.


The first step is to clone our out-of-box LED blink CCS project and rename it to denote it’s using IPC. The easiest way to do this is using CCS. Here are the steps...

  • In the Edit perspective, go into your Project Explorer window and right click on your GPIO_LedBlink_evmAM572x+c66xExampleProject project and select copy from the pop-up menu. Maske sure the project is not is a closed state.
  • Rick click in and empty area of the project explorer window and select past.
  • A dialog box pops up, modify the name to denote it’s using IPC. A good name is GPIO_LedBlink_evmAM572x+c66xExampleProjec_with_ipc.

This is the project we’ll be working with from here on. The next thing we want to do is select the proper RTSC platform and other components. To do this, follow these steps.

  • Right click on the GPIO_LedBlink_evmAM572x+c66xExampleProjec_with_ipc project and select Properties
  • In the left hand pane, click on CCS General.
  • On the right hand side, click on the RTSC tab
  • For XDCtools version: select 3.32.0.06_core
  • In the list of Products and Repositories, check the following...
    • IPC 3.43.2.04
    • SYS/BIOS 6.45.1.29
    • am57xx PDK 1.0.4
  • For Target, select ti.targets.elf.C66
  • For Platform, select ti.platforms.evmDRA7XX
  • Once the platform is selected, edit its name buy hand and append :dsp1 to the end. After this it should be ti.platforms.evmDRA7XX:dsp1
  • Go ahead and leave the Build-profile set to debug.
  • Hit the OK button.

Now we want to copy configuration and source files from the ex02_messageq IPC example into our project. The IPC example is located at C:/ti/ipc_3_43_02_04/examples/DRA7XX_linux_elf/ex02_messageq. To copy files into your CCS project, you can simply select the files you want in Windows explorer then drag and drop them into your project in CCS.

Copy these files into your CCS project...

  • C:/ti/ipc_3_43_02_04/examples/DRA7XX_linux_elf/ex02_messageq/shared/AppCommon.h
  • C:/ti/ipc_3_43_02_04/examples/DRA7XX_linux_elf/ex02_messageq/shared/config.bld
  • C:/ti/ipc_3_43_02_04/examples/DRA7XX_linux_elf/ex02_messageq/shared/ipc.cfg.xs

Now copy these files into your CCS project...

  • C:/ti/ipc_3_43_02_04/examples/DRA7XX_linux_elf/ex02_messageq/dsp1/Dsp1.cfg
  • C:/ti/ipc_3_43_02_04/examples/DRA7XX_linux_elf/ex02_messageq/dsp1/MainDsp1.c
  • C:/ti/ipc_3_43_02_04/examples/DRA7XX_linux_elf/ex02_messageq/dsp1/Server.c
  • C:/ti/ipc_3_43_02_04/examples/DRA7XX_linux_elf/ex02_messageq/dsp1/Server.h

Note

When you copy Dsp1.cfg into your CCS project, it should show up greyed out. This is because the LED blink example already has a cfg file (gpio_test_evmAM572x.cfg). The Dsp1.cfg will be used for copying and pasting. When it’s all done, you can delete it from your project.

Finally, you will likely want to use a custom resource table so copy these files into your CCS project...

  • C:/ti/ipc_3_43_02_04/packages/ti/ipc/remoteproc/rsc_table_vayu_dsp.h
  • C:/ti/ipc_3_43_02_04/packages/ti/ipc/remoteproc/rsc_types.h

The rsc_table_vayu_dsp.h file defines an initialized structure so let’s make a .c source file.

  • In your CCS project, rename rsc_table_vayu_dsp.h to rsc_table_vayu_dsp.c

Now we want to merge the IPC example configuration file with the LED blink example configuration file. Follow these steps...
  • Open up Dsp1.cfg using a text editor (don’t open it using the GUI). Right click on it and select Open With -> XDCscript Editor
  • We want to copy the entire contents into the clipboard. Select all and copy.
  • Now just like above, open the gpio_test_evmAM572x.cfg config file in the text editor. Go to the very bottom and paste in the contents from the Dsp1.cfg file. Basically we’ve appended the contents of Dsp1.cfg into gpio_test_evmAM572x.cfg.

We’ve now added in all the necessary configuration and source files into our project. Don’t expect it to build at this point, we have to make edits first. These edits are listed below.

Note

You can download the full CCS project with source files to use as a reference. See link towards the end of this section.

  • Edit gpio_test_evmAM572x.cfg

Add the following to the beginning of your configuration file

var Program = xdc.useModule('xdc.cfg.Program');

Comment out the Memory sections configuration as shown below

/* ================ Memory sections configuration ================ */
//Program.sectMap[".text"] = "EXT_RAM";
//Program.sectMap[".const"] = "EXT_RAM";
//Program.sectMap[".plt"] = "EXT_RAM";
/* Program.sectMap["BOARD_IO_DELAY_DATA"] = "OCMC_RAM1"; */
/* Program.sectMap["BOARD_IO_DELAY_CODE"] = "OCMC_RAM1"; */

Since we are no longer using a shared folder, make the following change

//var ipc_cfg = xdc.loadCapsule("../shared/ipc.cfg.xs");
var ipc_cfg = xdc.loadCapsule("../ipc.cfg.xs");

Comment out the following. We’ll be calling this function directly from main.

//BIOS.addUserStartupFunction('&IpcMgr_ipcStartup');

Increase the system stack size

//Program.stack = 0x1000;
Program.stack = 0x8000;

Comment out the entire TICK section

/* --------------------------- TICK --------------------------------------*/
// var Clock = xdc.useModule('ti.sysbios.knl.Clock');
// Clock.tickSource = Clock.TickSource_NULL;
// //Clock.tickSource = Clock.TickSource_USER;
// /* Configure BIOS clock source as GPTimer5 */
// //Clock.timerId = 0;
//
// var Timer = xdc.useModule('ti.sysbios.timers.dmtimer.Timer');
//
// /* Skip the Timer frequency verification check. Need to remove this later */
// Timer.checkFrequency = false;
//
// /* Match this to the SYS_CLK frequency sourcing the dmTimers.
//  * Not needed once the SYS/BIOS family settings is updated. */
// Timer.intFreq.hi = 0;
// Timer.intFreq.lo = 19200000;
//
// //var timerParams = new Timer.Params();
// //timerParams.period = Clock.tickPeriod;
// //timerParams.periodType = Timer.PeriodType_MICROSECS;
// /* Switch off Software Reset to make the below settings effective */
// //timerParams.tiocpCfg.softreset = 0x0;
// /* Smart-idle wake-up-capable mode */
// //timerParams.tiocpCfg.idlemode = 0x3;
// /* Wake-up generation for Overflow */
// //timerParams.twer.ovf_wup_ena = 0x1;
// //Timer.create(Clock.timerId, Clock.doTick, timerParams);
//
// var Idle = xdc.useModule('ti.sysbios.knl.Idle');
// var Deh = xdc.useModule('ti.deh.Deh');
//
// /* Must be placed before pwr mgmt */
// Idle.addFunc('&ti_deh_Deh_idleBegin');

Make configuration change to use custom resource table. Add to the end of the file.

/* Override the default resource table with my own */
var Resource = xdc.useModule('ti.ipc.remoteproc.Resource');
Resource.customTable = true;


  • Edit main_led_blink.c

Add the following external declarations

extern Int ipc_main();
extern Void IpcMgr_ipcStartup(Void);

In main(), add a call to ipc_main() and IpcMgr_ipcStartup() just before BIOS_start()

ipc_main();

if (callIpcStartup) {
    IpcMgr_ipcStartup();
}

/* Start BIOS */
BIOS_start();
return (0);

Comment out the line that calls Board_init(boardCfg). This call is in the original example because it assumes TI-RTOS is running on the Arm but in our case here, we are running Linux and this call is destructive so we comment it out.

#if defined(EVM_K2E) || defined(EVM_C6678)
    boardCfg = BOARD_INIT_MODULE_CLOCK |
    BOARD_INIT_UART_STDIO;
#else
    boardCfg = BOARD_INIT_PINMUX_CONFIG |
    BOARD_INIT_MODULE_CLOCK |
    BOARD_INIT_UART_STDIO;
#endif
    //Board_init(boardCfg);


  • Edit MainDsp1.c

The app now has it’s own main(), so rename this one and get rid of args

//Int main(Int argc, Char* argv[])
Int ipc_main()
{

No longer using args so comment these lines

//taskParams.arg0 = (UArg)argc;
//taskParams.arg1 = (UArg)argv;

BIOS_start() is done in the app main() so comment it out here

/* start scheduler, this never returns */
//BIOS_start();

Comment this out

//Log_print0(Diags_EXIT, "<-- main:");

  • Edit rsc_table_vayu_dsp.c

Set this #define before it’s used to select PHYS_MEM_IPC_VRING value

#define VAYU_DSP_1

Add this extern declaration prior to the symbol being used

extern char ti_trace_SysMin_Module_State_0_outbuf__A;

  • Edit Server.c


No longer have shared folder so change include path

/* local header files */
//#include "../shared/AppCommon.h"
#include "../AppCommon.h"

Download the Full CCS Project


GPIO_LedBlink_evmAM572x_c66xExampleProject_with_ipc.zip

Adding IPC to an existing TI RTOS application on the IPU


A common thing people want to do is take an existing IPU application that may be controlling serial or control interfaces and add IPC to it so that the firmware can be loaded from the ARM. This is common when migrating from a IPU only solution to a heterogeneous SoC with an MPUSS (ARM) and IPUSS. This is the focus of this section.


In order to describe this process, we need an example TI RTOS test case to work with. For this purpose, we’ll be using the UART_BasicExample_evmAM572x_m4ExampleProject example that’s part of the PDK (installed as part of the Processor SDK RTOS). This example uses TI RTOS and does serial IO using UART3 port on the AM572x GP EVM, it’s labeled Serial Debug on the EVM silkscreen.


There were several steps taken to make this whole process work, each of which will be described in following sections

  1. Build and run the out-of-box UART M4 example on the EVM using Code Composer Studio (CCS)
  2. Build and run the ex02_messageQ example from the IPC software bundle and turn it into a CCS project. Build it and modify the Linux startup code to use this new image. This is just a sanity check step to make sure we can build the IPC examples in CCS and have them run at boot up on the EVM.
  3. In CCS, make a clone of the out-of-box UART M4 example and rename it to denote it’s the IPC version of the example. Then using the ex02_messageq example as a reference, add in the IPC pieces to the UART example code. Build from CCS then add it to the Linux firmware folder.

Running UART Read/Write PDK Example from CCS

Developers are required to run pdkProjectCreate script to generate this example as described in the Processor SDK RTOS wiki article.

For the UART M4 example run the script with the following arguments:

pdkProjectCreate.bat AM572x evmAM572x little uart m4


After you run the script, you can find the UART M4 example project at <SDK_INSTALL_PATH>/pdk_am57xx_1_0_4/packages/MyExampleProjects/UART_BasicExample_evmAM572x_m4ExampleProject.

Import the project in CCS and build the example. You can now connect to the EVM using an emulator and CCS using the instructions provided here: http://processors.wiki.ti.com/index.php/AM572x_GP_EVM_Hardware_Setup

Connect to the ARM core and make sure GEL runs multicore initialization and brings the IPUSS out of reset. Connect to IPU2 core0 and load and run the M4 UART example. When you run the code you should see the following log on the serial IO console:

uart driver and utils example test cases :
Enter 16 characters or press Esc
1234567890123456  <- user input
Data received is
1234567890123456  <- loopback from user input
uart driver and utils example test cases :
Enter 16 characters or press Esc


Build and Run ex02_messageq IPC example

Follow instructions described in Article Run IPC Linux Examples

Update Linux Kernel device tree to remove UART that will be controlled by M4

Linux kernel enables all SOC HW modules which are required for its configuration. Appropriate drivers configure required clocks and initialize HW registers. For all unused IPs clocks are not configured.

The uart3 node is disabled in kernel using device tree. Also this restricts kernel to put those IPs to sleep mode.

&uart3 {
    status = "disabled";
    ti,no-idle;
};

Add IPC to the UART Example

The first step is to clone our out-of-box UART example CCS project and rename it to denote it’s using IPC. The easiest way to do this is using CCS. Here are the steps...

  • In the Edit perspective, go into your Project Explorer window and right click on your UART_BasicExample_evmAM572x_m4ExampleProject project and select copy from the pop-up menu. Maske sure the project is not is a closed state.
  • Rick click in and empty area of the project explorer window and select past.
  • A dialog box pops up, modify the name to denote it’s using IPC. A good name is UART_BasicExample_evmAM572x_m4ExampleProject_with_ipc.

This is the project we’ll be working with from here on. The next thing we want to do is select the proper RTSC platform and other components. To do this, follow these steps.

  • Right click on the UART_BasicExample_evmAM572x_m4ExampleProject_with_ipc project and select Properties
  • In the left hand pane, click on CCS General.
  • On the right hand side, click on the RTSC tab
  • For XDCtools version: select 3.xx.x.xx_core
  • In the list of Products and Repositories, check the following...
    • IPC 3.xx.x.xx
    • SYS/BIOS 6.4x.x.xx
    • am57xx PDK x.x.x
  • For Target, select ti.targets.arm.elf.M4
  • For Platform, select ti.platforms.evmDRA7XX
  • Once the platform is selected, edit its name buy hand and append :ipu2 to the end. After this it should be ti.platforms.evmDRA7XX:ipu2
  • Go ahead and leave the Build-profile set to debug.
  • Hit the OK button.

Now we want to copy configuration and source files from the ex02_messageq IPC example into our project. The IPC example is located at C:/ti/ipc_3_xx_xx_xx/examples/DRA7XX_linux_elf/ex02_messageq. To copy files into your CCS project, you can simply select the files you want in Windows explorer then drag and drop them into your project in CCS.

Copy these files into your CCS project...

  • C:/ti/ipc_3_xx_xx_xx/examples/DRA7XX_linux_elf/ex02_messageq/shared/AppCommon.h
  • C:/ti/ipc_3_xx_xx_xx/examples/DRA7XX_linux_elf/ex02_messageq/shared/config.bld
  • C:/ti/ipc_3_xx_xx_xx/examples/DRA7XX_linux_elf/ex02_messageq/shared/ipc.cfg.xs

Now copy these files into your CCS project...

  • C:/ti/ipc_3_xx_xx_xx/examples/DRA7XX_linux_elf/ex02_messageq/ipu2/Ipu2.cfg
  • C:/ti/ipc_3_xx_xx_xx/examples/DRA7XX_linux_elf/ex02_messageq/ipu2/MainIpu2.c
  • C:/ti/ipc_3_xx_xx_xx/examples/DRA7XX_linux_elf/ex02_messageq/ipu2/Server.c
  • C:/ti/ipc_3_xx_xx_xx/examples/DRA7XX_linux_elf/ex02_messageq/ipu2/Server.h

Note

When you copy Ipu2.cfg into your CCS project, it should show up greyed out. If not, right click and exclude it from build. This is because the UART example already has a cfg file (uart_m4_evmAM572x.cfg). The Ipu2.cfg will be used for copying and pasting. When it’s all done, you can delete it from your project.

Finally, you will likely want to use a custom resource table so copy these files into your CCS project...

  • C:/ti/ipc_3_xx_xx_xx/packages/ti/ipc/remoteproc/rsc_table_vayu_ipu.h
  • C:/ti/ipc_3_xx_xx_xx/packages/ti/ipc/remoteproc/rsc_types.h

The rsc_table_vayu_dsp.h file defines an initialized structure so let’s make a .c source file.

  • In your CCS project, rename rsc_table_vayu_ipu.h to rsc_table_vayu_ipu.c

Now we want to merge the IPC example configuration file with the LED blink example configuration file. Follow these steps...

  • Open up Ipu2.cfg using a text editor (don’t open it using the GUI). Right click on it and select Open With -> XDCscript Editor
  • We want to copy the entire contents into the clipboard. Select all and copy.
  • Now just like above, open the uart_m4_evmAM572x.cfg config file in the text editor. Go to the very bottom and paste in the contents from the Ipu2.cfg file. Basically we’ve appended the contents of Ipu2.cfg into uart_m4_evmAM572x.cfg.

We’ve now added in all the necessary configuration and source files into our project. Don’t expect it to build at this point, we have to make edits first. These edits are listed below.

Note

You can download the full CCS project with source files to use as a reference. See link towards the end of this section.

  • Edit uart_m4_evmAM572x.cfg

Add the following to the beginning(at the top) of your configuration file

var Program = xdc.useModule('xdc.cfg.Program');


Since we are no longer using a shared folder, make the following change

//var ipc_cfg = xdc.loadCapsule("../shared/ipc.cfg.xs");
var ipc_cfg = xdc.loadCapsule("../ipc.cfg.xs");

Comment out the following. We’ll be calling this function directly from main.

//BIOS.addUserStartupFunction('&IpcMgr_ipcStartup');

Increase the system stack size

//Program.stack = 0x1000;
Program.stack = 0x8000;

Comment out the entire TICK section

/* --------------------------- TICK --------------------------------------*/
// var Clock = xdc.useModule('ti.sysbios.knl.Clock');
// Clock.tickSource = Clock.TickSource_NULL;
// //Clock.tickSource = Clock.TickSource_USER;
// /* Configure BIOS clock source as GPTimer5 */
// //Clock.timerId = 0;
//
// var Timer = xdc.useModule('ti.sysbios.timers.dmtimer.Timer');
//
// /* Skip the Timer frequency verification check. Need to remove this later */
// Timer.checkFrequency = false;
//
// /* Match this to the SYS_CLK frequency sourcing the dmTimers.
//  * Not needed once the SYS/BIOS family settings is updated. */
// Timer.intFreq.hi = 0;
// Timer.intFreq.lo = 19200000;
//
// //var timerParams = new Timer.Params();
// //timerParams.period = Clock.tickPeriod;
// //timerParams.periodType = Timer.PeriodType_MICROSECS;
// /* Switch off Software Reset to make the below settings effective */
// //timerParams.tiocpCfg.softreset = 0x0;
// /* Smart-idle wake-up-capable mode */
// //timerParams.tiocpCfg.idlemode = 0x3;
// /* Wake-up generation for Overflow */
// //timerParams.twer.ovf_wup_ena = 0x1;
// //Timer.create(Clock.timerId, Clock.doTick, timerParams);
//
// var Idle = xdc.useModule('ti.sysbios.knl.Idle');
// var Deh = xdc.useModule('ti.deh.Deh');
//
// /* Must be placed before pwr mgmt */
// Idle.addFunc('&ti_deh_Deh_idleBegin');

Make configuration change to use custom resource table. Add to the end of the file.

/* Override the default resource table with my own */
var Resource = xdc.useModule('ti.ipc.remoteproc.Resource');
Resource.customTable = true;


  • Edit main_uart_example.c

Add the following external declarations

extern Int ipc_main();
extern Void IpcMgr_ipcStartup(Void);

In main(), add a call to ipc_main() and IpcMgr_ipcStartup() just before BIOS_start()

ipc_main();
if (callIpcStartup) {
   IpcMgr_ipcStartup();
 }
 /* Start BIOS */
 BIOS_start();
 return (0);

Comment out the line that calls Board_init(boardCfg). This call is in the original example because it assumes TI-RTOS is running on the Arm but in our case here, we are running Linux and this call is destructive so we comment it out. The board init call does all pinmux configuration, module clock and UART peripheral initialization.

In order to run the UART Example on M4, you need to disable the UART in the Linux DTB file and interact with the Linux kernel using Telnet (This will be described later in the article). Since Linux will be running uboot performs the pinmux configuration but clock and UART Stdio setup needs to be performed by the M4.


Original code

#if defined(EVM_K2E) || defined(EVM_C6678)
    boardCfg = BOARD_INIT_MODULE_CLOCK | BOARD_INIT_UART_STDIO;
#else
    boardCfg = BOARD_INIT_PINMUX_CONFIG | BOARD_INIT_MODULE_CLOCK | BOARD_INIT_UART_STDIO;
#endif
    Board_init(boardCfg);


Modified Code :

boardCfg = BOARD_INIT_UART_STDIO;
Board_init(boardCfg);

We are not done yet as we still need to configure turn the clock control on for the UART without impacting the other clocks. We can do that by adding the following code before Board_init API call:

CSL_l4per_cm_core_componentRegs *l4PerCmReg =
    (CSL_l4per_cm_core_componentRegs *)CSL_MPU_L4PER_CM_CORE_REGS;
CSL_FINST(l4PerCmReg->CM_L4PER_UART3_CLKCTRL_REG,
    L4PER_CM_CORE_COMPONENT_CM_L4PER_UART3_CLKCTRL_REG_MODULEMODE, ENABLE);
while(CSL_L4PER_CM_CORE_COMPONENT_CM_L4PER_UART3_CLKCTRL_REG_IDLEST_FUNC !=
   CSL_FEXT(l4PerCmReg->CM_L4PER_UART3_CLKCTRL_REG,
    L4PER_CM_CORE_COMPONENT_CM_L4PER_UART3_CLKCTRL_REG_IDLEST));
  • Edit MainIpu2.c

The app now has it’s own main(), so rename this one and get rid of args

//Int main(Int argc, Char* argv[])
Int ipc_main()
{

No longer using args so comment these lines

//taskParams.arg0 = (UArg)argc;
//taskParams.arg1 = (UArg)argv;

BIOS_start() is done in the app main() so comment it out here

/* start scheduler, this never returns */
//BIOS_start();

Comment this out

//Log_print0(Diags_EXIT, "<-- main:");

  • Edit rsc_table_vayu_ipu.c

Set this #define before it’s used to select PHYS_MEM_IPC_VRING value

#define VAYU_IPU_2

Add this extern declaration prior to the symbol being used

extern char ti_trace_SysMin_Module_State_0_outbuf__A;


  • Edit Server.c

No longer have shared folder so change include path

/* local header files */
//#include "../shared/AppCommon.h"
#include "../AppCommon.h"

Handling AMMU (L1 Unicache MMU) and L2 MMU

There are two MMUs inside each of the IPU1, and IPU2 subsystems. The L1 MMU is referred to as IPU_UNICACHE_MMU or AMMU and L2 MMU. The description of how this is configured in IPC-remoteproc has been described in section Changing_Cortex_M4_IPU_Memory_Map. IPC handling of L1 and L2 MMU is different from how the PDK driver examples setup the memory access using these MMUs which the users need to manage when integrating the components. This difference is highlighted below:

../_images/IPU_MMU_Peripheral_access.png
  • PDK examples use addresses (0x4X000000) to peripheral registers and use following MMU setting
    • L2 MMU uses default 1:1 Mapping
    • AMMU configuration translates physical 0x4X000000 access to logical 0x4X000000
  • IPC+ Remote Proc ARM+M4 requires IPU to use logical address (0x6X000000) and uses following MMU setting
    • L2 MMU is configured such that MMU translates 0x6X000000 access to addresss 0x4X000000
    • AMMU is configured for 1:1 mapping 0x6X000000 and 0x6X000000

Therefore after integrating IPC with PDK drivers, it is recommended that the alias addresses are used to access peripherals and PRCM registers. This requires changes to the addresses used by PDK drivers and in application code.

The following changes were then made to the IPU application source code:

Add UART_soc.c file to the project and modify the base addresses for all IPU UART register instance in the UART_HwAttrs to use alias addresses:

#ifdef _TMS320C6X
    CSL_DSP_UART3_REGS,
    OSAL_REGINT_INTVEC_EVENT_COMBINER,
#elif defined(__ARM_ARCH_7A__)
    CSL_MPU_UART3_REGS,
    106,
#else
    (CSL_IPU_UART3_REGS + 0x20000000),    //Base Addr = 0x48000000 + 0x20000000 = 0x68000000
    45,
#endif

Adding custom SOC configuration also means that you should use the generic UART driver instead of driver with built in SOC setup. To do this comment the following line in .cfg:

var Uart              = xdc.loadPackage('ti.drv.uart');
//Uart.Settings.socType = socType;

There is also an instance in the application code where we added pointer to PRCM registers that need to be changed as follows.

 CSL_l4per_cm_core_componentRegs *l4PerCmReg =
(CSL_l4per_cm_core_componentRegs *) 0x6a009700; //CSL_MPU_L4PER_CM_CORE_REGS;

Now, you are ready to build the firmware. After the .out is built, change the extension to .xem4 and copy it over to the location in the filesystem that is used to load M4 firmware.

10.2.5.2. Customizing Memory map for creating Multicore Applications on AM57xx using IPC

http://www.ti.com/lit/an/sprac60/sprac60.pdf

10.2.5.3. IPC Debugging Tools and Techniques on AM57xx

The sections relevant to AM57xx have been pulled from the Debugging Tools and Techniques With IPC3.x Application Note and placed here.

10.2.5.3.1. Introduction

During development of software, it is common to encounter issues that must be debugged to provide a robust software offering. When developing software that uses the IPC3.x product for inter-processor communication, there are tools and techniques available to aid in the debugging process. These tools and techniques help to more quickly understand and debug the issue. This document addresses all three HLOS’s supported by IPC3.x: Android™ platform, Linux®, and QNX®. Where applicable, differences between the OS’s are noted. This document aims to provide tools, techniques, and resources for debugging issues encountered when using the IPC3.x to communicate with remote core software.

10.2.5.3.2. Debug Tools

There are several tools that can be leveraged for debugging the IPC, from simple tracing to using Code Composer Studio™ (CCS) to attach to the remote cores. Each provides different advantages in the debugging process.

10.2.5.3.2.1. Tracing

When an issue occurs, checking the traces is often the first thing done. The traces can give quick insight into what may be happening. In normal, non-error cases, you might see little to no traces from the IPC. But when there is an error, there often is an error trace that can be used to shed light on the issue. An error trace often gives an error code and a module or function name that can be used to identify where the error was thrown.

10.2.5.3.2.2. Linux and Android - Debugfs

Another useful place to look for debug info is in the debugfs. Information for each remote processor can be found there, as well as remote core traces, state information, and more.

10.2.5.3.2.3. Code Composer Studio

Connecting over JTAG using Code Composer Studio provides the ability to see exactly what is happening on the remote core, providing access to a wealth of information including viewing memory, registers, and stepping through the code.

10.2.5.3.3. Traces

The first place to check when an issue occurs is the traces. Often an error code or a trace regarding an error gives some clue. Both the remote core traces and the HLOS-side traces can be checked.

10.2.5.3.3.1. Linux and Android - Enabling IPC Traces

By default, the IPC only prints error traces. To enable additional tracing, use the IPC_DEBUG environment variable at runtime. This feature is only supported on Linux and is available starting in IPC 3.22.00.05. Table 1 lists the two levels of tracing supported.

Table 1. IPC_DEBUG Trace Levels

Trace Level Description
1 Enables all warnings and errors to be printed
2 Turns on all tracing (including socket and LAD client tracing).
10.2.5.3.3.2. QNX – Enabling IPC Traces

When using QNX, additional traces are enabled by setting environment variables. There are separate environment variables for enabling traces in the resource manager and the user libraries.

Resource Manager Traces

Enable additional traces in the slog by setting the environment variable IPC_DEBUG_SLOG_LEVEL at runtime. By default, only errors and warnings are printed. The IPC_DEBUG_SLOG_LEVEL can be set before launching IPC to enable more traces. Setting the level to 7 enables all IPC traces. The default level is 2.

export IPC_DEBUG_SLOG_LEVEL=7

These traces are printed to the slog, and can be viewed by using the sloginfo command. All IPC traces use 42 as identification in the slog, and you can filter the slog to view only these traces:

sloginfo –m42

User Library Traces

User library traces can be enabled by using the variable IPC_DEBUG when launching the application. Valid levels are 1 to 3, with 3 being the most verbose. For example:

IPC_DEBUG=<level> app_host
10.2.5.3.3.3. Linux and Android - Remote Core Traces

The remote core traces can be checked by using debugfs. Run the following command, replacing the “X” with the core-id for the remote core to be checked.

cat /sys/kernel/debug/remoteproc/remoteprocX/trace0

Check the following when checking the traces after an error recovery has occurred:

cat /sys/kernel/debug/remoteproc/remoteprocX/trace0_last

This provides the last traces that happened before error recovery was triggered. For more information about debugging remote core faults and exceptions, see Debugging MMU Faults and Exceptions.

The core-id, “X”, starts at 0 and increments to include all of the remote cores supported by the remoteproc module in the dts file. Because the number of remoteprocs supported can vary depending on the dts configuration, it is not ensured that a certain remote core will always have a certain core-id if the remoteprocs supported in the dts file changes.

The core associated with a particular core-id can be found by checking the name of the remoteproc (see Linux and Android - Remoteproc). Table 2 associates the remoteproc name with the common name of the remote processor.

cat /sys/kernel/debug/remoteproc/remoteprocX/name

Table 2. Remoteproc Names for AM57xx

Debugfs Name Remote Core Name
58820000.ipu IPU1
55020000.ipu IPU2
40800000.dsp DSP1
41000000.dsp DSP2
10.2.5.3.3.4. QNX - Remote Core Traces

The remote core traces can be checked by using sysfs. Run the following command, replacing <core name> with the core name for the remote core to check. Valid core names for AM57xx are IPU1, IPU2, DSP1, and DSP2.

cat /dev/ipc-trace/<core name>

When checking the traces after error recovery has happened, check the logfile specified at IPC startup, if one was specified. When starting IPC, specify a logfile using the “-c” option. When an error recovery happens, the last traces are dumped to this log file. For more information about debugging remote core faults and exceptions, see Debugging MMU Faults and Exceptions.

10.2.5.3.3.5. QNX - Adding Traces

In some cases, you may want to add traces to get more information about the issue. If the issue is reliably reproducible, one technique is to add additional traces to get more information. If the issue is timing-related, this technique may not be helpful, as it may mask the issue

SYS-BIOS

You can add traces in the SYS-BIOS IPC code that come to the trace buffer by using the System_printf() API. After adding traces to the SYS-BIOS IPC and rebuilding the IPC, you must rebuild the remote core image. The traces come to the remote core trace buffer and can be viewed by following the instructions in Linux and Android - Remote Core Traces.

Linux

Additionally, traces can be added in the Linux code. The modules of interest when adding traces are the remoteproc, iommu, and rpmsg modules in the kernel, and the MessageQ, MMRPC, and LAD modules in the user space.

In the kernel are these modules in the following paths:

  • drivers/remoteproc/
  • drivers/iommu/
  • drivers/rpmsg/

Most of the user space code can be found in the IPC package, in the linux folder. The MMRPC code is found in the packages/ti/ipc/mm/ folder.

10.2.5.3.4. Remote Core Status Information

Useful information about the status of the remote cores can be found in debugfs.

10.2.5.3.4.1. Linux and Android - Remoteproc

Information about each remote core can be found in the following, where the “X” can be replaced with the remote core id.

cat /sys/kernel/debug/remoteproc/remoteprocX/<entry>

Table 3 lists what can be found for each core.

Table 3. Remoteproc Debugfs Entries

Entry Description
name Processor name, comprised of the RAM address and the processor type, (for example, 58820000.ipu for IPU1). For a complete list of names, see Table 2.
recovery Returns either “enabled” or “disabled”, indicating if recovery is enabled or disabled for the remote processor.
state Gives the state of the remote processor. State is one of: * offline (0) * suspended (1) * running (2) * crashed (3)
trace0 Returns the contents of the remote processor trace buffer.
trace0_last Created after recovering the remote core. Returns the contents of the remote processor trace buffer before recovery was triggered.
version Returns the version. Currently returns nothing.
10.2.5.3.4.2. Linux and Android - IOMMU Info

Information about the IOMMU can also be found in debugfs. It can be found in the following path, where “XXXXXXXX” is replaced by the register address for the remote core MMU registers.

cat /sys/kernel/debug/omap_iommu/XXXXXXXX.mmu/<entry>

Table 4 gives the corresponding core name for each MMU for AM57xx, and the register address in the TRM.

Table 4. IOMMU Entry Names

IOMMU Entry Core Name
58882000.mmu IPU1
55082000.mmu IPU2
40d01000.mmu DSP1 (MMU1)
40d02000.mmu DSP1 (MMU2)
41501000.mmu DSP2 (MMU1)
41502000.mmu DSP2 (MMU2)

Some of this information is inaccessible from a suspended state. Table 5 lists what can be found for each core.

Table 5. IOMMU Debugfs Entries

Entry Description
nr_tlb_entries Gives the number of tlb entries
pagetable Dumps the pagetable entries
regs Gives the values of the MMU registers
tlb Lists the tlb entries.
10.2.5.3.4.3. QNX – Remote Core State Information

Find out the current state of the remote core by issuing the following command:

cat /dev/ipc-state/<core_name>

The “core_name” is the name of the remote core. Valid names for AM57xx are IPU1, IPU2, DSP1, and DSP2. The current state will show as “running” or “reset”.

10.2.5.3.5. Using Code Composer Studio

A useful tool for debugging issues is Code Composer Studio. CCS allows easy connection to the remote core in order to see the state of the remote core.

10.2.5.3.5.1. Debug Symbols

The remote core image must be built with debug symbols to see information such as the call stack and variables. Once attached, load the symbols. The symbols are built into the executable itself. When loading symbols, point to the same executable that is loaded on the target (or the unstripped version locally, if it is stripped to save space when loading to the target.)

10.2.5.3.5.2. Linux and Android - Disabling Remoteproc Auto-Suspend

You may want to disable auto-suspend of the remote cores (provided that is not what is being debugged). When the core is suspended, you will not be able to connect to the remote core using CCS. Auto-suspend can be disabled by setting the power control to “on” for the remote core.

echo on > /sys/bus/platform/devices/<device>/power/control

The remote core device name for each remote core can be found in Table 2.

10.2.5.3.5.3. Linux and Android – Disabling Watchdog

You may decide to disable the watchdog timers when debugging and using CCS. Otherwise, while connected to the target, the watchdog may expire, triggering an abort sequence. Disable the watchdog timers for a remote core by removing their definitions from the dts file. For example, to disable the watchdog timers for IPU1, change the dts file as below:

&ipu1 {
    status = "okay";

    memory-region = <&ipu1_cma_pool>;

    mboxes = <&mailbox5 &mbox_ipu1_legacy>;

    timers = <&timer11>;

   - watchdog-timers = <&timer7>, <&timer8>;

   + /*watchdog-timers = <&timer7>, <&timer8>;*/
10.2.5.3.5.4. SYS/BIOS – Disabling Watchdog

When using QNX, you can disable the watchdog from within the remote core image itself. If using Linux or Android, this step is not required; simply follow the instructions in Linux and Android – Disabling Watchdog.

To disable the usage of the watchdog from the remote core without completely disabling the device exception module (DEH), comment out the calls to Watchdog_init in the SYS/BIOS IPC code. These calls can be found in packages/ti/deh/Deh.c, packages/ti/deh/DehDsp.c, and packages/ti/ipc/ipcmgr/IpcMgr.c.

packages/ti/deh/Deh.c:

/*
* ======== Deh_Module_startup ========
*/
Int Deh_Module_startup(Int phase)
{
if (AMMU_Module_startupDone() == TRUE) {
- Watchdog_init(ti_sysbios_family_arm_m3_Hwi_excHandlerAsm__I);
+ //Watchdog_init(ti_sysbios_family_arm_m3_Hwi_excHandlerAsm__I);
return Startup_DONE;
}
return Startup_NOTDONE;
}

packages/ti/deh/DehDsp.c:

Int Deh_Module_startup(Int phase)
{
#if defined(HAS_AMMU)
if (AMMU_Module_startupDone() == TRUE) {
- Watchdog_init((Void (*)(Void))ti_sysbios_family_c64p_Exception_handler);
+ //Watchdog_init((Void (*)(Void))ti_sysbios_family_c64p_Exception_handler);
return Startup_DONE;
}
return Startup_NOTDONE;
#else
- Watchdog_init((Void (*)(Void))ti_sysbios_family_c64p_Exception_handler);
+ //Watchdog_init((Void (*)(Void))ti_sysbios_family_c64p_Exception_handler);
return Startup_DONE;
#endif

packages/ti/ipc/ipcmgr/IpcMgr.c:

Void IpcMgr_rpmsgStartup(Void)
{
Assert_isTrue(MultiProc_self() != MultiProc_getId("HOST"), NULL);
RPMessage_init(MultiProc_getId("HOST"));
-#ifdef IpcMgr_USEDEH
+#if 0
/*
* When using DEH, initialize the Watchdog timers if not already done
* (i.e. late-attach)
*/
#ifdef IpcMgr_DSP
Watchdog_init((Void (*)(Void))ti_sysbios_family_c64p_Exception_handler);
#elif IpcMgr_IPU
Watchdog_init(ti_sysbios_family_arm_m3_Hwi_excHandlerAsm__I);
#endif
#endif
}
[...]
Void IpcMgr_ipcStartup(Void)
{
UInt procId = MultiProc_getId("HOST");
Int status;
/* TransportRpmsgSetup will busy wait until host kicks ready to recv: */
status = TransportRpmsgSetup_attach(procId, 0);
Assert_isTrue(status >= 0, NULL);
/* Sets up to communicate with host's NameServer: */
status = NameServerRemoteRpmsg_attach(procId, 0);
Assert_isTrue(status >= 0, NULL);
-#ifdef IpcMgr_USEDEH
+#if 0
/*
* When using DEH, initialize the Watchdog timers if not already done
* (i.e. late-attach)
*/
#ifdef IpcMgr_DSP
Watchdog_init((Void (*)(Void))ti_sysbios_family_c64p_Exception_handler);
#elif IpcMgr_IPU
Watchdog_init(ti_sysbios_family_arm_m3_Hwi_excHandlerAsm__I);
#endif
#endif
}

Following this, rebuild the IPC and the remote core image to have an image with DEH, but without watchdog enabled.

10.2.5.3.5.5. Attaching Before the Issue

In certain cases, you may want to attach to the remote core before the issue has occurred. If the issue is reliably reproducible and always occurs at the same location, then adding a breakpoint close to where the issue happens could be a good way to get a better picture of what is happening.

One instance where it may be difficult is if the issue is happening during boot-up of the remote core. In this case, it may be necessary to add a while loop in the main function, to attach before the issue occurs. Add a loop similar to this:

{
volatile int foo = 1;
while (foo);
}

Then, after attaching, load the symbols, add the breakpoints, change “foo” to 0, and continue running.

10.2.5.3.5.6. Attaching After the Issue

You can also attach to the core after the issue, load the symbols, and see the state and view memory. You can view the Exception module’s exception CallStack ROV view and the task module’s per task CallStack ROV view. For more information about the runtime object viewer (ROV) in the RTSC documentation online, see Runtime Object Viewer.

10.2.5.3.5.7. Viewing the State of the Remote Core

Once attached and with symbols loaded, the state of the processor can be inspected. You can see the program counter, memory windows, registers, call stack, and the ROV, among other things.

10.2.5.3.6. Debugging MMU Faults and Exceptions

Errors commonly manifest as MMU faults, exceptions, and watchdog errors (if using a version of IPC with watchdog available and enabled).

10.2.5.3.6.1. Linux and Android - Disabling Error Recovery

To debug an error, it may be necessary to turn of error recovery. Error recovery can be disabled by giving the following command:

echo disabled > /sys/kernel/debug/remoteproc/remoteprocX/recovery

See Linux and Android - Remoteproc for more information.

10.2.5.3.6.2. QNX – Disabling Error Recovery

To disable error recovery on QNX using IPC version 3.22 and above, give the -d option when launching the ipc binary. For example:

ipc –d IPU2 dra7x-ipu2-fw.xem4
10.2.5.3.6.3. Crash Dump

If any of these three errors are encountered, you will get a crash dump from the remote core which is visible in the remote core traces. If error recovery is disabled, the dump can be found in trace0 (when using Linux/Android) or in /dev/ipc-trace/<core_name> (when using QNX); otherwise, the trace is found in trace0_last (when using Linux/Android) and in the logfile (when using QNX).

An example of the crash dump will look like this:

[0] [ 91.045] Exception occurred at (PC) = 0000c976

[0] [ 91.045] CPU context: thread

[0] [ 91.045] BIOS Task name: {empty-instance-name} handle: 0x80060090.

[0] [ 91.045] BIOS Task stack base: 0x800600e0.

[0] [ 91.045] BIOS Task stack size: 0x800.

[0] [ 91.045] [t=0x18f6df13] ti.sysbios.family.arm.m3.Hwi: ERROR: line 1078: E_hardFault: FORCED

[0] [ 91.045] ti.sysbios.family.arm.m3.Hwi: line 1078: E_hardFault: FORCED

[0] [ 91.045] [t=0x18f9a0cb] ti.sysbios.family.arm.m3.Hwi: ERROR: line 1155: E_busFault: PRECISERR: Immediate Bus Fault, exact addr known, address: 96000000

[0] [ 91.045] ti.sysbios.family.arm.m3.Hwi: line 1155: E_busFault: PRECISERR: Immediate Bus

Fault, exact addr known, address: 96000000

[0] [ 91.045] R0 = 0x96000000 R8 = 0xffffffff

[0] [ 91.045] R1 = 0x00000000 R9 = 0xffffffff

[0] [ 91.045] R2 = 0x00000000 R10 = 0xffffffff

[0] [ 91.045] R3 = 0x80060814 R11 = 0xffffffff

[0] [ 91.045] R4 = 0x00013098 R12 = 0x8006074c

[0] [ 91.045] R5 = 0x0000000a SP(R13) = 0x80060820

[0] [ 91.045] R6 = 0xffffffff LR(R14) = 0x0000c973

[0] [ 91.045] R7 = 0xffffffff PC(R15) = 0x0000c976

[0] [ 91.045] PSR = 0x61000000

[0] [ 91.045] ICSR = 0x00438803

[0] [ 91.045] MMFSR = 0x00

[0] [ 91.045] BFSR = 0x82

[0] [ 91.045] UFSR = 0x0000

[0] [ 91.045] HFSR = 0x40000000

[0] [ 91.045] DFSR = 0x00000000

[0] [ 91.045] MMAR = 0x96000000

[0] [ 91.045] BFAR = 0x96000000

[0] [ 91.045] AFSR = 0x00000000

[0] [ 91.045] Stack trace

[0] [ 91.045] 00 [op faaaf00e] 00006abd (ret from call to 00015010)

[0] [ 91.045] 01 [op ff49f005] 00006ac3 (ret from call to 0000c954)

[0] [ 91.045] -- [op 98009000] 000154c9

[0] [ 91.045] -- [op 00000000] 000a0001

[0] [ 91.045] -- [op 80084a64] 0000fec9

[0] [ 91.045] -- [op 0001a75c] 000068b9

[0] [ 91.045] -- [op 80084a64] 0000fec9

[0] [ 91.045] -- [op bd0ef919] 00015b91

[0] [ 91.045] Stack dump base 800600e0 size 2048 sp 80060820:

[0] [ 91.045] 80060820: 00000001 00006abd 96000000 00000000 ffffffff 00006ac3 0000000a 00006bf4

[0] [ 91.045] 80060840: 00000000 00000000 80041800 80060ab0 00000080 56414c53 50495f45 be003155

[0] [ 91.045] 80060860: bebebebe bebebebe bebebebe bebebebe bebebebe bebebebe bebebebe bebebebe

[0] [ 91.045] 80060880: bebebebe bebebebe bebebebe bebebebe bebebebe 00000000 00000000 00000001

[0] [ 91.045] 800608a0: 00000001 000154c9 0001309a 0000000a 00000000 80041820 00000001 ffffffff

[0] [ 91.045] 800608c0: ffffffff 0000fec9 00000000 00000000 000068b9 0000fec9 00015b91 bebebebe

[0] [ 91.045] Terminating execution...
10.2.5.3.6.4. Exception Dump Decoding

Some useful information that can be found in the dump is the fault address, PC address, register contents, and call stack.

When an error occurs, you gets a crash dump from the remote core that looks similar to the one in Crash Dump.

The particular dump example above is from a MMU read fault. This dump provides important information in helping to understand what has happened. Some of the useful parts are broken down in the following section.

Timestamp

All traces (not just exception dumps) provide a timestamp for each trace. The time starts from the booting of the remote core.

[0] [ 91.045] Exception occurred at (PC) = 0000c976

[0] [ 91.045] CPU context: thread

[0] [ 91.045] BIOS Task name: {empty-instance-name} handle: 0x80060090.

The timestamp information can be useful even in non-crash situations, indicating the amount of time taken between two events. You can add traces at each event and then see when the events run.

For example, to check that a certain event is happening every second, put a trace at that event, then check the timestamps to see that it is happening as expected.

PC Address

The PC address where the exception occurred is also provided. This can be used, in conjunction with the map file or CCS, to identify the line of code where the exception happened.

[0] [ 91.045] Exception occurred at (PC) = 0000c976

[0] [ 91.045] CPU context: thread

[0] [ 91.045] BIOS Task name: {empty-instance-name} handle: 0x80060090.

Task Information

The information about the task that was executing when the exception occurred is also provided.

[0] [ 91.045] Exception occurred at (PC) = 0000c976

[0] [ 91.045] CPU context: thread

[0] [ 91.045] BIOS Task name: {empty-instance-name} handle: 0x80060090.

[0] [ 91.045] BIOS Task stack base: 0x800600e0.

[0] [ 91.045] BIOS Task stack size: 0x800.

Fault Information

The information about the fault is also provided. This can look different depending on the type of exception that occurred, but often provides a fault address to identify the source of the fault.

[0] [ 91.045] Exception occurred at (PC) = 0000c976

[0] [ 91.045] CPU context: thread

[0] [ 91.045] BIOS Task name: {empty-instance-name} handle: 0x80060090.

[0] [ 91.045] BIOS Task stack base: 0x800600e0.

[0] [ 91.045] BIOS Task stack size: 0x800.

[0] [ 91.045] [t=0x18f6df13] ti.sysbios.family.arm.m3.Hwi: ERROR: line 1078: E_hardFault: FORCED

[0] [ 91.045] ti.sysbios.family.arm.m3.Hwi: line 1078: E_hardFault: FORCED

[0] [ 91.045] [t=0x18f9a0cb] ti.sysbios.family.arm.m3.Hwi: ERROR: line 1155: E_busFault: PRECISERR: Immediate Bus Fault, exact addr known, address: 96000000

[0] [ 91.045] ti.sysbios.family.arm.m3.Hwi: line 1155: E_busFault: PRECISERR: Immediate Bus Fault, exact addr known, address: 96000000

Registers

A dump of the register contents at the time of the exception is also provided.

../_images/RegisterDump.PNG

Stack Trace

The stack trace is also provided (see Figure 6). This can be used in conjunction with the source code and the map file or CCS to get more information about what was executing at the time of the crash.

../_images/StackTraceDump.PNG
10.2.5.3.6.5. MMU Faults

MMU faults occur when an address that is not mapped to the remote core MMU is accessed. This can be due to a read, write, or an attempt to execute the address. When an MMU fault occurs, a crash dump from the remote core occurs that looks similar to the example provided in Crash Dump.

Some debugging techniques, as well as common times when an MMU fault occurs, are given as examples in the following sections.

Using CCS to Halt the Code When the Fault Happens

If the fault always happens at the same address, pre-map the location and then set up CCS with a breakpoint for that address. In this way, you can view the state of the remote core when the fault happens and see the call stack. From there, put a breakpoint at the surrounding code and step through to see where the fault happens.

Pre-mapping the address can be done either through the remote core resource table, or through CCS. With CCS, you can connect to the debug DAP and then bring up a memory window to inspect the MMU registers. Directly program the MMU from here to map some unused memory to the fault address location.

For example:

  • MMU CAM: 0x9600000E (Change the most significant 20 bits here to match the fault address. For example, it would be 96000 if the fault address is 0x96000010)
  • MMU RAM: 0xBA300000 (Change the most significant 20 bits here to match an unused 4-KB physical region in the memory map)
  • MMU Lock: 0x00000400
  • MMU LD: 0x00000001

Using the Crash Dump to Find the Location of the Fault

The crash dump call stack can indicate where the crash occurred. Using that information, connect to the remote core with CCS and put a breakpoint in the code at the most recent function in the call stack before the crash. From there, step through the code until the crash happens.

Example – Accessing a Memory Region That is Not Mapped

When using the L2 MMU, every address accessed by the remote core must be mapped. An attempt to access an un-mapped address results in an MMU fault. The following example explores the crash dump of an access to an un-mapped area.

Here is an example fault dump:

../_images/StackTraceDump2.PNG

From the crash dump, the fault address is 0x96000000. The address will not be found in the resource table, which is why the fault occurred.

Avoid hard-coding of virtual addresses for peripherals and memory blocks with a one-time physical to virtual address lookup using the resource table. There is an API available for this called Resource_physToVirt() in the resource module. This alerts that the address is not mapped in the resource table when the translation fails.

From here, either use the crash dump to see the PC and call stack or follow the instructions under the section “Using CCS to Halt the Code When the Fault Happens.” Error recovery, watchdog timers, and remoteproc autosuspend may need to be disabled to connect CCS. See Linux and Android - Disabling Error Recovery, Linux and Android – Disabling Watchdog, and Linux and Android - Disabling Remoteproc Auto-Suspend for more information on disabling these.

For this example, use the PC address which, as seen in the crash dump, is at 0xcfa6

[0] [ 107.092] Exception occurred at (PC) = 0000cfa6

Find the corresponding function by looking this address up in the map file for the remote core image. If the PC address is invalid due to an issue such as stack corruption, then this may not yield useful results. In this case, something useful is found:

../_images/SourceInsightCrashDump.PNG

Alternatively, use CCS to see the location of the fault. If CCS was already connected to the remote core before the fault happened, the core will have halted in the abort function. From here, directly set the PC address and see the line that caused the fault:

../_images/CCSFault.PNG

Use this technique at any time after booting the remote core to see what a PC address corresponds to. It will display the line that caused the error. This may, however, prevent proper execution because the registers and call stack won’t have proper values.

You can now isolate the particular line in the fxnFault() function that was executing. That code is found in the file <ipc_package>/packages/ti/ipc/tests/fault.c:

case 1:
        System_printf("Generating read MMU Fault...\n");
        a = *(volatile int *) (0x96000000);
        break;

Figure 8 clearly shows what caused the fault in this code, but when it is not clear, use CCS to see the fault in action. Once connected and the symbols are loaded, put a breakpoint in this function (if this function does not happen often). Once the breakpoint is hit, step through the code to find what is causing the fault.

Upon stepping through, observe that the variable, a, is being set to the contents of 0x96000000, which is equal to the fault address. This is the fault in this example.

Next, decide if this is a valid value that needs mapping, or if this is an invalid value that passed due to some error in the code. If it is still not known where the value is coming from, use CCS to trace it back through the call stack to fix the code. If it turns out that the address is an address that must be accessible to the remote core, then map it through the resource table to the appropriate physical memory.

10.3. EVM Hardware Setup

10.3.1. AM65x EVM

10.3.1.1. EVM Layout and Key Components

Refer to the image below which highlights the key components available on the AM65x EVM.

../_images/AM65x_IDK_Diagram.png

The complete feature set for the AM65x EVM is described in AM65x EVM User Manual. This section only provides description of components that are required to complete basic EVM setup for debugging code using an emulator and Code Composer Studio.

10.3.1.1.1. Supported JTAG Debug Probes (Emulators)

The AM65x EVM includes a cTI20 JTAG connector for external emulators and a micro USB connector for the on-board XDS110 emulator.

For XDS110 connect a USB cable to the micro USB connector J23 on the front of the board.

For external XDS200, connect the emulator to the cTI20 pin connector.

For Lauterbach or emulators with MIPI60 or TI14 pin connector, an adapter must be used to connect the emulator.

Warning

Do not connect an XDS560 emulator to the J16 application board connector. This may damage the EVM and the emulator pod.

../_images/AM65x_JTAG.png

If you are using an external emulator pod, you must select which connector sources the clock. The AM65x EVM can support the MIPI60 or cTI20 connector. The JTAG select jumper must be set correctly to specify the clock source as either the MIPI60 or the cTI20 connector.

../_images/AM65x_Clock_Select.png

10.3.1.1.2. BOOTMODE Switches

../_images/AM65x_Boot_Modes.png

MCU BOOTMODE shown:

MCUBOOTMODE[8:0] – 0000 10 011

Values in bold are fixed with resistors.

BOOTMODE shown:

BOOTMODE[18:0] - 1111111000011110000

10.3.1.1.3. UART Connection

  1. Connect a micro USB cable between UART port (J42) of the EVM and host PC.
  2. Open a serial console (e.g. Tera Term) on host PC, connect to COM port on which SOC UART0 port is connected. Four COM ports should appear in the serial console application. Connect to the first COM port in the list.
  • First COM port – SoC MAIN UART0
  • Second COM port – MCU UART
  • Third COM port – Wakeup UART
  • Fourth COM port – SoC MAIN UART1
../_images/AM65x_Tera_Term.png
  1. Open a serial console (e.g Tera Term) on host PC, connect to COM port on which EVM UART port is connected and set the following configuration.
  • Baud rate - 115200
  • Data length - 8 bit
  • Parity - None
  • Stop bits - 1
  • Flow control - None

10.3.1.1.4. Powering the EVM

Connector Specifications Example
Power DIN, 4-pin 24VDC, 5A Output (Max) CUI Inc.SDI120-24-U-P51
Barrel Plug, 2.5mm I.D x 5.5mm O.D x 9.55 12-24VDC, positive center, 2.71A Output (Max) CUI Inc. SDI65-24UD-P6

Note

The DIN connector power supply is recommended to provide enough power for applications that make use of the PCIe interface.

10.3.1.2. Minimum Hardware Setup Required to Connect to EVM

  1. Connect micro USB cable to J23 and connect USB to Host PC on which CCS is installed.
  2. Connect micro USB cable to J42 for UART serial IO.
  3. Set boot switches to “Sleep Boot” or “SD Boot” as described in the BOOT Switches section.
  4. Connect power supply to DC jack and power on EVM.
  5. Set switches and jumpers as indicated below.
Boot Settings
  • SW2 - All switches OFF
  • SW3 - All switches OFF
Jumpers
  • J4 – Short all the pins
  • JP37 – Short pins 1 & 2
  • J43 - Short pins 1 & 2
  • J8 – Short pins 1 & 2

10.3.1.3. AM65x Debug Software Setup

The following software packages are required to setup the AM65x EVM

  • Code Composer Studio IDE Environment
  • Processor SDK RTOS for AM65xx

10.3.1.3.1. CCS Host Setup

1. Download CCS from the following link: http://processors.wiki.ti.com/index.php/Download_CCS

Note

Check the Processor SDK Release Notes for the recommended CCS version.

Ensure that at least “Sitara AMx Processors” is selected:

../_images/AM65x_CCS_Install.png
10.3.1.3.1.1. Install the latest Emulation Package and Device Support Package

1. In CCS, navigate to Help -> Check for Updates and select “Sitara device support” and “TI Emulators” and click Next.

../_images/CCS_Check_for_Updates.PNG

2. Click “Next” again, select “I accept the terms of the license agreements” and click Finish to begin the installation.

../_images/CCS_Updating_Software.png

3. You may be prompted to restart CCS for the updates to take effect. Click “Restart Now” when prompted to complete the installation.

Disable Automatic Updates

To disable automatic updates in CCS, navigate to Windows -> Preferences -> Install/Update -> Automatic Updates, and uncheck “Automatically find new updates and notify me.”

This is a precautionary step to avoid automatic updates overwriting files updated through TI Emulation Updates for AM65x

10.3.1.3.2. Basic CCS Setup

The Basic CCS setup is similar to earlier Sitara devices which involves creation of target configuration and connecting to cores using the GEL files. This step is suitable for new board bring up and getting hello world going on the AM65x cores.

Users can use this setup for benchmarking code on cores, test basic pin functionality or to run diagnostics. However, multi-core application developers requiring resource management, power management or security services will require the advanced CCS setup in addition to the basic core setup.

We recommend that you follow the steps in basic setup and then migrate to the advanced SOC CCS setup for application development.

10.3.1.3.2.1. Creating the Target Configuration
  1. In CCS, open the Target Configurations window by navigating to View -> Target Configurations.
  2. In Target Configurations, right click and select “New Target Configuration.”
  3. Populate the Target Configuration File name, set the location, and click Finish.
../_images/AM65x_Target_Configuration.png
  1. Select “Texas Instruments XDS110 USB Debug Probe” for the Connection and “GPEVM_AM65x” for the Board or Device.
../_images/AM65x_Target_Configuration2.png

Note

The GEL files are automatically populated in the Target Configuration when selecting an EVM instead of an SOC. The SOC option is generally used for custom board bring up or secondary boot debugging.

  1. Navigate to the “Advanced” tab to ensure the GEL files are populated in the “initialization script” field for the various cores.
../_images/AM65x_Target_Configuration3.png

The initialization script for the Cortex M3 will setup the MCU domain and Main domain PLL clocks, PSC registers, and bring the R5 and Cortex A53 cores out of reset.

The initialization script for the Cortex A53 and Cortex R5 will perform a similar step to setup the DDR clocks and initialize DDR from the cores if required.

  1. Save the Target Configuration.
../_images/AM65x_Target_Configuration4.png
10.3.1.3.2.2. Connecting to the Cores on AM65x

1. Launch Target Configuration In CCS Editor View, go to View -> Target Configuration, and right click on the configuration that was created in the previous section and select “Launch Selected Configuration.”

  1. Connect to DMSC_Cortex_M3

Note

When connecting to the M3 core for the first time, you may be prompted with a firmware update. Please click “Update” to update the emulator firmware.

../_images/AM65x_FW_Update.png

On AM65x DMSC_Cortex_M3 is the boot master and is the first core that wakes up and starts the R5F ROM. Upon launching the target configuration, connect to DMSC_Cortex_M3 first, as this will automatically perform the PSC and PLL initialization. The following GEL output will appear in the CCS Console:

DMSC_Cortex_M3_0: GEL Output: Configuring AM65xEVM...
DMSC_Cortex_M3_0: GEL Output: Init value actual value: 0x00000888
DMSC_Cortex_M3_0: GEL Output: Register value: 0x00000888
DMSC_Cortex_M3_0: GEL Output: ATCM is on
DMSC_Cortex_M3_0: GEL Output: ATCM configured.
DMSC_Cortex_M3_0: GEL Output: Assuming execution from M3
DMSC_Cortex_M3_0: GEL Output: This script sets the first address translation region to [0x8000_0000, 0x0000_0000].
DMSC_Cortex_M3_0: GEL Output: It also sets the second address translation region to    [0x6000_0000, 0x4000_0000].
DMSC_Cortex_M3_0: GEL Output: Setting all PLLs in progress. This may take some time.
DMSC_Cortex_M3_0: GEL Output: 0 Percent Complete...
DMSC_Cortex_M3_0: GEL Output: 10 Percent Complete...
DMSC_Cortex_M3_0: GEL Output: 20 Percent Complete...
DMSC_Cortex_M3_0: GEL Output: 30 Percent Complete...
DMSC_Cortex_M3_0: GEL Output: 40 Percent Complete...
DMSC_Cortex_M3_0: GEL Output: 50 Percent Complete...
DMSC_Cortex_M3_0: GEL Output: 60 Percent Complete...
DMSC_Cortex_M3_0: GEL Output: 70 Percent Complete...
DMSC_Cortex_M3_0: GEL Output: 80 Percent Complete...
DMSC_Cortex_M3_0: GEL Output: 90 Percent Complete...
DMSC_Cortex_M3_0: GEL Output: Setting all PLLs done!
DMSC_Cortex_M3_0: GEL Output: Powering up all PSC power domains in progress...
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_WKUP_COMMON
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_DMSC
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_WKUP2MCU
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_WKUP2MAIN_INFRA
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_DEBUG2DMSC
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_WKUP_GPIO
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU2MAIN_INFRA
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU2MAIN
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU2WKUP
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MAIN2MCU
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_COMMON
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_TEST
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_MCAN_0
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_MCAN_1
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_OSPI_0
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_OSPI_1
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_HYPERBUS
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_DEBUG
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_R5_0
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_R5_1
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MAIN_INFRA
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MAIN_TEST
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MAIN_PBIST
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_CC_TOP
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_A53_CLUSTER_0
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_A53_0
DMSC_Cortex_M3_0: GEL Output: Power domain and module  state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_A53_1
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_A53_CLUSTER_1
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_A53_2
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_A53_3
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MAIN_DEBUG
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_DSS
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MMC
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_CAL
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_PCIE_0
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_PCIE_1
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_USB_0
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_USB_1
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_SAUL
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_PER_COMMON
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_NB
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_SERDES_0
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_SERDES_1
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_ICSSG_0
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_ICSSG_1
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_ICSSG_2
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_GPU
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_EMIF_DATA
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_EMIF_CFG
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up all PSC power domains done!

3. Connect to Cortex A53 or Cortex R5F Users must now connect to either the Cortex A53 (CortexA53_0_0) or Cortex R5 (MCU_PULSAR_Cortex_R5_0). The following GEL output will appear in the CCS console when connecting to the Cortex A53:

CortexA53_0_0: GEL Output: VTT Regulator Enabled
CortexA53_0_0: GEL Output:
PHY Init complete
CortexA53_0_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x8000000F
CortexA53_0_0: GEL Output:
Waiting for DRAM Init to complete...
CortexA53_0_0: GEL Output:
DRAM Init complete
CortexA53_0_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x8000001F
CortexA53_0_0: GEL Output:
Waiting for write leveling to complete
CortexA53_0_0: GEL Output:
Write leveling complete
CortexA53_0_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x8000003F
CortexA53_0_0: GEL Output: checking status per byte...
CortexA53_0_0: GEL Output:
DDRSS_DDRPHY_DX0GSR0 = 0x00932420
CortexA53_0_0: GEL Output:
DDRSS_DDRPHY_DX1GSR0 = 0x009224A0
CortexA53_0_0: GEL Output:
DDRSS_DDRPHY_DX2GSR0 = 0x00992620
CortexA53_0_0: GEL Output:
DDRSS_DDRPHY_DX3GSR0 = 0x009825A0
CortexA53_0_0: GEL Output:
Waiting for Read DQS training to complete
CortexA53_0_0: GEL Output:
Read DQS training complete
CortexA53_0_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x8000007F
CortexA53_0_0: GEL Output: checking status per byte...
CortexA53_0_0: GEL Output:
DDRSS_DDRPHY_DX0RSR0 = 0x00000000
CortexA53_0_0: GEL Output:
DDRSS_DDRPHY_DX1RSR0 = 0x00000000
CortexA53_0_0: GEL Output:
DDRSS_DDRPHY_DX2RSR0 = 0x00000000
CortexA53_0_0: GEL Output:
DDRSS_DDRPHY_DX3RSR0 = 0x00000000
CortexA53_0_0: GEL Output:
Waiting for Write leveling adjustment to complete
CortexA53_0_0: GEL Output:
Write leveling adjustment complete
CortexA53_0_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x800000FF
CortexA53_0_0: GEL Output:
Waiting for Read deskew to complete
CortexA53_0_0: GEL Output:
Read deskew complete
CortexA53_0_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x800001FF
CortexA53_0_0: GEL Output:
Waiting for Write deskew to complete
CortexA53_0_0: GEL Output:
Write deskew complete
CortexA53_0_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x800003FF
CortexA53_0_0: GEL Output:
Waiting for Read Eye training to complete
CortexA53_0_0: GEL Output:
Read Eye training complete
CortexA53_0_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x800007FF
CortexA53_0_0: GEL Output:
Waiting for Write Eye training to complete
CortexA53_0_0: GEL Output:
Write Eye training complete
CortexA53_0_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x80000FFF
CortexA53_0_0: GEL Output:
Waiting for VREF training to complete
CortexA53_0_0: GEL Output:
VREF training complete
CortexA53_0_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x80004FFF
CortexA53_0_0: GEL Output:

====

DDR4 Initialization has PASSED!!!!

====

The same GEL output will be shown if connecting to the Cortex R5 first instead of the Cortex A53.

  1. The EVM is now completely initialized to load and run code on the cores and access the full device address range. User level software is responsible to configure the pin multiplexing and peripheral configuration.

10.3.1.3.3. Advanced AM65x Debug Setup with DMSC Firmware Load

Description

AM65x EVM users testing basic functionality like R5F and A53 bring up and DDR configuration can use the basic setup described in the previous section for setting up the EVM. However, advanced application level debug that uses resource management for UDMAs, interrupt setup, power management to setup clock modules, or wakeup/power of slave cores will require loading of SYSFW (DMSC Firmware) on the M3 core so that the application can make API calls to leverage its services.

To load the SYSFW firmware, the DMSC ROM expects R5F secondary bootloader/application to provide board configuration message to initialize the cores and SOC services. The R5F application provided in SciClient uses a default board configuration message to the SYSFW and sets up the device for application debugging.

For more details, refer to the Initialization Chapter in the TRM and the SciClient User guide.

Additional Software Dependency

  • Processor SDK RTOS for AM65x

Users are required to install Processor SDK RTOS to obtain the SciClient component package before proceeding to the Next Step.

After installing Processor SDK RTOS, users should locate the latest R5F CCS init app, SYSFW binary, and the debug server script within the following directory:

${PDK_INSTALL_PATH}/packages/ti/drv/sciclient/tools/ccsLoadDmsc

The following files are provided as part for the SciClient tools:

  • launch_am65xx.js: CCS Debug Server script to perform on target connect and load DMSC firmware and R5F CCS Init app.

Location:: ${PDK_INSTALL_PATH}/packages/ti/drv/sciclient/tools/ccsLoadDmsc

  • sciclient_ccs_init_mcu1_0_release.xer5f: R5F Application with default board config

Location:: ${PDK_INSTALL_PATH}/packages/ti/drv/sciclient/tools/ccsLoadDmsc/am65xx

  • ti-sci-firmware-am6x-gp.bin: TISCI SYSFW binary loaded on the DMSC

Location:: ${PDK_INSTALL_PATH}/packages/ti/drv/sciclient/src/V0

AM65x Advanced Debug Script Flow

../_images/AM65x_Advanced_Flow.png

10.3.1.3.3.1. Creating Debug Configuration to Integrate CCS GEL and DMSC Firmware Initialization

With the intent to maintain the same CCS target connect flow as existing devices, we provide a Debug Server Script (DSS) that users can link to in their target configuration to allow for loading SYSFW firmware on the DMSC as part of the target connect process.

The DSS script allows users to perform all of the initialization using a single click. When the script is run, the following actions happens sequentially:

  1. Running On Target Connect M3 existing GEL scripts.
  2. Loading the DMSC firmware *.bin file to DMSC M3.
  3. Run the R5F Init code which performs the board configuration initialization.

At the end of the setup, the R5F and A53 are in a clean state to load code and debug the application with the SYSFW loaded on the M3 core.

Steps to Link and Run the DSS Script for DMSC Firmware Loading

  1. Update the file “pdk/packages/ti/drv/sciclient/tools/ccsLoadDmsc/launch_am65xx.js” for the following variable to your PC location:
     //<!!!!!! EDIT THIS !!!!!>
     // Set this to 1 to allow loading the GEL files directly from the ccxml file.
     disableGelLoad = 1;
     if (disableGelLoad == 0)
     {
     //Path to GEL files
     gelFilePath = "C:/ti/ccsv8/ccs_base/emulation/gel/AM65xEVM";
     }
     // Path to the directory in which this file would be residing. CCS expects
     // absolute paths to load the binaries.
     thisJsFileDirectory = "pdk/packages/ti/drv/sciclient/tools/ccsLoadDmsc";
     //<!!!!!! EDIT THIS !!!!!>
  • Set disableGelLoad =1 if GEL files is linked to the cores in the target configuration file.
  • The variable “gelFilePath” doesn’t need to be updated if CCS is installed in the default C:/ti/ directory.
  • The variable “thisJsFileDirectory” needs to be updated to point to the PDK install directory.
  1. Connect the Javascript to the CCXML file with the steps shown below.

Note

This step needs to be repeated if you switch workspaces or clean your workspace.

In the debug view after completing the basic CCS setup, Click on Debug Configurations from the button as show below:

../_images/CCS_Debug_Config.png

Select the CCXML file from the left-hand side and populate the path to the launch_am65xx.js file in the “Initialization Script” free form field and click on “Apply”.

../_images/CCS_Debug_XML.png

Once you Launch the CCXML file, the java script will automatically run and connect to R5F.

Steps to re-run the script once ccxml is already launched:

In the CCS window, navigate to “View → Scripting Console.”

In the CCS Scripting Console, type:

>  load ("<Your Path>\\launch_am65xx.js");

This would give the following output on the scripting console:

js:> load("C:\\Users\\User\\Documents\\PDK\\pdk\\packages\\ti\\drv\\sciclient\\tools\\ccsLoadDmsc\\launch_am65xx.js")
Connecting to DMSC_Cortex_M3_0!
Loading DMSC Firmware...
DMSC Firmware Load Done...
DMSC Firmware run starting now...
Connecting to MCU Cortex_R5_0!

GEL Output Log:

DMSC_Cortex_M3_0: GEL Output: Configuring AM65xEVM...
DMSC_Cortex_M3_0: GEL Output: Init value actual value: 0x00000888
DMSC_Cortex_M3_0: GEL Output: Register value: 0x00000888
DMSC_Cortex_M3_0: GEL Output: ATCM is on
DMSC_Cortex_M3_0: GEL Output: ATCM configured.
DMSC_Cortex_M3_0: GEL Output: Assuming execution from M3
DMSC_Cortex_M3_0: GEL Output: This script sets the first address translation region to [0x8000_0000, 0x0000_0000].
DMSC_Cortex_M3_0: GEL Output: It also sets the second address translation region to    [0x6000_0000, 0x4000_0000].
DMSC_Cortex_M3_0: GEL Output: Setting all PLLs in progress. This may take some time.
DMSC_Cortex_M3_0: GEL Output: 0 Percent Complete...
DMSC_Cortex_M3_0: GEL Output: 10 Percent Complete...
DMSC_Cortex_M3_0: GEL Output: 20 Percent Complete...
DMSC_Cortex_M3_0: GEL Output: 30 Percent Complete...
DMSC_Cortex_M3_0: GEL Output: 40 Percent Complete...
DMSC_Cortex_M3_0: GEL Output: 50 Percent Complete...
DMSC_Cortex_M3_0: GEL Output: 60 Percent Complete...
DMSC_Cortex_M3_0: GEL Output: 70 Percent Complete...
DMSC_Cortex_M3_0: GEL Output: 80 Percent Complete...
DMSC_Cortex_M3_0: GEL Output: 90 Percent Complete...
DMSC_Cortex_M3_0: GEL Output: Setting all PLLs done!
DMSC_Cortex_M3_0: GEL Output: Powering up all PSC power domains in progress...
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_WKUP_COMMON
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_DMSC
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_WKUP2MCU
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_WKUP2MAIN_INFRA
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_DEBUG2DMSC
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_WKUP_GPIO
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU2MAIN_INFRA
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU2MAIN
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU2WKUP
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MAIN2MCU
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_COMMON
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_TEST
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_MCAN_0
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_MCAN_1
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_OSPI_0
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_OSPI_1
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_HYPERBUS
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_DEBUG
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_R5_0
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MCU_R5_1
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MAIN_INFRA
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MAIN_TEST
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MAIN_PBIST
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_CC_TOP
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_A53_CLUSTER_0
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_A53_0
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_A53_1
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_A53_CLUSTER_1
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_A53_2
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_A53_3
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MAIN_DEBUG
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_DSS
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_MMC
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_CAL
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_PCIE_0
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_PCIE_1
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_USB_0
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_USB_1
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_SAUL
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_PER_COMMON
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_NB
DMSC_Cortex_M3_0: GEL Output: No change needed.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_SERDES_0
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_SERDES_1
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_ICSSG_0
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_ICSSG_1
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_ICSSG_2
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_GPU
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_EMIF_DATA
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up LPSC_EMIF_CFG
DMSC_Cortex_M3_0: GEL Output: Power domain and module state changed successfully.
DMSC_Cortex_M3_0: GEL Output: Powering up all PSC power domains done!
MCU_PULSAR_Cortex_R5_0: GEL Output: VTT Regulator Enabled
MCU_PULSAR_Cortex_R5_0: GEL Output:
PHY Init complete
MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x8000000F
MCU_PULSAR_Cortex_R5_0: GEL Output:
Waiting for DRAM Init to complete...
MCU_PULSAR_Cortex_R5_0: GEL Output:
DRAM Init complete
MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x8000001F
MCU_PULSAR_Cortex_R5_0: GEL Output:
Waiting for write leveling to complete
MCU_PULSAR_Cortex_R5_0: GEL Output:
Write leveling complete
MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x8000003F
MCU_PULSAR_Cortex_R5_0: GEL Output: checking status per byte...
MCU_PULSAR_Cortex_R5_0: GEL Output:
DDRSS_DDRPHY_DX0GSR0 = 0x00A728A0
MCU_PULSAR_Cortex_R5_0: GEL Output:
DDRSS_DDRPHY_DX1GSR0 = 0x00AA2920
MCU_PULSAR_Cortex_R5_0: GEL Output:
DDRSS_DDRPHY_DX2GSR0 = 0x00AB2920
MCU_PULSAR_Cortex_R5_0: GEL Output:
DDRSS_DDRPHY_DX3GSR0 = 0x00AA2A20
MCU_PULSAR_Cortex_R5_0: GEL Output:
Waiting for Read DQS training to complete
MCU_PULSAR_Cortex_R5_0: GEL Output:
Read DQS training complete
MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x8000007F
MCU_PULSAR_Cortex_R5_0: GEL Output: checking status per byte...
MCU_PULSAR_Cortex_R5_0: GEL Output:
DDRSS_DDRPHY_DX0RSR0 = 0x00000000
MCU_PULSAR_Cortex_R5_0: GEL Output:
DDRSS_DDRPHY_DX1RSR0 = 0x00000000
MCU_PULSAR_Cortex_R5_0: GEL Output:
DDRSS_DDRPHY_DX2RSR0 = 0x00000000
MCU_PULSAR_Cortex_R5_0: GEL Output:
DDRSS_DDRPHY_DX3RSR0 = 0x00000000
MCU_PULSAR_Cortex_R5_0: GEL Output:
Waiting for Write leveling adjustment to complete
MCU_PULSAR_Cortex_R5_0: GEL Output:
Write leveling adjustment complete
MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x800000FF
MCU_PULSAR_Cortex_R5_0: GEL Output:
Waiting for Read deskew to complete
MCU_PULSAR_Cortex_R5_0: GEL Output:
Read deskew complete
MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x800001FF
MCU_PULSAR_Cortex_R5_0: GEL Output:
Waiting for Write deskew to complete
MCU_PULSAR_Cortex_R5_0: GEL Output:
Write deskew complete
MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x800003FF
MCU_PULSAR_Cortex_R5_0: GEL Output:
Waiting for Read Eye training to complete
MCU_PULSAR_Cortex_R5_0: GEL Output:
Read Eye training complete
MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x800007FF
MCU_PULSAR_Cortex_R5_0: GEL Output:
Waiting for Write Eye training to complete
MCU_PULSAR_Cortex_R5_0: GEL Output:
Write Eye training complete
MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x80000FFF
MCU_PULSAR_Cortex_R5_0: GEL Output:
Waiting for VREF training to complete
MCU_PULSAR_Cortex_R5_0: GEL Output:
VREF training complete
MCU_PULSAR_Cortex_R5_0: GEL Output: DDRSS_DDRPHY_PGSR0 = 0x80004FFF
MCU_PULSAR_Cortex_R5_0: GEL Output:

====

DDR4 Initialization has PASSED!!!!

====

10.3.1.3.3.2. Additional Notes for GEL Users

R5F in Split Mode Configuration

AM65x EVM ships with the dual Cortex R5F configured in lockstep mode. The AM65x EVM GEL file provides a GEL function “Change_MCUSS_to_SplitMode” that can be added to OnTargetConnect or invoked from the DMSC_Cortex_M3 to set the dual R5F in split mode.

Configuring PRU-ICSS in Sync Mode

The PRU-ICSS subsystem can be configured to SYNC mode (250 Mhz) using the GEL function “PRU_ICSSG_SyncMode_250MHz” from Cortex A53 or R5F

10.3.2. AM572x GP EVM Hardware Setup

Description

The AM572x Evaluation Module provides an affordable platform to quickly start evaluation of Sitara™ ARM® Cortex®-A15 AM57x Processors (AM5728, AM5726, AM5718, AM5716) and accelerate development for HMI, machine vision, networking, medical imaging and many other industrial applications. It is a development platform based on the dual ARM Cortex-A15, dual C66x DSP processor that is integrated with tons of connectivity such as PCIe, SATA, HDMI, USB 3.0/2.0, Dual Gigabit Ethernet, and more.

The AM572x Evaluation Module also integrates video and 3D/2D graphics acceleration, as well as a qual-core Programmable Real-time Unit (PRU) and dual ARM Cortex-M4 cores.

Contents of the kit

../_images/EVM_modules.png

Module:

  • Processor Module
  • LCD Module
  • Camera Module

Other components:

  • µSD card with Linux SDK
  • USB-to-serial debug cable
  • HDMI cable for optional external display
  • LCD brackets

Printed documentation:

EVM Layout and Key Components

../_images/AM572X_GP_EVM_Overview.png

JTAG debug probes (aka Emulators) supported

List of standalone JTAG debug probes supported:

  • XDS100-class JTAG debug probes (low cost, low performance). XDS100v1 is not supported.
  • XDS200-class JTAG debug probes (recommended)
  • XDS560v2-class JTAG debug probes (high performance)

Host Drivers

Download and install Virtual COM Port Drivers for TTL-232R-3V3 USB to UART cable from the FTDI website:

Minimal EVM setup

Setting boot switches

../_images/Boot_Switches.png

Other Boot Pin configurations: GP EVM Boot Options


Connecting Emulator

Note: This EVM setup is only required for developers who need to connect to cores using Code Composer studio to load application.

The JTAG emulation pins for the EVM are on the back of the processor module. User need to carefully unmount the processor module from the LCD panel in order to get access to the JTAG pins.

Refer to the image below for how to safely separate the processor module from the LCD panel.

../_images/X15_PModule_disconnect.jpg ../_images/JMI_0065.jpg

Image for how to connect the XDS200 Emulator to the 20 pin header is shown below:
../_images/GPEVM_XDS200.jpg

Powering up the EVM

Power Supply specifications

../_images/CUI_Isolated_Power_Supply.png

Please note that a power supply is NOT included with the AM572x Evaluation Module and needs to be purchased separately. A power supply with the following specs is needed:

  • 12V DC output
  • 5A output
  • Positive inner and negative outer terminals
  • Female barrel with 2.5mm inner diameter and 5.5mm outer diameter
  • Isolated power supply

PMIC auto-off after seven seconds

The Power Management Integrated Circuit (PMIC) on the TMDSEVM572X turns off the board in seven seconds after power on to work around a hardware errata. After seven seconds, the PMIC powers off unless software writes to a PMIC register to keep it on.

In emulation setup, the GEL file will keep the PMIC on after you connect to the A15 core on the SoC. While booting from ROM bootloader user application software, would need to keep the PMIC ON while initializing the board.

In Linux boot, the uboot code keeps the PMIC On and in the TI RTOS boot scenario, the SBL component provides the same functionality

NOTE

  • To allow quicker execution of the GEL before the PMIC shuts off, you can increase the JTAG TCLK Frequency in Advance settings of your target configuration to 15Mhz or to the maximum (20Mhz).
  • If the above CCS connect sequence does not work in the first attempt, it means that the PMIC switched off before the GEL could initialize I2C and modify the PMIC settings. In that case, the connection has failed, hit connect in CCS debug view without removing the power cable and then immediately hit the power switch besides the power plug.

Connect Power to the EVM

../_images/Push_Power_EVM.png

CCS Setup

There are two scenarios while connecting to the EVM :

  • Connect to EVM without a SD card boot image to boot the EVM
  • Connect to EVM after booting an image from the SD card.

Connect without a SD card boot image

Configuring target configuration files

Launch CCS and create new target configuration(File->New->Target Configuration file) as shown in the images below and provide appropriate name to the configuration. Select Spectrum digital XDS200 emulator and target as GPEVM_AM572x_SiRevA.

Note: For older revisions of CCSv6, If you don`t find the GPEVM_AM572x_SiRevA target make sure you have installed the CCSv6 package with support for Sitara Processors and done the software update correctly from the Help Menu to get the latest Sitara CSP package.

../_images/GPEVM_Target_configuration.jpg

In advance settings, make sure that the gel files are populated correctly. The following GEL files and their corresponding cores are provided below:

  • IcePick_D: AM572x_ICEPickD_Utility.gel
  • CS_DAP_DebugSS: AM572x_dap_startup.gel
  • CS_DAP_PC: AM572x_CS_DAP_PC_Utility.gel
  • A15_0: AM572x_cortexa15_cpu0_startup.gel
  • A15_1: AM572x_cortexa15_cpu1_startup.gel
  • C66x_0: AM572x_dsp_startup.gel
  • C66x_1: AM572x_dsp_startup.gel
  • M4_IPU_1_C0: AM572x_cortexM4_startup.gel
  • M4_IPU_1_C1: AM572x_cortexM4_startup.gel
  • M4_IPU_2_C0: AM572x_cortexM4_startup.gel
  • M4_IPU_2_C1: AM572x_cortexM4_startup.gel
  • IVAHD: AM572x_ivahd_startup.gel

Connecting to target

Step1 : Download Code composer Studio and AM572x Sitara CSP package as described in the wiki article mentioned below:

Install Code composer Studio v6 for AM572x

Step2: AM572x EVM doesn`t have any boot switches to configure for emulation mode. so configure the boot switches to SD Boot Mode. Dont Populate the uSD card when the intent is to connect and load code over emulator and not to boot the device using uSD card.

Step3: Connect an XDS200 Emulator to emulation pins at the back of the GP EVM as shown in section.Connecting_Emulator

Step4: Launch CCS and create new target configuration as discussed in the previous section.


Step5: Launch Target configuration you just created. AM572x is an ARM master boot device so connect to the A15_0 first. It is also recommended that you do a CPU reset from (Run->Reset->CPU Reset) Menu on the A15 to put it in a clean state as the EVM is designed to come up in SD boot mode.

Note: Keep in mind the PMIC shutdown issue discussed in previous section while connecting to the target cores. Due to the PMIC shutdown issue, users need to connect to A15_0 as soon as you push the power button to enable power to the SoC.

Complete GEL log from A15 connect is provided below:
IcePick_D: GEL Output: IVAHD ICONT1 is released from Wait-In-Reset.
IcePick_D: GEL Output: IVAHD ICONT2 is released from Wait-In-Reset.
CS_DAP_DebugSS: GEL Output: --->>> CONFIGURE DEBUG DPLL settings to 1.9 GHZs  <<<---
CS_DAP_DebugSS: GEL Output: > Setup DebugSS 1.9GHz in progress...
CS_DAP_DebugSS: GEL Output: < Done with Setup DebugSS Trace export clock (TPIU) to 97MHz
CS_DAP_DebugSS: GEL Output: < Done with Setup DebugSS PLL Clocking 1.9GHz
CS_DAP_DebugSS: GEL Output: < Done with Setup DebugSS ATB Clocking 380MHz
CS_DAP_DebugSS: GEL Output: < Done with Setup DebugSS Trace export clock (TPIU) to 97MHz
CS_DAP_DebugSS: GEL Output: --->>> TURNING ON L3_INSTR and L3_3 clocks required for debug instrumention <<<<<<----
CS_DAP_DebugSS: GEL Output: ---<<< L3 instrumentation clocks are enabled >>>> ---
CS_DAP_DebugSS: GEL Output: --->>> Mapping TIMER supsend sources to default cores <<<<<<----
CS_DAP_PC: GEL Output: Cortex-A15 1 is not in WIR mode so nothing to do.
CortexA15_0: GEL Output: --->>> AM572x GP EVM <<<---
CortexA15_0: GEL Output: --->>> AM572x Target Connect Sequence Begins ... <<<---
CortexA15_0: GEL Output: --->>> I2C Init <<<---
CortexA15_0: GEL Output: --->>> AM572x Begin MMC2 Pad Configuration <<<---
CortexA15_0: GEL Output: --->>> AM572x End MMC2 Pad Configuration <<<---
CortexA15_0: GEL Output: --->>> AM572x PG2.0 GP device <<<---
CortexA15_0: GEL Output: --->>> PRCM Clock Configuration for OPPNOM in progress... <<<---
CortexA15_0: GEL Output:    Cortex A15 DPLL OPP 0 clock config is in progress...
CortexA15_0: GEL Output:    Cortex A15 DPLL is already locked, now unlocking...
CortexA15_0: GEL Output:    Cortex A15 DPLL OPP 0 is DONE!
CortexA15_0: GEL Output:    IVA DPLL OPP 0 clock config is in progress...
CortexA15_0: GEL Output:    IVA DPLL OPP 0 is DONE!
CortexA15_0: GEL Output:    PER DPLL OPP 0 clock config in progress...
CortexA15_0: GEL Output:    PER DPLL already locked, now unlocking
CortexA15_0: GEL Output:    PER DPLL OPP 0 is DONE!
CortexA15_0: GEL Output:    CORE DPLL OPP 0 clock config is in progress...
CortexA15_0: GEL Output:    CORE DPLL OPP  already locked, now unlocking....
CortexA15_0: GEL Output:    CORE DPLL OPP 0 is DONE!
CortexA15_0: GEL Output:    ABE DPLL OPP 0 clock config in progress...
CortexA15_0: GEL Output:    ABE DPLL OPP 0 is DONE!
CortexA15_0: GEL Output:    GMAC DPLL OPP 0 clock config is in progress...
CortexA15_0: GEL Output:    GMAC DPLL OPP 0 is DONE!
CortexA15_0: GEL Output:    GPU DPLL OPP 0 clock config is in progress...
CortexA15_0: GEL Output:    GPU DPLL OPP 0 is DONE!
CortexA15_0: GEL Output:    DSP DPLL OPP 0 clock config is in progress...
CortexA15_0: GEL Output:    DSP DPLL OPP 0 is DONE!
CortexA15_0: GEL Output:    PCIE_REF DPLL OPP 0 clock config is in progress...
CortexA15_0: GEL Output:    PCIE_REF DPLL OPP 0 is DONE!
CortexA15_0: GEL Output: --->>> PRCM Clock Configuration for OPP 0 is DONE! <<<---
CortexA15_0: GEL Output: --->>> PRCM Configuration for all modules in progress... <<<---
CortexA15_0: GEL Output: --->>> PRCM Configuration for all modules is DONE! <<<---
CortexA15_0: GEL Output: --->>> DDR3 Initialization is in progress ... <<<---
CortexA15_0: GEL Output:    DDR DPLL clock config for 532MHz is in progress...
CortexA15_0: GEL Output:    DDR DPLL clock config for 532MHz is in DONE!
CortexA15_0: GEL Output:        Launch full leveling
CortexA15_0: GEL Output:        Updating slave ratios in PHY_STATUSx registers
CortexA15_0: GEL Output:        as per HW leveling output
CortexA15_0: GEL Output:        HW leveling is now disabled. Using slave ratios from
CortexA15_0: GEL Output:        PHY_STATUSx registers
CortexA15_0: GEL Output:        Launch full leveling
CortexA15_0: GEL Output:        Updating slave ratios in PHY_STATUSx registers
CortexA15_0: GEL Output:        as per HW leveling output
CortexA15_0: GEL Output:        HW leveling is now disabled. Using slave ratios from
CortexA15_0: GEL Output:        PHY_STATUSx registers
CortexA15_0: GEL Output:        Two EMIFs in interleaved mode - (2GB total)
CortexA15_0: GEL Output: --->>> DDR3 Initialization is DONE! <<<---
CortexA15_0: GEL Output: --->>> AM572x Target Connect Sequence DONE !!!!!  <<<---
CortexA15_0: GEL Output: --->>> IPU1SS Initialization is in progress ... <<<---
CortexA15_0: GEL Output: --->>> IPU1SS Initialization is DONE! <<<---
CortexA15_0: GEL Output: --->>> IPU2SS Initialization is in progress ... <<<---
CortexA15_0: GEL Output: --->>> IPU2SS Initialization is DONE! <<<---
CortexA15_0: GEL Output: --->>> DSP1SS Initialization is in progress ... <<<---
CortexA15_0: GEL Output: DEBUG: Clock is active ...
CortexA15_0: GEL Output: DEBUG: Checking for data integrity in DSPSS L2RAM ...
CortexA15_0: GEL Output: DEBUG: Data integrity check in GEM L2RAM is sucessful!
CortexA15_0: GEL Output: --->>> DSP1SS Initialization is DONE! <<<---
CortexA15_0: GEL Output: >> START ==> Enable L3 Clk
CortexA15_0: GEL Output: >> Change Suspend source for GPTimer5 to DSP1
CortexA15_0: GEL Output: --->>> DSP2SS Initialization is in progress ... <<<---
CortexA15_0: GEL Output: DEBUG: Clock is active ...
CortexA15_0: GEL Output: DEBUG: Checking for data integrity in DSPSS L2RAM ...
CortexA15_0: GEL Output: DEBUG: Data integrity check in GEM L2RAM is sucessful!
CortexA15_0: GEL Output: --->>> DSP2SS Initialization is DONE! <<<---
CortexA15_0: GEL Output: --->>> IVAHD Initialization is in progress ... <<<---
CortexA15_0: GEL Output: DEBUG: Clock is active ...
CortexA15_0: GEL Output: --->>> IVAHD Initialization is DONE! ... <<<---
CortexA15_0: GEL Output: --->>> PRUSS 1 and 2 Initialization is in progress ... <<<---
CortexA15_0: GEL Output: --->>> PRUSS 1 and 2 Initialization is in complete ... <<<---

Multi-core Initialization

After connecting to the boot master core – typically the ARM core – you may need to connect to a slave core in order to run code. Depending on your SOC, the slave core can be

  • DSP C66x
  • ARM M4
  • PRUSS
  • IVAHD

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.

../_images/Multicore-Enable.jpg

If you wish to run TI RTOS code on DSP, please also run the Timer Suspend Control Options.


Connect after booting from SD card

When you boot an image from the SD card, the secondary boot loader will configure the device clocks, DDR and wake up the slave cores on the AM572x processor on GP EVM hence you don`t need the GEL initialization scripts to redo the clock and DDR settings.

Note: If you are running the Image processing demo or have created an SD card with the SBL (mlo) for booting the board then please follow the following procedure

Configuring target configuration files

Launch CCS and create new target configuration(File->New->Target Configuration file) as shown in the images below and provide appropriate name to the configuration. Select Spectrum digital XDS200 emulator and target as AM5728_RevA. This target setting will not populate the GEL files when you connect to the target

Note: If you don`t find the AM572x_RevA target make sure you have installed the CCSv6.1.1 package and done the software update correctly.


../_images/COnfigure_targetConfigFiles_SDboot.png

GEL file options

Changing SoC Operating point

The GEL file for setting the clocks on the SoC provides 3 Operating points OPP_NOM, OPP_OD and OPP_HIGH.

OPP_NOM PLL Settings:

  • ARM = 1000 MHz
  • DSP = 600 Mhz
  • IVA = 532 Mhz

OPP_OD PLL Settings:

  • ARM = 1176 MHz
  • DSP = 600 Mhz
  • IVA = 430 Mhz
  • GPU =500 Mhz

OPP_HIGH PLL Settings:

  • ARM = 1500 MHz
  • DSP = 700 Mhz
  • GPU = 425 Mhz
  • IVA = 388.3 Mhz

Timer Suspend Control Options for DSP

On AM57xx devices, all the timers on the chip have their suspend control signal routed to the A15 core. Which means that if any of the slave cores are using these timers, the timers will continue to run even when the slave core has been paused. The timer will only pause when the A15 core is halted.

This is confusing while debugging code on slave cores if you are relying on timer for logging, inserting delays or if the timer keeps firing interrupts even when the core is halted. One such scenario occurs with GPtimer5 when DSP developers are using SYS/BIOS. The OS uses GPtimer5 on the DSP and forces a frequency check to confirm the timer configuration, however the OS can’t gain access to the timer due to the hook up of the suspend control signals.

Due to this issue the SYS/BIOS developers will need to configure an additional CCS configuration check to connect the GPTimer suspend control signal to the DSP as shown in the image below:

../_images/GPtimer5_DSPConnect.png

Other How-To Options

Connecting the UART

Connecting FTDI cable to the 6 pin UART header for serial debug

../_images/GP_EVM_UART.jpg

Note: Pin 1 corresponds to ground.

Connect the USB end to the host. If you connect to the EVM UART, use the following host configuration setup in the serial terminal software (Minicom, Teraterm, etc) Baud Rate: 115200 Data Bits: 8 Parity: None Flow Control: Off

Connect Ethernet cable to enable Network Connectivity

For ethernet connectivity connect the ethernet cable to the top serial port which is port 0 on the GP EVM.

../_images/AM572x_GP_EVM_Ethernet_connect.jpg

You can connect the other end of the cable directly to the host or through a network switch based on the configuration required for your test setup.

10.3.3. TMDXIDK5728 Hardware Setup

Description

The TMDXIDK5728 is a standalone test, development, and evaluation module system that enables developers to write software and develop hardware for industrial communication type applications. It has been equipped with a TI AM572x processor and a defined set of features to allow the user to experience industrial communication solutions using serial or Ethernet based interfaces. Using standard interfaces, the IDK may interface to other processors or systems and act as a communication gateway in this case. In addition it can directly operate as a standard remote I/O system or simple sensor connected to an industrial communication network. The embedded emulation logic allows emulation and debug using standard development tools such as TI’s Code Composer Studio by just using the supplied USB cable.

EVM Layout and key components

../_images/AM572x_IDK_layout.png
  • PRU1ETH0 and PRU2ETH0 are not enabled by default

Quick Start Guide

This section talks about how to quickly setup the AM572x Industrial Development Kit (IDK) EVM. This guide is a Beta version and it is designed to help you through the initial setup of the EVM.


1. Once you have received the TI-RTOS or Linux™ software from your TI representative, create a bootable µSD card (using the included blank µSD) and insert it into the EVM
../_images/IDK_uSD.png
2. Connect the power cable to the power jack on the board and plug in to an AC power source
../_images/Power_cord_connect.png

Note: When powering this IDK, always use the recommended power supply (GlobTek Part Number TR9CA6500LCP-N, Model Number GT-43008-3306-1.0-T3) or equivalent model having output voltage of +5VDC and output current max 6.5 Amp as well as the applicable regional product regulatory/safety certification requirements requirements such as (by example) UL, CSA, VDE, CCC, PSE, etc.


3. Connect the microUSB cable to USB JTAG/Console port on the EVM and connect to the USB on the host. Connect Ethernet cable to GIG ETH0 if Network connectivity is required
../_images/JTAGUSB_UART.png

Note: The serial port will not show up on the host PC until you power on the EVM.

4. Select the power ON button to run power the IDK.
../_images/PowerON.png

After, you power on the EVM the Status, Industrial LED2, Industrial LED3 will turn on. If the microUSB cable is pluged in then the LED corresponding to FTDI UARTtoUSB will be turned on.

5. Users can now connect to UART and the on board XDS100 emulator from the host machine.For UART port connections set the serial terminal software Tera term/minicom/hyperterminal to baudrate 115200 to see log messages. Connecting to target using emulator has been discussed in the section below.
../_images/Serial_connect.jpg
../_images/Baudrate.jpg

Connecting IDK EVM to Code Composer Studio

Step1 : Download Code composer Studio and AM572x Sitara CSP package as described in the wiki article mentioned below:

Install Code composer Studio for AM572x

Step2: Connect IDK EVM as described in the Quick Start Guide. Populating the uSD card is not required as the intent is to connect and load code over emulator and not to boot the device using uSD card. AM572x IDK doesn`t have any boot switches to configure for emulation mode.

Step3: Launch CCS and create new target configuration(File->New->Target Configuration file) as shown in the images below and provide appropriate name to the configuration. Select Texas Instuments XDS100v2 emulator and target as IDK_AM572x.

NOTE If you don`t find the IDK_AM572x target make sure you have installed the Sitara Device support version 1.3.x package correctly

../_images/Target_configuration.png

Step4: In advance settings, Make sure that the corresponding IDK GEL file are populated for all the cores. The following GEL files and their corresponding cores are provided below:
  • Cortex_A15_0: ..\..\emulation\boards\am572x\gel\idk_am572x.gel
  • C66x_DSP1: ..\..\emulation\boards\am572x\gel\AM572x_dsp_startup.gel
  • Cortex_M4_IPU1_C0: ..\..\emulation\boards\am572x\gel\AM572x_cortexM4_startup.gel

Note: GEL files are located under ccsv6\ccs_base\emulation\boards\am572x\gel after the CSP package is installed


Step5: Launch Target configuration you just created. AM572x is an ARM master boot device so connect to the A15_0 first. It is also recommended that you do a CPU reset from (Run->Reset->CPU Reset) Menu on the A15 to put it in a clean state as the IDK is designed to come up in SD boot mode.

Complete GEL log from A15 connect is provided below:
CortexA15_0: GEL Output: --->>> AM572x Target Connect Sequence Begins ... <<<---
CortexA15_0: GEL Output: --->>> AM572x Begin MMC2 Pad Configuration <<<---
CortexA15_0: GEL Output: --->>> AM572x End MMC2 Pad Configuration <<<---
CortexA15_0: GEL Output: --->>> AM572x PG1.1 GP device <<<---
CortexA15_0: GEL Output: --->>> I2C Init <<<---
CortexA15_0: GEL Output: --->>> PRCM Clock Configuration for OPPNOM in progress... <<<---
CortexA15_0: GEL Output:    Cortex A15 DPLL OPP 0 clock config is in progress...
CortexA15_0: GEL Output:    Cortex A15 DPLL is already locked, now unlocking...
CortexA15_0: GEL Output:    Cortex A15 DPLL OPP 0 is DONE!
CortexA15_0: GEL Output:    IVA DPLL OPP 0 clock config is in progress...
CortexA15_0: GEL Output:    IVA DPLL OPP 0 is DONE!
CortexA15_0: GEL Output:    PER DPLL OPP 0 clock config in progress...
CortexA15_0: GEL Output:    PER DPLL already locked, now unlocking
CortexA15_0: GEL Output:    PER DPLL OPP 0 is DONE!
CortexA15_0: GEL Output:    CORE DPLL OPP 0 clock config is in progress...
CortexA15_0: GEL Output:    CORE DPLL OPP  already locked, now unlocking....
CortexA15_0: GEL Output:    CORE DPLL OPP 0 is DONE!
CortexA15_0: GEL Output:    ABE DPLL OPP 0 clock config in progress...
CortexA15_0: GEL Output:    ABE DPLL OPP 0 is DONE!
CortexA15_0: GEL Output:    GMAC DPLL OPP 0 clock config is in progress...
CortexA15_0: GEL Output:    GMAC DPLL OPP 0 is DONE!
CortexA15_0: GEL Output:    GPU DPLL OPP 0 clock config is in progress...
CortexA15_0: GEL Output:    GPU DPLL OPP 0 is DONE!
CortexA15_0: GEL Output:    DSP DPLL OPP 0 clock config is in progress...
CortexA15_0: GEL Output:    DSP DPLL OPP 0 is DONE!
CortexA15_0: GEL Output:    PCIE_REF DPLL OPP 0 clock config is in progress...
CortexA15_0: GEL Output:    PCIE_REF DPLL OPP 0 is DONE!
CortexA15_0: GEL Output: --->>> PRCM Clock Configuration for OPP 0 is DONE! <<<---
CortexA15_0: GEL Output: --->>> PRCM Configuration for all modules in progress... <<<---
CortexA15_0: GEL Output: --->>> PRCM Configuration for all modules is DONE! <<<---
CortexA15_0: GEL Output: --->>> DDR3 Initialization is in progress ... <<<---
CortexA15_0: GEL Output:    DDR DPLL clock config for 532MHz is in progress...
CortexA15_0: GEL Output:    DDR DPLL clock config for 532MHz is in DONE!
CortexA15_0: GEL Output: DEBUG: Overall DDR configuration
CortexA15_0: GEL Output: DEBUG: EMIF1 and EMIF1 DDR IOs config (CTRL_MODULE_CORE_PAD module)
CortexA15_0: GEL Output: DEBUG: DDR PHY config (CTRL_MODULE_WKUP module)
CortexA15_0: GEL Output: DEBUG: EMIF1 ctrl + associated DDR PHYs initial config (EMIF1 module)
CortexA15_0: GEL Output: DEBUG: EMIF1 channel - Launch full levelling
CortexA15_0: GEL Output: DEBUG: EMIF2 ctrl + associated DDR PHYs initial config (EMIF2 module)
CortexA15_0: GEL Output: DEBUG: EMIF1 channel - Launch full levelling
CortexA15_0: GEL Output: DEBUG: Setting LISA maps in non-interleaved dual-EMIF mode
CortexA15_0: GEL Output: --->>> DDR3 Initialization is DONE! <<<---
CortexA15_0: GEL Output: --->>> AM572x Target Connect Sequence DONE !!!!!  <<<

Step6 : To connect to the DSP, M4,PRUSS or to IVAHD go to Scripts menu and under AM572x MULTICORE Initialization enable the corresponding Sub system clock Enable API.For Eg. FOr DSP1 select DSP11SSClkEnable_API. After running the clock enable option, you can connect to the core.


../_images/Multicore-Enable.jpg

AM572x_Industrial_EVM_Hardware_Users_Guide

10.3.4. 66AK2GX GP EVM Hardware Setup

Description

The EVMK2G is a high performance, cost-efficient, standalone development platform that enables users to evaluate and develop applications for the Texas Instrument’s Keystone2 System-on-Chip (SoC) 66AK2GX. The Key features of EVM are:

Processor and controller

  • K2G SoC 66AK2GX is based on keystone II architecture with ARM cortex A15 @600MHz and C66x DSP @600MHz
  • Board Management Controller (BMC) for board management functions like system status and Boot mode control

Volatile and non volatile Memory/Interfaces:

  • 2GByte of DDR3L with ECC
  • 2Gbit of NAND Flash
  • 128Mbit of SPI Flash
  • 512Mbit of QSPI Flash
  • 128kByte of I2C EEPROM for Boot support from I2C
  • Micro SD-Card slot
  • 16GByte of eMMC

High speed and Serial Interfaces

  • Gigabit Ethernet port supporting 10/100/1000 Mbps data rate on RJ45 connector
  • PCIe x1 card slot
  • COM8 interface
  • DCAN and MLB interfaces
  • One USB2.0 host and one USB2.0 Dual-role ports
  • One RS232 serial interface on DB9 connector or UART over mini-USB connector, One UART interface on 6 pin header

Multimedia and display:

  • 4.3” LCD display with Capacitive touch (Sold separately)
  • HDMI transmitter
  • Audio Line In and Line Out

JTAG and Emulation:

  • MIPI 60-Pin JTAG header to support all types of external emulator
  • On Board XDS200 Emulator
  • Powered by DC power-wall adaptor (12V/5A)

EVM Layout and Key Components

../_images/TI_K2GEVM.png

JTAG debug probes (aka Emulators) supported

List of standalone JTAG debug probes supported:

  • XDS100-class JTAG debug probes (low cost, low performance). XDS100v1 is not supported.
  • XDS200-class JTAG debug probes (recommended)
  • XDS560v2-class JTAG debug probes (high performance)

Minimal EVM setup

Setting boot switches

The DIP Switch /Boot mode switch (SW3) is used for selecting the boot mode.


For EVM Out of box experience uses SD/MMC boot as shown in the image:
../_images/Boot_switch_SDboot.jpg

For Debugging over emulator use “No Boot/Sleep” Setting as shown below:
../_images/Boot_Switch_NoBoot.jpg

The table below provides the list of all the boot modes supported on the GP EVM

Note: Read the PCB marking around the boot switch for your EVM to interpret of ON and OFF marking on the switch

  • For Rev C K2G02 GP EVM: ON = ‘0’ and OFF = ‘1’
  • For Rev C/Rev D K2G12 GP EVM: ON = ‘1’ and OFF = ‘0’

Other Boot Pin configurations:


SW3[4:1] BOOT MODE
0000 (0x0) Sleep/No Boot
0001 (0x1) PCIe boot
0010 (0x2) Ethernet Boot
0011 (0x3) I2C PLL Boot
0100 (0x4) SPI No PLL Boot
0101 (0x5) SPI PLL-1 Boot
0110 (0x6) USB Boot
0111 (0x7) MMC/SD Boot
1000 (0x8) UART Boot
1001 (0x9) QSPI 96 Boot
1010 (0xa) eMMC Boot
1011 (0xb) NAND Boot
1100 (0xc) I2C No PLL Boot
1101 (0xd) SPI PLL-2 Boot
1110 (0xe) SPI PLL-3 Boot
1111 (0xf) QSPI 48 Boot

Connecting Emulator

Note: This EVM setup is only required for developers who need to connect to cores using Code Composer studio to load application.


The EVM supports two types of Emulation - “On-Board-XDS200 emulator” and “60-pin MIPI Header”

When external emulator is not connected to MIPI 60-pin connector, On-board XDS200 embedded JTAG emulator is the default type of emulation (SoC JTAG signals are routed to XDS200 on-board emulator). When external emulator is connected to MIPI 60-pin header, it is automatically detected and SoC JTAG signals are routed to external emulator.

On Board XDS200 emulator

EVMK2G has on-board XDS200 embedded JTAG emulation circuitry. Hence user does not require any external emulator to connect EVM with Code Composer Studio (CCS). User can connect target SoC in EVM to CCS through USB cable supplied in the EVM kit.

Use the USB to USB mini-B cable provided. Connect the USB mini-B connector to the USB mini-B interface near to the audio line in on the EVM, and the USB connector to your PC. This enables XDS-2xx emulation and is directly useable by CCS.

../_images/XDS200_connect.png

NOTE On Rev C boards and earlier revisions of the board, users who plan to connect the USB cable to USB 3.0 cable need to follow the instructions to update Emulation firmware using steps described in the article Updating_the_XDS200_firmware Without the firmware update, users are recommended to disconnect the mini USB cable from the XDS USB connector before powering up the EVM and reconnect after board power up is complete.


MIPI 60-pin header for connecting External emulator

If you are using a different JTAG, you can connect it at MIPI60 connector (EMU1). The MIPI 60-pin JTAG header is provided on-board for high speed real-time emulation. All JTAG and EMUxx signals are terminated on MIPI 60-pin header.

No emulation firmware upgrade is required if users plan to use an external emulator The MIPI 60-pin JTAG header supports all standard (XDS510 or XDS560) TI DSP emulators. Please refer to the documentation supplied with your emulator for connection assistance.

Powering up the EVM

Power Supply specifications

The EVMK2G can be powered from a single +12V / 5.0A DC (60W) external power supply connected to the DC power jack (J3). Internally, +12V input is converted into required voltage levels using local DC-DC converters

Please note that a power supply is included with the 66AK2GX Evaluation Module. The power supply has the following specs :

  • 12V DC output
  • 5A output
  • Positive inner and negative outer terminals
  • Female barrel with 2.5mm inner diameter and 5.5mm outer diameter
  • Isolated power supply

CCS Setup

This section describes the setup to connect to 66AK2GX GP EVM using Code composer Studio environment and an emulator.

There are two scenarios while connecting to the EVM :

  • Connect to EVM without a SD card boot image to boot the EVM
  • Connect to EVM after booting an image from the SD card.

Before discussing both these scenarios, let us look at how to pull in the latest KeystoneII device support in CCSv6


Update CCS v6 to install Keystone II device Support package

All revisions of the board require this step to be performed in order to get the latest GEL files and the target content for the K2G. This step will not be required for CCS versions higher than version 6.1.3. CCSv6.1.3 package contain KeystoneII device support package v1.1.4 which doesn`t contain 66AK2GX GPEVM specific target files hence we recommend this update.

Step 1 All CCS v6.1.3 and earlier version users are required to update the Keystone Device Support package by going into the Help->Check For Updates

../_images/Check_for_Updates.png

Step 2 Select Keystone2 device support package. Follow menu options to continue with the update

Step 3 After the update is complete go to Help->Installation details and check that Keystone2 device support package v1.1.5 or later are installed as shown below

../_images/KeystoneII_device_support_package.png

Note: The package can be downloaded separately from the link below and manually unzipped into CCSv6 installation.


Note for K2G devices: If using CCS v6.1.2 and Keystone2 device support v1.1.7, 66AK2G02 would not show up in the list of devices when creating the target configuration. This is due to an incompatibility in the XML parser in CCS v6.1.2 with the K2G device xml. In order to work-around this issue, make the change in 66AK2G02.xml as illustrated below in order to have 66AK2G02 display in the device list. This problem does not exist in CCS v6.1.3 onwards as the XML parser has been updated.
C:\ti\ccsv6\ccs_base\common\targetdb\devices\66AK2G02.xml
Line #1
<?xml version=”1.1” encoding=”UTF-8” standalone=”no”?>
to
<?xml version=”1.0” encoding=”UTF-8” standalone=”no”?>


Connect without a SD card boot image

Configuring target configuration files

Launch CCS and create new target configuration(File->New->Target Configuration file) as shown in the images below

../_images/CCS_target_configuration.png

Provide appropriate name to the configuration. Select Spectrum digital XDS200 emulator and target as K2G GPEVM.

Note: If you don`t find the 66AK2G02 target make sure you have installed the CCSv6.1.3 package or for CCSv6.1.2 and earlier ensure that you have done the software update correctly as shown in the how to section below.

../_images/K2G_GPEVM_Target_configuration.jpg

In advance settings, make sure that the gel files are populated correctly. The following GEL files and their corresponding cores are provided below:

  • C66X Core: evmk2g.gel
  • A15 Core: evmk2g_arm.gel

Connecting to target

Step1 : Download Code composer Studio v6.1.3 or for CCSv6.1.2 and earlier, ensure it contains Keystone device support package version 1.1.5 as described in the how to guide

Install Code composer Studio v6 for K2G

Step2: 66AK2GX GP EVM contains boot switches to configure for “No
boot/sleep” mode. So configure the boot switches to No Boot Mode as described in the SettingBootSwitches

Step3: Connect an XDS200 Emulator to XDS USB of the GP EVM as shown in ConnectingEmulator

Step4: Launch CCS and create new target configuration as discussed in the previous section ConfiguringTargetConfigFile

Step5: Launch Target configuration you just created.

../_images/K2G_Launch_targetConfig.png
Step6:K2G can be a DSP or an ARM master boot device so connect to
the C66x or the A15_0.

GEL Log

A15_0: GEL Output: PLL has been configured (24.0 MHz * 100 / 1 / 4 = 600.0 MHz)
A15_0: GEL Output: ARM PLL has been configured with ref clock 24MHz, -sysclkp_period 41.6666 (24.0 MHz * 100 / 1 / 4 = 600.0 MHz)
A15_0: GEL Output: Power on all PSC modules and DSP domains...
A15_0: GEL Output: Power on PCIE PSC modules and DSP domains... Done.
A15_0: GEL Output: UART PLL has been configured (24.0 MHz * 128 / 1 / 8 = 384.0 MHz)
A15_0: GEL Output: NSS PLL has been configured (24.0 MHz * 250 / 3 / 2 = 1000.0 MHz)
A15_0: GEL Output: ICSS PLL has been configured (24.0 MHz * 250 / 3 / 10 = 200.0 MHz)
A15_0: GEL Output: DSS PLL has been configured (24.0 MHz * 198 / 12 / 16 = 24.75 MHz)
A15_0: GEL Output: DDR PLL has been configured (24.0 MHz * 250 / 3 / 10 = 200.0 MHz)
A15_0: GEL Output: XMC setup complete. A15_0: GEL Output: DDR3 PLL Setup ...
A15_0: GEL Output: DDR3 PLL Setup complete, DDR3A clock now running at 400MHz.
A15_0: GEL Output: DDR3A initialization complete

Connect with a SD card boot image

Launch CCS and create new target configuration(File->New->Target Configuration file) as shown in the images below

../_images/CCS_target_configuration.png

Provide appropriate name to the configuration. Select Spectrum digital XDS200 emulator and target as 66AK2G02.

Note: If you don`t find the 66AK2G02 target make sure you have installed the CCSv6.1.3 package or for CCSv6.1.2 and earlier ensure that you have done the software update correctly as shown in the how to section below.

../_images/K2G_GPEVM_Target_configuration_alternate.jpg

In advance settings, make sure that the no gel files are populated.

Step2: 66AK2G02 GP EVM contains boot switches to configure for “SD/MMC boot” mode. So configure the boot switches to SD/MMC boot Mode as described in the SettingBootSwitches

Step3: Connect an XDS200 Emulator to XDS USB of the GP EVM as shown in section ConnectingEmulator

Step4: Launch CCS and create new target configuration as discussed in the previous section ConfiguringTargetConfigFile

Step5: Launch Target configuration you just created.

../_images/K2G_Launch_targetConfig.png

Step6:K2G will boot with ARM master boot from the SD card so connect to the A15_0. There will be no output on the console when you connect to the core.

Step7 SD card boot image will typically load a secondary bootloader like u-boot that will put the DSP in reset so user will need to follow the instructions on the page that talks about Taking DSP out of reset

Note: RTOS users don`t need to follow this step as the Secondary bootloader (SBL) will put the DSP in idle state and not in reset if there is no code running on the DSP.

How to guide

This section guides users who are using older versions of the GP EVM which may require an update to the firmware flashed on the EVM or hardware updates to workaround specific issues. Each section specifies the affected versions and the fix for the issue.

Create SD card to boot Linux on the GP EVM

All pre-production boards (Rev C and earlier) will not contain a SD card image in the kit without an image flashed on it for the Out of Box experience described in the Quick start guide. User are required to download the image seperately from the Processor SDK Linux portal and run a script to create the SD boot image. The steps to create the image are provided below:

Step 1 Download the image k2g-evm-linux-xx.xx.xx.xx.img.zip from the link Latest Processor SDK Linux

Step 2 Follow instructions to create a SD card for the EVM using the instruction in the SD Card Creation Guide

Update the BMC firmware on the EVM

The section describes how the Board Management controller firmware on the board can be updated through the BMC UART interface. All boards prior to RevC, require a BMC update for the following issue:

  • CDCM chip on the board generates clocks to modules like PCIe and USB. It is possible to use PCIe only in external clock mode on the EVM. However there can be use-cases where PCIe clock should be enabled with SoC running in internal clock mode.

Step 1 Install the LM flash programmer from link provided below:

Step 2 Obtain latest BMC software for the K2G GP EVM can be obtained from the board manufacturer or from local TI contact. Production EVMs are shipped with latest BMC version 0.6.1.0. You can check the version of the BMC software by observing the version indicated on BMC LCD on the GP EVM after power up.

Step 3 Connect the mini USB cable between host PC and ‘USB to SoC UART0’ port (J23) on EVM

Step 4 Remove the jumper J10 and power on the K2G EVM

Step 5 Open the LM Flash programmer utility on the windows host machine.

Step 6 In the LM Flash Programmer Utility ‘Configuration’ tab, in the interface section, select ‘Serial (UART)’ from the drop-down box on the left.Refer to the image provided below:

../_images/LMflashProg_Config.png

Step 7 Select the BMC COM Port and set the ‘Baud Rate’ to 115200.

  • There will be two COM ports that appears on EVMs ‘USB to SoC UART0’ port. Select the one which is connected to BMC. To find which port corresponds to the BMC, you can open a serial terminal program or Device Manager on your PC and check the port number corresponding to “Silicon Labs CP210x: USB to UART Bridge: Standard COM Port (COM##)” as shown below:
../_images/BMCUARTPort.png

Note: BMC outputs boot logs to serial console when EVM is powered ON. Connect the ‘USB to SoC UART0’ port to standard serial console application to find the right COM port that is connected to BMC.

Step 8 Set ‘Transfer Size’ to 60, and make sure ‘Disable Auto Baud Support’ is unchecked.

Step 9 In the ‘Program’ tab, select the binary image file bmc_evmKS2_K2G.bin in the section ‘Select.bin file’.

../_images/LMflashProg_program.png

Step 10 Leave all other options as default, and press the ‘Program’ button.

Step 11 Wait till ‘Program Complete’ status in the status bar.

Step 12 Connect the jumper J10 and reboot the EVM

Update XDS200 firmware and hardware components on the GP EVM

Note: This update is only required if you are using the on board XDS200 debug probe.

The RevB and RevC boards are using an earlier version of the XDS200 firmware. We have observed the following issues when hooking up the internal XDS200 USB debug probe to a host machine.

  • XDS200 Emulator USB cable need to be re-plugged every time board is power cycled/reset to avoid leakage on power supply VCC1V8_XDS which can damage the regulator or other ICs

Workaround for this issue

  • Use external emulators with the MIPI 60 adapter included int he kit.
  • Perform following firmware and hardware updates to the GP EVM (RevC and earlier)

Software Update Required

Steps to update the XDS200 firmware on the EVM are archived on the article Updating_the_XDS200_firmware

Hardware updates required

  • Replace R431 & R442 to 200E
  • Mount resistors R95, R107, R108, R115.
  • Mount D2, R600, R599 components.
  • Remove FB3 and connect a wire from R64.2 ‘rVCC_VBUS_XDS’ and R67.2 ‘VCC5V0_DCDC’ as shown in the image below:
../_images/R64_to_R67_HWMod.png

Update the EVM for improved USB performance

The external resistors for the USB (R442 and R431) are currently 10k Ω. We recommend that users need to replace these with 200 Ω / 1%.



Useful Resources and Support

10.3.5. 66AK2G02 ICE EVM Hardware Setup

10.3.5.1. Description

The K2G ICE EVM is a high performance, cost-efficient, standalone development platform that enables users to evaluate and develop industrial communications applications for the Texas Instrument’s Keystone2 System-on-Chip (SoC) 66AK2G02. The K2G SOC (66AK2G02) is the new device from TI’s Keystone II architecture with

  • ARM® Cortex® -A15 Microprocessor Unit (ARM A15) Subsystem at up to 600MHz
  • C66x Fixed- and Floating-Point VLIW DSP Subsystem at up to 600MHz
  • Two Programmable Real-Time Unit and Industrial Communication Subsystems (PRU-ICSS)
  • Multicore Shared Memory Controller (MSMC) with 1024KB of Shared L2 RAM
  • Up to 36-Bit DDR3 External Memory Interface (EMIF) with ECC (32-Bit Data + 4-Bit ECC)
  • PCI-Express® 2.0 Port with Integrated PHY
  • Three Multichannel Audio Serial Port (McASP) Peripherals
  • Multichannel Buffered Serial Port (McBSP)
  • Six Enhanced High Resolution Pulse Width Modulation (eHRPWM)

The key features of the EVM are:

  • K2G SoC 66AK2G02 is based on keystone II architecture with ARM cortex A15 @600MHz and C66x DSP @600MHz
  • 515MByte of DDR3L
  • 512Mbit of QSPI Flash
  • 128kByte of I2C EEPROM
  • Micro SD-Card slot
  • Gigabit Ethernet port supporting 10/100/1000 Mbps data rate on RJ45 connector
  • 4x 10/100 Industrial Ethernet connectors
  • PCIe x1 card edge connector
  • LCD display
  • Expansion connector for customer designs
  • XDS100 Emulator and UART over mini-USB connector
  • 20-Pin JTAG header to support all types of external emulator
  • RoHS compliant design
  • Powered by DC power-wall adaptor (24V/2.5A) or PCIE Edge Connector

10.3.5.2. EVM Layout and Key Components

../_images/TI_K2G_ICE_EVM_TOP.png ../_images/TI_K2G_ICE_EVM_BOTTOM.png

10.3.5.3. Supported JTAG Debug Probes (Emulators)

  • XDS100-class JTAG debug probes (low cost, low performance). The XDS100v1 is not supported.
  • XDS200-class JTAG debug probes (recommended)
  • XDS560v2-class JTAG debug probes (high performance)

10.3.5.4. Minimal EVM setup

10.3.5.4.1. Setting Boot Switches

The DIP switch (SW3) is used for selecting the boot mode.

For the EVM Out-of-Box experience, use SD/MMC boot mode as shown in the image below:

../_images/K2GICE_Boot_MODE.png

The table below lists all of the boot modes supported on the ICE EVM.

../_images/K2G_ICE_BOOTSW.png

10.3.5.4.2. Connecting an Emulator

Note

This EVM setup is only required for developers who need to connect to cores using Code Composer Studio (CCS) to load their application.

The EVM supports two types of emulation via the on-board XDS100 emulator or the 20-pin JTAG header.

When an external emulator is not connected to the 20-pin JTAG Header, the on-board XDS100 embedded JTAG emulator is the default type of emulation (SoC JTAG signals are routed to the XDS100 on-board emulator). When an external emulator is connected to the 20-pin JTAG Header, it is automatically detected and the SoC JTAG signals are routed to the external emulator.

On-board XDS100 Emulator

The K2G ICE EVM has on-board XDS100 embedded JTAG emulation circuitry so an external emulator is not required. Users can connect to the target SoC via CCS by connecting the USB cable, supplied in the ICE EVM kit, as shown in the image below.


../_images/ICE_K2G_connect.png

20-pin JTAG Header for Connecting an External Emulator

Users have the option of connecting an external at the 20-pin JTAG Header connector (EMU1). The 20-pin JTAG Header is provided on-board for high speed real-time emulation. All JTAG and EMUxx signals are terminated on 20-pin JTAG Header.

10.3.5.4.3. Powering Up the EVM

Power Supply Specifications

The K2G ICE EVM can be powered from one of two sources. A single +24V / 2.5A DC (60W) external power supply connected to the DC power jack (J6). In addition, the K2G ICE EVM can be powered from the 12V supply pins on the PCIE edge connector. A power ANDing circuit is included in the design which will prevent damage if the +24V is connected while the board is installed on a PCIE backplane. The +24V supply will supply the power for the board in that condition.

10.3.5.5. CCS Setup

This section describes the setup to connect to 66AK2G02 ICE EVM using Code composer Studio environment and an emulator.

There are two scenarios while connecting to the EVM :

  • Connect to EVM without a SD card boot image to boot the EVM
  • Connect to EVM after booting an image from the SD card.

Note

Keystone II device support package in CCSv7.1 includes the support for K2G ICE board but CCSv7.0/ CCSv6 users may need to update the device support package as described in the section “Update CCS to Install Keystone II Device Support Package.”


10.3.5.5.1. Update CCS to Install Keystone II Device Support Package

All revisions of the board require this step to be performed in order to get the latest GEL files and the target content for the K2G if you are using CCSv7.0 and earlier. This step will not be required for CCS versions higher than version 7.1. CCSv7.0 or CCSv6.1.3 package contain KeystoneII device support package v1.1.6 which doesn’t contain K2GICE specific target files hence we recommend this update.

1. All CCS v6.1.3 or CCSv7.0 and earlier version users are required to update the Keystone Device Support package by going into the Help->Check For Updates

../_images/Check_for_Updates.png

2. Select Keystone2 device support package. Follow menu options to continue with the update.

3. After the update is complete go to Help->Installation details and check that Keystone2 device support package v1.1.9 or later are installed as shown below.

../_images/KeystoneII_device_support_package.png

Note

The package can be downloaded separately from the link below and manually unzipped into CCS installation.

Note

For K2G Devices, if using CCS v6.1.2 and Keystone2 device support v1.1.7, 66AK2G02 would not show up in the list of devices when creating the target configuration. This is due to an incompatibility in the XML parser in CCS v6.1.2 with the K2G device xml. In order to work-around this issue, make the change in 66AK2G02.xml as illustrated below in order to have 66AK2G02 display in the device list. This problem does not exist in CCS v6.1.3 onwards as the XML parser has been updated.

C:\ti\ccsv6\ccs_base\common\targetdb\devices\66AK2G02.xml

Line #1

<?xml version="1.1" encoding="UTF-8" standalone="no"?>

to

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

10.3.5.5.2. Connect without an SD Card Boot Image

Configuring target configuration files

Launch CCS and create a new target configuration (File->New->Target Configuration file) as shown in the images below.

../_images/CCS_target_configuration.png

Provide an appropriate name to the configuration. Select Spectrum Digital XDS100 emulator and target as K2G ICE EVM.

Note

If you don’t find the K2GICE target make sure you have installed CCSv7.1 or higher. If using CCSv 7.0 or CCSv6.1.x and earlier, ensure that you have done the software update correctly as shown in the how to section below.

../_images/K2G_ICE_target_configuration.png

In advanced settings, make sure that the GEL files are populated correctly. The following GEL files and their corresponding cores are provided below.

  • C66X Core: icek2g.gel
  • A15 Core: icek2g_arm.gel

Connecting to target

1. Download Code composer Studio or for CCSv7.0 and earlier, ensure it contains Keystone device support package version 1.1.9 as described in the how to guide “Update CCS to Install Keystone II Device Support Package.”

2. 66AK2G02 ICE EVM contains boot switches to configure for “No boot/sleep” mode. So configure the boot switches to “No Boot Mode” as described in the “Setting Boot Switches” section.

3. Connect an XDS100 Emulator to the XDS USB port of the ICE EVM as shown in the section “Connecting Emulator.”

4. Launch CCS and create a new target configuration as discussed in the previous section “Configuring target configuration files.”

5. Launch the newly created target configuration.

../_images/K2G_Launch_targetConfig.png

6. K2G can be a DSP or an ARM master boot device so connect to the C66x or the A15_0.

GEL Log

A15_0: GEL Output: PLL has been configured (24.0 MHz * 100 / 1 / 4 = 600.0 MHz)
A15_0: GEL Output: ARM PLL has been configured with ref clock 24MHz, -sysclkp_period 41.6666 (24.0 MHz * 100 / 1 / 4 = 600.0 MHz)
A15_0: GEL Output: Power on all PSC modules and DSP domains...
A15_0: GEL Output: Power on PCIE PSC modules and DSP domains... Done.
A15_0: GEL Output: UART PLL has been configured (24.0 MHz * 128 / 1 / 8 = 384.0 MHz)
A15_0: GEL Output: NSS PLL has been configured (24.0 MHz * 250 / 3 / 2 = 1000.0 MHz)
A15_0: GEL Output: ICSS PLL has been configured (24.0 MHz * 250 / 3 / 10 = 200.0 MHz)
A15_0: GEL Output: DSS PLL has been configured (24.0 MHz * 198 / 12 / 16 = 24.75 MHz)
A15_0: GEL Output: DDR PLL has been configured (24.0 MHz * 250 / 3 / 10 = 200.0 MHz)
A15_0: GEL Output: XMC setup complete. A15_0: GEL Output: DDR3 PLL Setup ...
A15_0: GEL Output: DDR3 PLL Setup complete, DDR3A clock now running at 400MHz.
A15_0: GEL Output: DDR3A initialization complete

10.3.5.5.3. Connect with an SD Card Boot Image

1. Launch CCS and create a new target configuration (File->New->Target Configuration file) as shown in the images below.

../_images/CCS_target_configuration.png

Provide an appropriate name to the configuration. Select Spectrum digital XDS100 emulator and target as 66AK2G02.

Note

If you don’t find the K2GICE target make sure you have installed CCSv7.1 or higher. If using CCSv 7.0 or CCSv6.1.x and earlier, ensure that you have done the software update correctly as shown in the how to section below.

../_images/K2G_GPEVM_Target_configuration_alternate.jpg

In advanced settings, make sure that no GEL files are populated.

2. 66AK2G02 GP EVM contains boot switches to configure for “SD/MMC boot” mode. So configure the boot switches to “SD/MMC Boot” as described in the section “Setting Boot Switches.”

3. Connect an XDS100 Emulator to the XDS USB port of the GP EVM as shown in the section “Connecting Emulator.”

4. Launch CCS and create a new target configuration as discussed in the previous section “Configuring target configuration files”.

5. Launch the newly created target configuration.

../_images/K2G_Launch_targetConfig.png

6. K2G will boot with ARM master boot from the SD card so connect to the A15_0. There will be no output on the console when you connect to the core.

7. SD card boot image will typically load a secondary bootloader like u-boot that will put the DSP in reset so users will need to follow the instructions in the guide How to take the C66x DSP out of reset with Linux running on A15

Note

RTOS users do not need to follow this step as the Secondary Bootloader (SBL) will put the DSP in idle state and not in reset if there is no code running on the DSP.

10.3.6. EVMK2E Hardware Setup Guide

10.3.6.1. Hardware Setup

Note

The EVM board is sensitive to electrostatic discharges (ESD). Use a grounding strap or other device to prevent damaging the board. Be sure to connect communication cables before applying power to any equipment.

10.3.6.1.1. Attach the Ethernet cable

Using the Ethernet cable supplied, connect one end of the cable to the Ethernet Port 0 (At bottom one) on the EVM and the other end to your PC. The below picture shows which Ethernet Port is port 0:

../_images/Evmk2e-image001.jpg

10.3.6.1.2. Connect the JTAG interface

Use the USB to USB mini-B cable provided. Connect the USB mini-B connector to the USB mini-B interface near to the RST_PWR1 (Red color) button on the EVM, and the USB connector to your PC. This enables XDS-2xx emulation and is directly useable by CCS. If you are using a different JTAG, you can connect it at MIPI60 connector (EMU1).

10.3.6.1.3. K2E Set the boot mode switch SW1

K2E SPI Little Endian Boot mode (Default factory setting)

MSB                         LSB
SW1 - 1(OFF) 2(OFF) 3(ON) 4(OFF)
../_images/Evmk2e-image002.jpg

Note

Here a switch on “ON” position should be considered as “1”.

K2E No Boot/JTAG DSP Little Endian Boot mode

MSB                      LSB
SW1 - 1(ON) 2(ON) 3(ON) 4(ON)
../_images/Evmk2e-image003.jpg

10.3.6.1.4. Attach the serial port cable to the SoC UART port

Connect the SoC UART port to PC using the serial cable provided with the EVM. The SoC UART port is the 4-pin white connector COM1 of the EVM.

Start TeraTerm or HyperTerminal and set configuration to

  • Baud Rate or Bits per second: 115200
  • Data Bits: 8
  • Parity: None
  • Stop Bits: 1
  • Flow Control: None

10.3.6.1.5. Connect the power cable

Connect the power cable to the EVM power jack on the board. To be ESD safe, plug in the other end of the power cable only after you have connected the power cord to the board. Then turn on the board.

10.3.6.2. DIP Switch and Bootmode Configurations

EVM SW1 switch Bootmode Configuration

The table below shows the bootmode combinations for the BMC v1.1.0.x. and value selected from internal flash memory of LM3s2d93.

DIP Switch settings Selected High_value of that bootmode Low_value of that bootmode Selected bootmode
0000 0x00000000 0x00010067 ARM NAND
0001 0X00000000 0x00100001 DSP No Boot
0010 0x00000000 0x00008005 ARM SPI
0011 0x00000000 0x00100003 ARM I2C Master
0100 0x00000000 0x0000006F ARM UART Master
0101 0x00000000 0x0001506B ARM RBL EthNet
0110 0x00000000 0x00001061 Sleep with Max PLL and ARM Bypass
0111 0x00000000 0x00001061 Sleep with Max PLL
1000 0x00000000 0x00010167 DSP NAND
1001 0x00000000 0x00001061 Sleep with Slow PLL and ARM Bypass
1010 0x00000000 0x00008105 DSP SPI-boot
1011 0x00000000 0x00100103 ARM I2C Master
1100 0x00000000 0x0000016F DSP UART boot
1101 0x00000000 0x0001516B DSP RBL ENET
1110 0x00000000 0x00003661 Sleep with Slow PLL and Slow ARM PLL
1111 0x00000000 0x00100001 DSP No-Boot

10.3.6.3. EVM K2E How To Guides

10.3.6.3.1. Host driver for on-board mini-USB connector

The K2E EVM has a CP2105 device on-board. A driver must be installed on the host PC in order to be able to communicate with the EVM using the CP2105 mini-USB connector located at the corner edge of the EVM. The driver can be downloaded from CP2105 driver download.

Both Linux and Windows host machine drivers can be downloaded from this page. For Linux host machine, please follow the instructions given in the release notes. There are two versions of drivers for Linux kernel version 3.x.x and 2.6.x. Please download appropriate drivers after identifying the correct kernel version of the user’s host machine.

Note

Before testing the USB connection, make sure that the mini-USB cable is plugged into the port on the base board.

After installing the driver and connecting the USB cable, two COM ports should be visible in the list of COM ports available to connect to in the PC Host terminal console. The lower COM port (Enhanced) corresponds to the SoC UART and the higher (Standard) one corresponds to the MCU UART.

10.3.6.3.2. BMC Version Check and Update

BMC, or Board Management Controller, takes care of the power, clocks, resets, bootmodes, etc. of the EVM.

You can check the version by:

  1. Opening a hyperterminal or another similar type of console application.
  2. Set COM Port to higher value.
    • When you connect to CP2105 mini-USB on the EVM it will provide two COM port connections, one to the SOC UART and one to BMC UART.
    • The SOC UART will always be the “Enhanced” COM port, for example COM6 (actual COM PORT values will vary.)
  3. Set COM port properties appropriately:
    • Baud Rate or Bits per second: 115200
    • Data Bits: 8
    • Parity: None
    • Stop Bits: 1
    • Flow Control: None
  4. At BMC prompt type ‘ver’ (no quotes).
  5. Check BMC version
../_images/Evmk2e-image005.jpg

If an in-field update is needed, downloaded the latest version here (labeled “BMC”) and follow instructions below.

10.3.6.3.2.1. Prepare EVM for in-field update
  1. Remove power to the EVM.
  2. Set boot mode to “No Boot mode” (see above).
  3. Remove the MCU_BOOTSELECT (CN4) jumper (see picture below for location of jumper.)
  4. Make sure your
    • USB cable is connected to CP2105 mini-USB (not XDS200 Emulator USB) or
    • Connect 4pin UART cable to COM1: MCU UART connector
  5. Make sure no HyperTerminal/Console connected to BMC COM port are open or active.
  6. Use the LM Flash Programmer (available here) to update the firmware, as detailed in the steps below.
../_images/Evmk2e-image006.jpg
10.3.6.3.2.2. Perform in-field update
  1. Apply power to the EVM. No LED’s will be illuminated and no LCD backlight or characters will be on because the BMC is waiting for a command rather than executing from Flash.
  2. Open the LM Flash programmer utility. (Default location Start Menu -> All Programs -> Texas Instruments -> Stellaris -> LM Flash Programmer -> LM Flash Programmer )
  3. In the LM Flash Programmer Utility ‘Configuration’ tab, in the interface section, select ‘Serial (UART)’ from the drop-down box on the left.
  4. Select the BMC COM Port (the same COM port used to issue the ver command earlier), and set the ‘Baud Rate’ to 115200.
  5. Set ‘Transfer Size’ to 60, and make sure ‘Disable Auto Baud Support’ is unchecked. See image below.
  6. In the ‘Program’ tab, Browse to the location of the binary file containing the firmware update, and select it.
  7. Leave all other options as default, and press the ‘Program’ button.
  8. After the programming is complete, power off the board.
  9. Reconnect the jumper.
  10. Open the HyperTerminal/Console for the BMC COM port.
  11. Apply power to the EVM. When BMC completes initialization of board it will show latest version of BMC in Console.
  12. If step 9 was done after power was applied, just type “ver” at BMC prompt.
../_images/Evmk2e-image007.jpg

10.3.6.3.3. UCD Power Management Update

There is one power management module (a.k.a. UCD) located on the EVM. It can be identified by its address: 104(68h). Each module contains non-volatile registers that determine its operation. It may be necessary to update these registers in the field after the board has been shipped.

This update can be performed through the BMC, which can issue commands to the UCD modules to update the register settings. The Power Management Configuration Update Tool performs the task of sending commands to the BMC to get the current module versions, and perform updates using configuration files.

The latest version of the tool is available from here along with instructions on using the tool, and the latest configuration files (txt files). Please follow the instructions provided to check the current module versions, and update them accordingly.

Note

The DIP switch configuration of the board when running the update is irrelevant.

10.3.7. EVMK2H Hardware Setup Guide

10.3.7.1. Hardware Setup

Note

The EVM board is sensitive to electrostatic discharges (ESD). Use a grounding strap or other device to prevent damaging the board. Be sure to connect communication cables before applying power to any equipment.

10.3.7.1.1. FTDI Driver Installation on PC Host

The K2 EVM has a FTDI FT2332HL device on board. A driver must be installed on the PC Host in order to be able to communicate with the EVM using the FTDI mini-USB connector located under the mini-USB connector of the emulator daughter card. The driver can be downloaded from here FTDI Driver.

Note

Before testing the usb connection, make sure that the mini-usb cable is plugged into the port on the base board. (and not connected to the daughter card).

After installing the driver and connecting the USB cable, two COM ports should be visible in the list of COM ports available to connect to in the PC Host terminal console. The lower COM port corresponds to the SoC UART and the higher one corresponds to the MCU UART.

10.3.7.1.2. BMC Version Check and Update

Read BMC_In-Field_Update to check BMC version and update if necessary.

10.3.7.1.3. UCD Power Management Modules In-Field Update

There are three power management modules (sometimes called the UCDs) located on the EVM. Each module can be identified by it’s address: 104(68h), 52(34h), and 78(4Eh). Each module contains non-volatile registers that determine it’s operation. It may be necessary to update these registers after the board has been shipped. This update can be performed through the BMC, which can issue commands to the UCD modules to update the register settings. The Power Management Configuration Update Tool (bmc_tool.py) performs the task of sending commands to the BMC to get the current module versions, and perform updates using configuration files. Instructions for executing the update tool (bmc_tool.py) are available here: BMC Tool UCD Update Guide

The latest version of the tool is available here. The latest configuration files (txt files) are available here. Please follow the instructions provided to check the current module versions, and update them accordingly.

Note

The DIP switch configuration of the board when running the update is irrelevant.

Note

BMC versions 1.0.1.3a and earlier will not work properly with the Get Versions feature of the Update Tool. Upgrade to a more recent version of the BMC to use this functionality.



10.3.7.1.4. Attach the Ethernet cable

Using the Ethernet cable supplied, connect one end of the cable to the Ethernet Port 0 (marked ENET0 on the board) on the EVM and the other end to your PC.

This picture shows which Ethernet Port is 0:

../_images/K2H_ENET0.jpg

10.3.7.1.5. Connect the JTAG interface

Use the USB to USB mini-B cable provided. Connect the USB mini-B connector to the USB mini-B interface on the XDS-2xx daughter card on the EVM, and the USB connector to your PC. This enables XDS-2xx emulation and is directly useable by CCS. If you are using a different JTAG, connect it now.

10.3.7.1.6. K2H Set the boot mode switch SW1

K2H No Boot/JTAG DSP Little Endian Boot mode

For Rev 0B EVM, the setting is as follows

SW1 - 4(ON) 3(ON) 2(ON) 1(OFF)

For Rev 1.0 EVM, the setting is as follows:

SW1 - 1(OFF) 2(OFF) 3(OFF) 4(ON)

K2H SPI Little Endian Boot mode

For Rev 0B EVM, the setting is as follows:

SW1 - 4(ON) 3(ON) 2(OFF) 1(ON)

For Rev 1.0 EVM, the setting is as follows:

SW1 - 1(OFF) 2(OFF) 3(ON) 4(OFF)

10.3.7.1.7. DDR Configuration (Rev 0B EVM only)

For Rev 0B EVM, the following procedure is required for proper DDR configuration:

  • Connect the MCU UART port to PC using the serial cable provided with the EVM. The MCU UART port is the 4-pin white connector farthest from the edge of the EVM. Alternatively it is also possible to connect a mini-USB cable to the FTDI mini-USB connector of the EVM. This will provide access to both the SoC and the MCU UART ports.
  • Start Tera Term or Hyper terminal and set to 115200 board rate, 8-bit data, 1-bit stop and no parity/flow control.
  • Power on the EVM. MCU UART console will show user prompt once MCU boot up is complete. Type the following commands at the console to setup DDR3A. Ethernet requires DDR3A and will not work with DDR3B which is default in Rev 0B EVMs.
BMC> setboot 100001
BMC> fullrst

10.3.7.1.8. Attach the serial port cable to the SoC UART port

Connect the SoC UART port to PC using the serial cable provided with the EVM. The SoC UART port is the 4-pin white connector closest to the edge of the EVM.

Start Tera Term or Hyper terminal and set to 115200 board rate, 8-bit data, 1-bit stop and no parity/flow control.

10.3.7.1.9. Connect the power cable

Connect the power cable to the EVM power jack on the board. To be ESD safe, plug in the other end of the power cable only after you have connected the power cord to the board. Then turn on the board.

10.3.7.2. BMC In-Field Update

BMC, or Board Management Controller, takes care of the power, clocks, resets, bootmodes, etc. of the EVM.

For Rev1.0 EVMs an in-field update may be necessary as a very small quantity were delivered with an old revision of the BMC. If your EVM is using version 1.0.1.3 then it should be updated to version 1.0.1.3a. The update corrects the way that the boot mode pins are interpreted.

You can check the version by:

1. Opening a hyperterminal or another similar type of console application.

2. Set COM Port to higher value

  • When you connect to FTDI mini-USB on the EVM it will provide 2 COM port connections, one to the SOC UART and one to BMC UART.
  • The SOC UART will always be the lowest value COM port, for example COM5, and the BMC UART will always be the higher value COM port, for example COM6. (Actual COM PORT values will vary).

3. Set COM port properties appopriately:

  • Baud Rate or Bits per second: 115200
  • Data Bits: 8
  • Parity: None
  • Stop Bits: 1
  • Flow Control: None

4. At BMC prompt typer ‘ver’ (no quotes)

5. Check BMC Version


../_images/Bmc_ver_screenshot.JPG


If an in-field update is needed, downloaded the latest version here (labeled Board Management Controller Binaries (BMC)) and continue with the following steps.


Prepare EVM for in-field update:

  1. Remove power to the EVM.
  2. Set boot mode to “No Boot mode” ( See NoBootLittleEndian_ )
  3. Remove the MCU_BOOTSELECT (CN9) jumper (see picture below for location of jumper: Referred as “G: MCU Reset Jumper for BMC field update”).
  4. Make sure your USB cable is connected to FTDI mini-USB (not XDS200 Emulator USB) OR connect 4pin UART cable to COM1: MCU UART connector.
  5. Make sure no HyperTerminal/Console connected to BMC COM port are open or active.
  6. Use the LM Flash Programmer (available here) to update the firmware, as detailed in the steps below.

Perform in-field update:

  1. Apply power to the EVM. No LED’s will be illuminated and no LCD backlight or characters will be on because the BMC is waiting for a command rather than executing from Flash.

  2. Open the LM Flash programmer utility. (Default location Start Menu -> All Programs -> Texas Instruments -> Stellaris -> LM Flash Programmer -> LM Flash Programmer )

  3. In the LM Flash Programmer Utility ‘Configuration’ tab, in the interface section, select ‘Serial (UART)’ from the drop-down box on the left.

  4. Select the BMC COM Port (the same COM port used to issue the ver command earlier), and set the ‘Baud Rate’ to 115200.

  5. Set ‘Transfer Size’ to 60, and make sure ‘Disable Auto Baud Support’ is unchecked.

    ../_images/LMflashProg_Config.png
  6. In the ‘Program’ tab, Browse to the location of the binary file containing the firmware update, and select it.

  7. Leave all other options as default, and press the ‘Program’ button.

  8. After the programming is complete, power off the board.

  9. Reconnect the jumper.

  10. Open the HyperTerminal/Console for the BMC COM port.

  11. Apply power to the EVM. When BMC completes initialization of board it will show latest version of BMC in Console.

  12. If step 9 was done after power was applied, just type “ver” at BMC prompt.

../_images/K2EVM.jpg

10.3.7.3. DIP Switch and Bootmode Configurations

10.3.7.3.1. Rev 1.0 EVM SW1 switch Bootmode Configuration

The table below shows the bootmode combinations for the BMC v1.0.1.3a.
DIP Switch (p1, p2, p3, p4) Bootmode
0000 ARM NAND
0001 DSP no-boot
0010 ARM SPI
0011 ARM I2C
0100 ARM UART
0101 Reserved
0110 Reserved
0111 Reserved
1000 Reserved
1001 Reserved[1]
1010 Reserved
1011 Reserved
1100 Reserved
1101 Reserved
1110 Reserved
1111 Reserved

[1]In revision BMC v1.0.1.4 this is 10 MHz SPI NOR. This will not continue in future versions.

10.3.7.3.2. Changing the Bootmode

In BMC v1.0.1.x the only way to use a bootmode that is not supported by the DIP switch combinations is to use the ‘setboot’ and ‘fullrst’ commands. To set the bootmode use the setboot command, which takes a 32 bit value in hex as its only argument:

setboot 00110CE7

Then use the fullrst command to boot the SoC into this bootmode:

fullrst

This process is volatile, and will have to be repeated every time the board is power cycled.

In BMC v1.0.2.x the setboot command has been removed. It has been replaced with the bootmode command, which performs various functions depending on the way in which the command is used. The command works with 16 bootmodes, which are representative of the various DIP switch combinations; the bootmodes are numbered 0 - 15. Bootmodes 8 - 15 are User-Defined, and may be altered and stored using the command (explained below). Each bootmode consists of a title, a high value, and a low value. The high value is currently not used. The low value is a 32 bit value in hex, and is the same as the value previously used by setboot. The bits of low value (and the setboot argument) are shown in the table below).

Bit Devstat Bit Config Pin Function Normal Pin Function Comments
31       Reserved
30       Reserved
29       Reserved
28       Reserved
27       Reserved
26       Reserved
25   PACLKSEL PACLKSEL  
24   CORECLKSEL CORECLKSEL  
23       Reserved
22   AVSIFSEL1 TIMI1 Reserved: EVM forces these bits to strap values during reset
21   AVSIFSEL0 TIMI0 Reserved: EVM forces these bits to strap values during reset
20   DDR3_REMAP_EN GPIO16  
19   ARM_LENDIAN GPIO15 0 = little, 1 = is not supported; do in SW
18   MAINPLLODSEL CORESEL3  
17   ARMAVSSHARED CORESEL2  
16 16 BOOTMODE15 CORESEL2  
15 15 BOOTMODE14 CORESEL1 Element
14 14 BOOTMODE13 CORESEL0  
13 13 BOOTMODE12 GPIO13  
12 12 BOOTMODE11 GPIO12  
11 11 BOOTMODE10 GPIO11  
10 10 BOOTMODE9 GPIO10  
9 9 BOOTMODE8 GPIO9  
8 8 BOOTMODE7 GPIO8  
7 7 BOOTMODE6 GPIO7  
6 6 BOOTMODE5 GPIO6  
5 5 BOOTMODE4 GPIO5  
4 4 BOOTMODE3 GPIO4  
3 3 BOOTMODE2 GPIO3  
2 2 BOOTMODE1 GPIO2  
1 1 BOOTMODE0 GPIO1  
0 0 LENDIAN GPIO0  

There are 5 different formats to the bootmode command:

bootmode

When the command is entered with no arguments the current bootmode will be displayed.

bootmode all

This format will display all 16 bootmodes and mark the currently selected bootmode.

bootmode #x

This will change the currently selected bootmode to the bootmode represented by x. For example, if the board is booted with DIP switch setting 1(OFF) 2(OFF) 3(OFF) 4(ON) then the bootmode would be 1 - DSP NO-BOOT. If ‘bootmode #2’ is entered, the bootmode represented by DIP switch setting 1(OFF) 2(OFF) 3(ON) 4(OFF) would become the current bootmode (ARM SPI-NOR BOOT). If the ‘reboot’ command is given, the SoC will be rebooted using this new bootmode. This format is volatile, meaning once power is removed, the bootmode at the next power up will be determined by the DIP switch.

bootmode read

This format reads the current value of the DIP switch, and changes the current bootmode to this value. For example, if the board is booted with DIP switch setting 1(OFF) 2(OFF) 3(OFF) 4(ON) then the bootmode would be 1 - DSP NO-BOOT. If the DIP switch is changed to 1(OFF) 2(OFF) 3(ON) 4(OFF) and then the command ‘bootmode read’ is given, the board will change to bootmode 2 - ARM SPI-NOR BOOT. If the ‘reboot command is then given, the SoC will be rebooted using this new bootmode.

bootmode [#]x hi_value lo_value title

This bootmode is used to alter User-Defined bootmodes (bootmodes 8 - 15). x is the index of the bootmode to be set, as such its appropriate value range is 8 - 15, any other value will return an error. hi_value is not currently used, and should always be set to 0. lo_value is a 32 bit hex value whose bits are representative of the table above. title is a given string that is displayed by the bootmode command to help better understand what the bootmode does, it has no purpose within the actual booting of the board. The option ‘#’ is used to determine whether the bootmode will be saved. If # is used, the bootmode will be saved to flash, meaning the new value is tied to the DIP switch, and will remain even if power is removed from the board. If # is not given, then the change will be lost as soon as power is removed. Some examples with descriptions are given below:

bootmode 8 0 112005 ARM_SPI

bootmode 8 will be set to 112005 and given the title ARM_SPI. To boot into this bootmode, the command ‘bootmode #8’ followed by ‘reboot’ would be given (or changing the DIP switch to 1(ON) 2(OFF) 3(OFF) 4(OFF) without removing power, then entering ‘bootmode read’ followed by ‘reboot’). Once power is removed, this change is lost.

bootmode #10 0 12cba1 RANDOM_BOOT

bootmode 10 will be set to 12cba1 and given the title RANDOM_BOOT. This is now the permanent value of bootmode 10; the change will persist even if power is removed.

10.3.7.4. Connect to EVMK2H using CCS

Step 1: Configure the EVM hardware

  • Setup the EVM to DSP no boot using SW1 as described in the section BootModeConfiguration
  • Connect mini USB cable to the XDS2xx MIPI adapter card marked J1 or connect external emulator to the MIPI connector on J3

Note

For newer versions of CCS, a XDS200 firmware update is recommended which user can perform using instruction on the article

below:

Note

For newer versions of CCS, a XDS200 firmware update is recommended which user can perform using instruction on

Updating_the_XDS200_firmware <http://dev.ti.com/tirex/explore/node?node=AADzJ8Y-La4f7Bi5Ga0TcA__FUz-xrs__LATEST>__

Step 2: Create CCS Target configuration

Launch CCS on your host machine. Select View Tab and select the “Target configuration”

../_images/New_TargetConfig.png

Create New Target configuration in CCS by selecting appropriate emulator. For Default on board emulator select “Texas instruments XDS2xx Debug Probe” and select the target device as 66AK2H12.

../_images/K2H_TargetConfig.png

Go to the Advanced Tab where you will see all the cores on the SOC listed. In order to initialize the clocks and external DDR memory on the device, users are required to use a initialization Gel scripts. To populate the Gel Select A15_0 and then hit Browse and locate the GEL in the CCS installation under the following path: CCS_INSTALL/ccs_base/emulation/boards/xtcievmk2x/gel

../_images/ARM_GEL.png

DSP developers, can also select C66x_0 and populate the DSP GEL file that is found in the same location.

../_images/DSP_GEL.png

Going back to the Basic Tab, Save the configuration. For additional sanity check, you can also test connection.


Step 3: Connect to the cores

Right click on the target configuration and Select “Launch Target configuration”. Wait for CCS debug View to launch and display the eight C66x cores and 4 A15 cores.

../_images/Launch_TargetConfig.png ../_images/Connect_A15.png

Start by connecting to A15_0 and C66x_0. when you connect to the cores, you will see the GEL script logs in the console window, which indicates that device clocks, PSC and external DDR memory has been initialized. The GEL log from target connect is provided below for reference.

arm_A15_0: GEL Output: Disabling MMU
arm_A15_0: GEL Output: Disabling Caches
arm_A15_0: GEL Output: Invalidate Instruction Caches
arm_A15_0: GEL Output: Enabling non-secure access to cp10 and cp11
arm_A15_0: GEL Output: Enabled non-secure access to cp10 and cp11
arm_A15_0: GEL Output: Enabling SMP bit in ACTLR
arm_A15_0: GEL Output: Enabled SMP bit in ACTLR
arm_A15_0: GEL Output: Entering NonSecure Mode
arm_A15_0: GEL Output: Entered NonSecure Mode
arm_A15_0: GEL Output: Disabling MMU
arm_A15_0: GEL Output: Disabling Caches
arm_A15_0: GEL Output: Invalidate Instruction Caches
arm_A15_0: GEL Output:

Connecting Target...

arm_A15_0: GEL Output: Disabling MMU
arm_A15_0: GEL Output: Disabling Caches
arm_A15_0: GEL Output: Invalidate Instruction Caches
arm_A15_0: GEL Output: Enabling non-secure access to cp10 and cp11
arm_A15_0: GEL Output: Enabled non-secure access to cp10 and cp11
arm_A15_0: GEL Output: Enabling SMP bit in ACTLR
arm_A15_0: GEL Output: Enabled SMP bit in ACTLR
arm_A15_0: GEL Output: Entering NonSecure Mode
arm_A15_0: GEL Output: Entered NonSecure Mode
arm_A15_0: GEL Output: Disabling MMU
arm_A15_0: GEL Output: Disabling Caches
arm_A15_0: GEL Output: Invalidate Instruction Caches
arm_A15_0: GEL Output: TCI6638K2K GEL file Ver is 1.89999998
arm_A15_0: GEL Output: Disabling MMU
arm_A15_0: GEL Output: Disabling Caches
arm_A15_0: GEL Output: Invalidate Instruction Caches
arm_A15_0: GEL Output: Enabling non-secure access to cp10 and cp11
arm_A15_0: GEL Output: Enabled non-secure access to cp10 and cp11
arm_A15_0: GEL Output: Enabling SMP bit in ACTLR
arm_A15_0: GEL Output: Enabled SMP bit in ACTLR
arm_A15_0: GEL Output: Entering NonSecure Mode
arm_A15_0: GEL Output: Entered NonSecure Mode
arm_A15_0: GEL Output: Disabling MMU
arm_A15_0: GEL Output: Disabling Caches
arm_A15_0: GEL Output: Invalidate Instruction Caches
arm_A15_0: GEL Output: Detected PLL bypass disabled: SECCTL[BYPASS] = 0x00000000
arm_A15_0: GEL Output: (3a) PLLCTL = 0x00000040
arm_A15_0: GEL Output: (3b) PLLCTL = 0x00000040
arm_A15_0: GEL Output: (3c) Delay...
arm_A15_0: GEL Output: (4)PLLM[PLLM] = 0x0000000F
arm_A15_0: GEL Output: MAINPLLCTL0 = 0x07000000
arm_A15_0: GEL Output: (5) MAINPLLCTL0 = 0x07000000
arm_A15_0: GEL Output: (5) MAINPLLCTL1 = 0x00000040
arm_A15_0: GEL Output: (6) MAINPLLCTL0 = 0x07000000
arm_A15_0: GEL Output: (7) SECCTL = 0x00090000
arm_A15_0: GEL Output: (8a) Delay...
arm_A15_0: GEL Output: PLL1_DIV3 = 0x00008002
arm_A15_0: GEL Output: PLL1_DIV4 = 0x00008004
arm_A15_0: GEL Output: PLL1_DIV7 = 0x00000000
arm_A15_0: GEL Output: (8d/e) Delay...
arm_A15_0: GEL Output: (10) Delay...
arm_A15_0: GEL Output: (12) Delay...
arm_A15_0: GEL Output: (13) SECCTL = 0x00090000
arm_A15_0: GEL Output: (Delay...
arm_A15_0: GEL Output: (Delay...
arm_A15_0: GEL Output: (14) PLLCTL = 0x00000041
arm_A15_0: GEL Output: PLL has been configured (CLKIN * PLLM / PLLD / PLLOD = PLLOUT):
arm_A15_0: GEL Output: PLL has been configured (122.879997 MHz * 16 / 1 / 2 = 983.039978 MHz)
arm_A15_0: GEL Output: Switching on ARM Core 0
arm_A15_0: GEL Output: Switching on ARM Core 1
arm_A15_0: GEL Output: Switching on ARM Core 2
arm_A15_0: GEL Output: Switching on ARM Core 3
arm_A15_0: GEL Output: ARM PLL has been configured (125.0 MHz * 16 / 2 = 1000.0 MHz)
arm_A15_0: GEL Output:  DISABLESTAT ---> 0x00000000
arm_A15_0: GEL Output: Power on all PSC modules and DSP domains...
arm_A15_0: GEL Output: Power on all PSC modules and DSP domains... Done.
arm_A15_0: GEL Output: WARNING: SYSCLK is the input to the PA PLL.
arm_A15_0: GEL Output: Completed PA PLL Setup
arm_A15_0: GEL Output: PAPLLCTL0 - before: 0x0x09080500  after: 0x0x09080500
arm_A15_0: GEL Output: PAPLLCTL1 - before: 0x0x00002040  after: 0x0x00002040
arm_A15_0: GEL Output: DDR begin
arm_A15_0: GEL Output: XMC setup complete.
arm_A15_0: GEL Output: DDR3 PLL (PLL2) Setup ...
arm_A15_0: GEL Output: DDR3 PLL Setup complete, DDR3A clock now running at 666 MHz.
arm_A15_0: GEL Output: DDR3A initialization complete
arm_A15_0: GEL Output: DDR3 PLL Setup ...
arm_A15_0: GEL Output: DDR3 PLL Setup complete, DDR3B clock now running at 800MHz.
arm_A15_0: GEL Output: DDR3B initialization complete
arm_A15_0: GEL Output: DDR done
arm_A15_0: GEL Output: Entering A15 non secure mode ..
arm_A15_0: GEL Output: Disabling MMU
arm_A15_0: GEL Output: Disabling Caches
arm_A15_0: GEL Output: Invalidate Instruction Caches
arm_A15_0: GEL Output: Enabling non-secure access to cp10 and cp11
arm_A15_0: GEL Output: Enabled non-secure access to cp10 and cp11
arm_A15_0: GEL Output: Enabling SMP bit in ACTLR
arm_A15_0: GEL Output: Enabled SMP bit in ACTLR
arm_A15_0: GEL Output: Entering NonSecure Mode
arm_A15_0: GEL Output: Entered NonSecure Mode
arm_A15_0: GEL Output: Disabling MMU
arm_A15_0: GEL Output: Disabling Caches
arm_A15_0: GEL Output: Invalidate Instruction Caches
arm_A15_0: GEL Output: A15 non secure mode entered

Users can now load and run code on the cores by using Run -> Load Program. Happy Debugging !!

10.3.8. TMDSEVM6657L EVM Hardware Setup Guide

This page will walk you through setting up your TMDSEVM6657L Evaluation Module (EVM). These guidelines also apply to the L and LE EVM models.

Note

Some of the steps in this section have been updated from those used in the EVM Quick Start Guide.

10.3.8.1. Hardware Setup Overview

The picture below shows the TMDXEVM6657L EVM and the locations of relevant switches and connectors.

../_images/TMDSEVM6657L-image.jpg

10.3.8.2. Hardware Setup Steps

Note

The EVM board is sensitive to electrostatic discharges (ESD). Use a grounding strap or other device to prevent damaging the board. Be sure to connect communication cables before applying power to any equipment.


1. Attach the Ethernet cable Using the Ethernet cable supplied, connect one end of the cable to the Ethernet port on the EVM and the other end to your PC.

2. Connect the JTAG interface Use the USB to USB mini-B cable provided. Connect the USB mini-B connector to the USB mini-B interface on the EVM and the USB connector to your PC. This enables XDS-100 emulation and is directly useable by CCS. If you are using a different JTAG, connect it now.

3. Verify Endian mode in the SW3 settings The Endian mode should be set to Little Endian. SW3 also contains the boot device settings.

../_images/TMD6657LSW3.png

4. Verify boot mode in the SW3 and SW5 settings The boot mode settings below enable NOR boot by loading the boot loader from EEPROM address 0x51.

../_images/TMD6657LSW3-6.png

5. Set User Switch for the demo application The application needs an IP address. It can use either a static IP address (pre-configured) or it can request one using DHCP. This is controlled by setting dip switch 2 of SW9.

User Switch 2 ON : DHCP
User Switch 2 OFF: Static IP
../_images/TMD6678LSW9.png

6. Attach the serial port cable This EVM can use either a USB serial port or the standard DB-9 (use the cable shipped with the platform). By default the shunts which control this on the platforms are set to use the USB by default. We recommend changing them to use the DB-9 as there are no known issues with this approach.

../_images/TMDXEVM6657L-shunts.jpg

../_images/TMDXEVM6657LCOMSEL.png

COM_SEL1: Select UART over 3-Pin Header

Note

If the USB serial port output does not work, ensure that the cable is connected directly to a USB port on the PC/laptop rather than going through an extender or USB hub.

7. Connect the power cable

Connect the power cable to the EVM power jack on the board. To be ESD safe, plug in the other end of the power cable only after you have connected the power cord to the board. Then turn on the board.


10.3.8.3. Boot Mode Dip Switch Settings

The EVM supports booting image from various devices (EEPROM, NAND or NOR) via IBL (at I2C address 0x51), I2C EEPROM (at I2C address 0x50), and ROM Boot modes (such as Ethernet, SRIO, PCIe, SPI etc.) which address the boot source directly from the ROM code. Below is the table showing the boot mode dip switch settings for different boot mode that the EVM supports:

Boot Mode

DIP SW3

(Pin1, 2, 3, 4, 5, 6, 7, 8)

DIP SW5

(Pin1, 2, 3, 4, 5, 6, 7, 8)

IBL NOR boot on image 0 (default) (off, off, on, off, on, on, on, on)1,2,3 (on, on, on, off, on, on, on, on)4
IBL NAND boot on image 0 (off, off, on, off, on, off, on, on) (on, on, on, off, on, on, on, on)
IBL NAND boot on image 1 (off, off, on, off, off, off, on, on) (on, on, on, off, on, on, on, on)
IBL TFTP boot (off, off, on, off, on, on, off, on) (on, on, on, off, on, on, on, on)
I2C POST boot (off, off, on, off, on, on, on, on) (on, on, on, on, on, on, on, on)
ROM SPI Boot8 (off, on, off, off, on, on, on, on) (on, on, off, on, on, on, on, on)
ROM SRIO Boot5 (off, off, on, on, on, on, off, on) (off, on, on, off, off, on, on, on)
ROM Ethernet Boot6 (off, on, off, on, on, on, on, off) (on, off, on, off, off, on, on, on)
ROM PCIE Boot7 (off, on, on, off, on, on, on, on) (on, on, on, off, off, on, on, on)
No boot (off, on, on, on, on, on, on, on) (on, on, on, on, on, on, on, on)
Note: C6657 currently does not support Image 1 for NOR boot.


Footnotes:

1. Pin 1 of SW3 is the endian pin, by default, it is set to off (Little Endian)

2. Pin 2-4 of SW3 are the boot mode pins, by default it is set to I2C boot mode (off, on, off)

3. Pin 5-8 of SW3 and pin 1-2 of SW5 are the boot parameter index pins for I2C boot (paramter index 0/1 for NOR boot image 0/1, parameter index 2/3 for NAND boot image 0/1, parameter index 4 for TFTP boot). By default, image 0 is programmed to offset byte address 0x0 on NOR, and 0x20000 (block 1 start address) on NAND, image 1 is programmed to offset byte address 0x4000000 on NAND.

4. Pin 4 of SW5 is the I2C address pin (off: 0x51, on: 0x50)  for I2C boot mode

5. This will set the board to boot from SRIO boot mode, with reference clock at 250 MHz, data rate at 3.125 GBs, and lane setup 4-1x ports and DSP System PLL at 100 MHz.

6. This will set the board to boot from Ethernet boot mode, with SerDes clock multiplier x 4, core PLL clock at 100 MHz.

7. This will set the board to boot form PCIE boot mode, with PCIE in end point mode and DSP System PLL at 100 MHz.

8. This will set the board to boot from SPI NOR via the ROM code, with boot-table contents expected in the NOR. 24bit addressing has been set.

Please refer to Technical_Reference_Manual for the boot mode switch settings on the board.

10.3.9. TMDXEVM6670L EVM Hardware Setup

This page will walk you through setting up your TMDSEVM6670L Evaluation Module (EVM). These guidelines also apply to the LE and LXE EVM models.

Note

Some of the steps in this section have been updated from those used in the EVM Quick Start Guide.

10.3.9.1. Hardware Setup Overview

The picture below shows the TMDXEVM6670L EVM and the locations of relevant switches and connectors.

../_images/TMD6670L.jpg

10.3.9.2. Hardware Setup Steps

Note

The EVM board is sensitive to electrostatic discharges (ESD). Use a grounding strap or other device to prevent damaging the board. Be sure to connect communication cables before applying power to any equipment.


1. Attach the Ethernet cable
Using the Ethernet cable supplied, connect one end of the cable to the Ethernet port on the EVM and the other end to your PC.

2. Connect the JTAG interface
Use the USB to USB mini-B cable provided. Connect the USB mini-B connector to the USB mini-B interface on the EVM and the USB connector to your PC. This enables XDS-100 emulation and is directly useable by CCS. If you are using a different JTAG, connect it now.

3. Verify Endian mode in the SW3 settings
The Endian mode should be set to Little Endian. SW3 also contains the boot device settings.
../_images/TMD6678LSW3.png

4. Verify boot mode in the SW3 - SW6 settings
The boot mode settings below enable NOR boot by loading the boot loader from EEPROM address 0x51.
../_images/TMD6678LSW3-6.png

5. Set User Switch 2 for the demo application
The application needs an IP address. It can use either a static IP address (pre-configured) or it can request one using DHCP. This is controlled by setting User Switch 2 to ON for DHCP and OFF for Static. See SW9.
../_images/TMD6670LSW9.png

6. Attach the serial port cable
This EVM can use either a USB serial port or the standard DB-9 (use the cable shipped with the platform). By default the shunts which control this on the platforms are set to use the USB by default. We recommend changing them to use the DB-9 as there are no known issues with this approach.
To change the shunts refer to the picture below.
../_images/TMD6670LShunts.jpg

Note

If the USB serial port output does not work, ensure that the cable is connected directly to a USB port on the PC/laptop rather than going through an extender or USB hub.


7. Connect the power cable
Connect the power cable to the EVM power jack on the board. To be ESD safe, plug in the other end of the power cable only after you have connected the power cord to the board. Then turn on the board.

10.3.9.3. Boot Mode Dip Switch Settings

The EVM supports booting image from various devices (EEPROM, NAND or NOR) via IBL, it also supports ROM Boot modes, such as Ethernet, SRIO, PCIe, etc. Below is the table showing the boot mode dip switch settings for different boot mode that the EVM supports:

Boot Mode

DIP SW3

(Pin1, 2, 3, 4)

DIP SW4

(Pin1, 2, 3, 4)

DIP SW5

(Pin1, 2, 3, 4)

DIP SW6

(Pin1, 2, 3, 4)

IBL NOR boot on image 0 (default) (off, off, on, off)1, 2 (on, on, on, on)3 (on, on, on, off)4 (on, on, on, on)
IBL NOR boot on image 1 (off, off, on, off) (off, on, on, on) (on, on, on, off) (on, on, on, on)
IBL NAND boot on image 0 (off, off, on, off) (on, off, on, on) (on, on, on, off) (on, on, on, on)
IBL NAND boot on image 1 (off, off, on, off) (off, off, on, on) (on, on, on, off) (on, on, on, on)
IBL TFTP boot (off, off, on, off) (on, on, off, on) (on, on, on, off) (on, on, on, on)
I2C POST boot (off, off, on, off) (on, on, on, on) (on, on, on, on) (on, on, on, on)
ROM SPI Boot8 (off, on, off, off) (on, on, on, on) (on, on, off, on) (off, on, on, on)
ROM SRIO Boot5 (off, off, on, on) (on, on, on, off) (on, off, on, off) (off, off, on, on)
ROM Ethernet Boot6 (off, on, off, on) (on, on, on, off) (on, off, on, off) (off, off, on, on)
ROM PCIE Boot7 (off, on, on, off) (on, on, on, on) (on, on, on, off) (off, on, on, on)
No boot (off, on, on, on) (on, on, on, on) (on, on, on, on) (on, on, on, on)

Footnotes:

1. Pin 1 of SW3 is the endian pin, by default, it is set to off (Little Endian)

2. Pin 2-4 of SW3 are the boot mode pins, by default it is set to I2C boot mode (off, on, off)

3. Pin 1-4 of SW4 and pin 1-2 of SW5 are the boot parameter index pins for I2C boot (paramter index 0/1 for NOR boot image 0/1, parameter index 2/3 for NAND boot image 0/1, parameter index 4 for TFTP boot). By default, image 0 is programmed to offset byte address 0x0 on NOR, and 0x4000 (block 1 start address) on NAND, image 1 is programmed to offset byte address 0xA00000 on NOR, and 0x2000000 on NAND.

4. Pin 4 of SW5 is the I2C address pin (off: 0x51, on: 0x50)  for I2C boot mode

5. This will set the board to boot from SRIO boot mode, with reference clock at 250 MHz, data rate at 3.125 GBs, and lane setup 4-1x ports and DSP System PLL at 122.88 MHz.

6. This will set the board to boot from Ethernet boot mode, with SerDes clock multiplier x 5, DSP System PLL clock at 122.88 MHz.

7. This will set the board to boot form PCIE boot mode, with PCIE in end point mode and DSP System PLL at 100 MHz.

8. This will set the board to boot from SPI NOR via the ROM code, with boot-table contents expected in the NOR. 24bit addressing has been set.


Please refer to Technical_Reference_Manual for the boot mode switch settings on the board.

10.3.10. TMDXEVM6678L EVM Hardware Setup Guide


This page will walk you through setting up your TMDXEVM6678L Evaluation Module (EVM). These guidelines also apply to the LE and LXE EVM models.

Note

Some of the steps in this section have been updated from those used in the EVM Quick Start Guide.

10.3.10.1. Hardware Setup Overview

The picture below shows the TMDXEVM6678L EVM and the locations of relevant switches and connectors.

../_images/TMDXEVM6678L-image.jpg

Note

Please refer to the following picture for the alpha/beta Lite EVM boards.

../_images/TMD6678L.jpg

10.3.10.2. Hardware Setup Steps

Warning: The EVM board is sensitive to electrostatic discharges (ESD). Use a grounding strap or other device to prevent damaging the board. Be sure to connect communication cables before applying power to any equipment.


1. Attach the Ethernet cable

Using the Ethernet cable supplied, connect one end of the cable to the Ethernet port on the EVM and the other end to your PC.


2. Connect the JTAG interface

Use the USB to USB mini-B cable provided. Connect the USB mini-B connector to the USB mini-B interface on the EVM and the USB connector to your PC. This enables XDS-100 emulation and is directly useable by CCS. If you are using a different JTAG, connect it now.


3. Verify Endian mode in the SW3 settings

The Endian mode should be set to Little Endian. SW3 also contains the boot device settings.


../_images/TMD6678LSW3.png

4. Verify boot mode in the SW3 - SW6 settings

The boot mode settings below enable NOR boot by loading the boot loader from EEPROM address 0x51.

../_images/TMD6678LSW3-6.png

5. Set User Switch for the demo application

The application needs an IP address. It can use either a static IP address (pre-configured) or it can request one using DHCP. This is controlled by setting dip switch 2 of SW9.

User Switch 2 ON : DHCP
User Switch 2 OFF: Static IP
../_images/TMD6678LSW9.png

6. Attach the serial port cable

This EVM can use either a USB serial port or the standard DB-9 (use the cable shipped with the platform). By default the shunts which control this on the platforms are set to use the USB by default. We recommend changing them to use the DB-9 as there are no known issues with this approach.

../_images/TMDXEVM6678L-shunts.jpg

Note

If the USB serial port output does not work, ensure that the cable is connected directly to a USB port on the PC/laptop rather than going through an extender or USB hub.

Note

For the shunts on the alpha/beta Lite EVM, please refer to the picture below for the setting

../_images/TMD6678LShunts.jpg

7. Connect the power cable

Connect the power cable to the EVM power jack on the board. To be ESD safe, plug in the other end of the power cable only after you have connected the power cord to the board. Then turn on the board.


10.3.10.3. Boot Mode Dip Switch Settings

The EVM supports booting image from various devices (EEPROM, NAND or NOR) via IBL (at I2C address 0x51), I2C EEPROM (at I2C address 0x50), and ROM Boot modes (such as Ethernet, SRIO, PCIe, SPI etc.) which address the boot source directly from the ROM code. Below is the table showing the boot mode dip switch settings for different boot mode that the EVM supports:

Boot Mode

DIP SW3

(Pin1, 2, 3, 4)

DIP SW4

(Pin1, 2, 3, 4)

DIP SW5

(Pin1, 2, 3, 4)

DIP SW6

(Pin1, 2, 3, 4)

IBL NOR boot on image 0 (default) (off, off, on, off)1, 2 (on, on, on, on)3 (on, on, on, off)4 (on, on, on, on)
IBL NOR boot on image 1 (off, off, on, off) (off, on, on, on) (on, on, on, off) (on, on, on, on)
IBL NAND boot on image 0 (off, off, on, off) (on, off, on, on) (on, on, on, off) (on, on, on, on)
IBL NAND boot on image 1 (off, off, on, off) (off, off, on, on) (on, on, on, off) (on, on, on, on)
IBL TFTP boot (off, off, on, off) (on, on, off, on) (on, on, on, off) (on, on, on, on)
I2C POST boot (off, off, on, off) (on, on, on, on) (on, on, on, on) (on, on, on, on)
ROM SPI Boot8 (off, on, off, off) (on, on, on, on) (on, on, off, on) (on, on, on, on)
ROM SRIO Boot5 (off, off, on, on) (on, on, on, off) (on, off, on, off) (off, on, on, on)
ROM Ethernet Boot6 (off, on, off, on) (on, on, on, off) (on, on, off, off) (off, on, on, on)
ROM PCIE Boot7 (off, on, on, off) (on, on, on, on) (on, on, on, off) (off, on, on, on)
No boot (off, on, on, on) (on, on, on, on) (on, on, on, on) (on, on, on, on)

Footnotes:

1. Pin 1 of SW3 is the endian pin, by default, it is set to off (Little Endian)

2. Pin 2-4 of SW3 are the boot mode pins, by default it is set to I2C boot mode (off, on, off)

3. Pin 1-4 of SW4 and pin 1-2 of SW5 are the boot parameter index pins for I2C boot (paramter index 0/1 for NOR boot image 0/1, parameter index 2/3 for NAND boot image 0/1, parameter index 4 for TFTP boot). By default, image 0 is programmed to offset byte address 0x0 on NOR, and 0x4000 (block 1 start address) on NAND, image 1 is programmed to offset byte address 0xA00000 on NOR, and 0x2000000 on NAND.

4. Pin 4 of SW5 is the I2C address pin (off: 0x51, on: 0x50)  for I2C boot mode

5. This will set the board to boot from SRIO boot mode, with reference clock at 312.5 MHz, data rate at 3.125 GBs, and lane setup 4-1x ports and DSP System PLL at 100 MHz.

6. This will set the board to boot from Ethernet boot mode, with SerDes clock multiplier x 4, core PLL clock at 100 MHz.

7. This will set the board to boot form PCIE boot mode, with PCIE in end point mode and DSP System PLL at 100 MHz.

8. This will set the board to boot from SPI NOR via the ROM code, with boot-table contents expected in the NOR. 24bit addressing has been set.


Please refer to Technical Reference Manual for the boot mode switch settings on the board.

10.3.11. OMAP-L137/C6747 EVM Hardware Setup Guide

10.3.11.1. Setting up the Hardware

Follow the steps below to setup the hardware and enable communication with the EVM.

Note

The EVM is sensitive to static discharges. Use a grounding strap or other device to prevent damaging the board. Be sure to connect communication cables before applying power to any equipment.

  • Verify that the EVM board’s SW2 (Boot) switch is correctly set. The setting to boot from SPI0 Flash are:
Pin # 7 2 1 0 3
Position 0 1 0 1 X

Note

All boot switch modes can be found in the EVM Technical Reference Manual at the link provided under the Additional Resources section.

  • If you want to use networking, connect the Ethernet cable to one of the Ethernet ports on the EVM board and to an Ethernet network port.
  • Connect the USB cable provided in the kit to the on-board emulation USB port on the board (EMBED USB). Connect the other end to a computer with CCS installed.
  • If you plan to use UART port for a console window, connect the RS-232 null modem cable to the EVM UART port and to the COM port of your host workstation.
  • Connect the power cable to the EVM power jack on the board. To be ESD safe, plug in the other end of the power cable only after you have connected the power cord to the board.

10.3.11.2. Connecting to a Console Window

You can open a console window that allows you to watch boot and serial console messages by following these steps:

  1. Connect a serial cable between the serial port on the EVM and the serial port (for example COM1) on a PC.
  2. Run a terminal session (such as Minicom on Linux or TeraTerm on Windows) on the workstation and configure it to connect to that serial port with the following characteristics:
    • Bits per Second: 115200
    • Data Bits: 8
    • Parity: None
    • Stop Bits: 1
    • Flow Control: None
    • Transmit delay: 0 msec/char, 100 msec/line

For Linux

  1. When you power on the EVM, you will see boot sequence messages (If you have a boot loader in flash). You can press a key to interrupt the boot sequence and type commands in the U-Boot command shell.

10.3.11.3. Connecting to CCS

Note

CCS versions 9.0 and later are 64-bit applications. Due to this, the on-board Spectrum Digital XDS510USB emulator is not supported. The alternatives are to either stay with CCS 8.3 or earlier, or use an external emulator with CCS 9.0. For example, the low cost XDS110 emulator for $99 (http://www.ti.com/tool/TMDSEMU110-U).

10.3.11.3.1. Target Configuration

  • Open CCS and select New->Target Configuration File.
  • Specify a file name or use default.
  • Select “Spectrum Digital XDS510USB Emulator” as Connection. If using CCS 9.0 or later, you will need an external emulator as noted above.
../_images/OMAPL137_targetConfig.png
  • Check “OMAPL137” or “C6747” as Device and save.

Tip

If you don’t see “OMAPL137”, ensure that you have installed CCS and selected Single Core DSP devices in the installation.

  • Open Target Configuration view in CCS by selecting “Window -> Show View -> Target Configurations” from menu.
  • Select newly created configuration, right-click on it and set it as default.
  • Launch Target configuration file

10.3.11.3.2. Connect Target and Load/Run Program

  • Connecting Target
    • Select “View -> Debug” from menu to start a debug session.
    • CCS will switch to Debug perspective with devices DSP and ARM.
    • Select device to connect and then go to “Run -> Connect Target” from menu.

Note

OMAPL137 is a DSP boot master device. Hence to connect to the ARM, you need to connect the DSP first (even if you do not load anything to DSP), then connect ARM (Reason: DSP’s GEL file enables and wakes up the ARM).

  • Loading Program
    • Choose desired device (DSP or ARM).
    • Go to “Run -> Load -> Load Program” from menu.
    • Click “Browse” to choose a prebuilt *.out or click “Browse project..” to choose *.out of the open projects.
    • Choose desired *.out and click OK.
  • Running Program
    • Go to “Run -> Resume”

10.3.11.3.3. Additional References

EVM Design and Support Files: http://support.spectrumdigital.com/boards/evmomapl137/revg/

10.3.12. AM335x ICE EVM Hardware Setup

10.3.12.1. Description

The low-cost ICE EVM can be used for evaluation and development of industrial communication type applications. It has been equipped with a TI AM3359 processor and a defined set of features to allow the user to experience specifically industrial communication solutions using serial or Ethernet based interfaces. It is not intended as a generic development platform as some of the features and interfaces supplied by the AM335x are not accessible from the ICE board. Using standard interfaces, the ICE board may interface to other processors or systems and act as a communication gateway in this case. In addition it can directly operate as a standard remote I/O system or simple sensor connected to an industrial communication network. The embedded emulation logic allows emulation and debug using standard development tools such as TI’s Code Composer Studio by just using the supplied USB cable.

10.3.12.2. EVM Layout and Key Components

../_images/ICE_V2_marked.png

10.3.12.3. Quick Start Guide

This section details how to quickly setup the AM3359 ICE.

1. Unbox the board and identify the various components and connectors shown above.

2. Connect the power cable to the power jack on the board and plug it into an AC power source.

../_images/ICE335924V.png

Once powered on, the POWER ON LED (D16) and Industrial Output LEDs (D6-D10, D12, D14, and D15) will turn on.

Note

When powering the AM335x ICE, always use the supplied power supply (CUI/V-Infinity Part Number EMSA240075) or equivalent model having output voltage of +24VDC and output current max 0.75 Amps and that complies with applicable regional safety standards such as (by example) UL, CSA, VDE, CCC, PSE, etc.

3. Connect the microUSB cable to the USB JTAG/Console port on the ICE board and connect to the USB on the host. Connect an Ethernet cable to ETH0 if network connectivity is required.

../_images/ICE3359USB.png

Note

The serial port will not show up on the host PC until the board is powered on.

4. Users can now connect to UART and the on-board XDS100v2 emulator from the host machine. For UART port connections, set the serial terminal software baud rate to 115200 to view the log messages. Connecting to the target using the on-board emulator is discussed in the section below.

../_images/Serial_connect.jpg ../_images/Baudrate.jpg

10.3.12.4. Boot Configuration

The various boot configurations are discussed in the Hardware User Guide.


10.3.12.5. Connecting the AM3359 ICE to Code Composer Studio

1. Download Code Composer Studio and the AM335x Sitara Device Support package as described in the Processor SDK RTOS Getting Started Guide.

2. Connect the AM3359 ICE as described above in the Quick Start Guide.

3. Launch CCS and create a new target configuration file (File->New->Target Configuration File) as shown below. Select the Texas Instruments XDS100v2 USB Debug Probe and the ICE_AM3359 as shown below.

Note

If the ICE_AM3359 target is not listed, make sure the latest Sitara Device Support package is installed by going to Help->Check for Updates.

../_images/ICE3359TargetConfig.png

4. Click Save to save the target configuration. Then press Test Connection to test the connection. If successful, a message should be seen similar to the one below.

../_images/ICE3359Test.png

5. Launch the target configuration and connect to the ARM Cortex-A8.

The complete GEL log from the Cortex A8 is provided below.

CortxA8: Output: ****  AM3359_ICE Initialization is in progress ..........
CortxA8: Output: ****  AM335x ALL PLL Config for OPP == OPP100 is in progress .........
CortxA8: Output: Input Clock Read from SYSBOOT[15:14]:  24MHz
CortxA8: Output: ****  Going to Bypass...
CortxA8: Output: ****  Bypassed, changing values...
CortxA8: Output: ****  Locking ARM PLL
CortxA8: Output: ****  Core Bypassed
CortxA8: Output: ****  Now locking Core...
CortxA8: Output: ****  Core locked
CortxA8: Output: ****  DDR DPLL Bypassed
CortxA8: Output: ****  DDR DPLL Locked
CortxA8: Output: ****  PER DPLL Bypassed
CortxA8: Output: ****  PER DPLL Locked
CortxA8: Output: ****  DISP PLL Config is in progress ..........
CortxA8: Output: ****  DISP PLL Config is DONE ..........
CortxA8: Output: ****  AM335x ALL ADPLL Config for OPP == OPP100 is Done .........
CortxA8: Output: ****  AM335x DDR3 EMIF and PHY configuration is in progress...
CortxA8: Output: EMIF PRCM is in progress .......
CortxA8: Output: EMIF PRCM Done
CortxA8: Output: DDR PHY Configuration in progress
CortxA8: Output: Waiting for VTP Ready .......
CortxA8: Output: VTP is Ready!
CortxA8: Output: DDR PHY CMD0 Register configuration is in progress .......
CortxA8: Output: DDR PHY CMD1 Register configuration is in progress .......
CortxA8: Output: DDR PHY CMD2 Register configuration is in progress .......
CortxA8: Output: DDR PHY DATA0 Register configuration is in progress .......
CortxA8: Output: DDR PHY DATA1 Register configuration is in progress .......
CortxA8: Output: Setting IO control registers.......
CortxA8: Output: EMIF Timing register configuration is in progress .......
CortxA8: Output: EMIF Timing register configuration is done .......
CortxA8: Output: PHY is READY!!
CortxA8: Output: DDR PHY Configuration done
CortxA8: GEL Output: Turning on EDMA...
CortxA8: GEL Output: EDMA is turned on...
CortxA8: Output: ****  AM3359_ICE Initialization is Done ******************

10.3.12.6. Running Board Diagnostics

The Processor SDK RTOS Diagnostic package is designed to be a set of baremetal tests to run on a given board to provide data path continuity testing on peripherals.

To run diagnostics on the AM335x ICE, follow the procedure given in the RTOS Software Developer Guide

10.3.13. AMIC110 ICE EVM Hardware Setup

10.3.13.1. Description

The AMIC110 ICE is a high-performance, low-power platform that enables users to evaluate and develop industrial communications applications for the Sitara AMIC110 ARM Cortex-A8 processor SoC from Texas Instruments.™

10.3.13.2. EVM Layout and Key Components

../_images/ICEAMIC110TopLayout.PNG ../_images/ICEAMIC110BottomLayout.PNG

10.3.13.3. Quick Start Guide

This quick start guide can be found in the Hardware User’s Guide.

1. Unbox the board and identify the various components and connectors shown above.

2. To download a bootable image into the onboard SPI Flash, connect a 20-pin JTAG emulator to J1 on the ICE board. For example, the XDS110 or the XDS200 emulators may be used for this purpose and can be purchased from the TI store: XDS200 and XDS110.

../_images/ICEAMIC110JTAG.PNG

3. Connect the pin header connector of the included TTL-232R-3V3 serial cable to J3 on the ICE board. Ensure that pin 1 of the serial cable (black wire, marked with a triangle) is connected to pin 1 of J3, which is indicated by a dot on the silk screen. Connect the USB connector of the serial cable to a PC host port. The datasheet for this cable can found at http://www.ftdichip.com/Support/Documents/DataSheets/Cables/DS_TTL-232R_CABLES.pdf

../_images/ICEAMIC110TTL.PNG

4. Connect a CAT5 Ethernet cable from a PC running TwinCAT software to ECAT IN/PHY1 (J6) of the ICE board. If you have multiple ICE boards in a chain, please connect another CAT5 Ethernet cable from ECAT OUT/PHY2 (J7) to PHY1 of the next ICE board. PHY2 of the last ICE board in the chain is left open.

../_images/ICEAMIC110ETHERNET.PNG

5. Connect the recommended power supply (CUI Inc. SMI18-5-V-P5, procurable at: http://www.digikey.com/product-detail/en/cui-inc/SMI18-5-V-P5/102-3571-ND/5415042) or equivalent (Output voltage/current: 5 Volts DC +/- 10% @ 1.2 Amps; Output connector: 2.1-mm ID, 5.5-mm OD barrel plug, center positive) power supply to J8 on the ICE board. Apply power to the power supply to power up the ICE board. Do not hot plug the 5-V supply into the ICE board.

../_images/ICEAMIC1105V.PNG

Once the ICE board is powered on, the ON LED (D15) and LED4 (D19) will turn on.

6. The AMIC110 ICE can now be connected to from the host machine via UART. The serial port should be setup as shown below.

../_images/Baudrate.jpg

10.3.13.4. Boot Configuration

The various boot configurations are discussed in the Hardware User Guide.

10.3.13.5. Connecting the AMIC110 ICE to Code Composer Studio

1. Download Code Composer Studio and the AMIC110 Sitara Device Support package as described in the Processor SDK RTOS Getting Started Guide.

2. Connect the AMIC110 ICE as described in the Quick Start Guide.

3. Launch CCS and create a new target configuration file (File->New->Target Configuration File) as shown below. Select the appropriate emulator and the ICE_AMIC110 as the target as shown below.

Note

If the ICE_AMIC110 target is not listed, make sure the Sitara Device Support package v1.3.6 or greater is installed.

../_images/ICEAMIC110TargetConfig.PNG

4. Click Save to save the target configuration. Then press Test Connection to test the connection. If successful, a message should be seen similar to the one below.

../_images/ICEAMIC110Test.PNG

5. Launch the target configuration and connect to the ARM Cortex-A8.

The complete GEL log from the Cortex A8 is provided below.

CortxA8: Output: ****  AMIC110_ICE & BoosterPack Initialization is in progress ......
CortxA8: Output: ****  AMIC110 & Booster Pack ALL PLL Config for OPP == OPP100 is in progress ........
CortxA8: Output: Input Clock Read from SYSBOOT[15:14]:  25MHz
CortxA8: Output: ****  Going to Bypass...
CortxA8: Output: ****  Bypassed, changing values...
CortxA8: Output: ****  Locking ARM PLL
CortxA8: Output: ****  Core Bypassed
CortxA8: Output: ****  Now locking Core...
CortxA8: Output: ****  Core locked
CortxA8: Output: ****  DDR DPLL Bypassed
CortxA8: Output: ****  DDR DPLL Locked
CortxA8: Output: ****  PER DPLL Bypassed
CortxA8: Output: ****  PER DPLL Locked
CortxA8: Output: ****  DISP PLL Config is in progress ..........
CortxA8: Output: ****  DISP PLL Config is DONE ..........
CortxA8: Output: ****  AMIC110 BoosterPack ALL ADPLL Config for 25 MHz OPP == OPP100 25MHz is Done .........
CortxA8: Output: ****  AMIC110 DDR3 EMIF and PHY configuration is in progress...
CortxA8: Output: EMIF PRCM is in progress .......
CortxA8: Output: EMIF PRCM Done
CortxA8: Output: DDR PHY Configuration in progress
CortxA8: Output: Waiting for VTP Ready .......
CortxA8: Output: VTP is Ready!
CortxA8: Output: DDR PHY CMD0 Register configuration is in progress .......
CortxA8: Output: DDR PHY CMD1 Register configuration is in progress .......
CortxA8: Output: DDR PHY CMD2 Register configuration is in progress .......
CortxA8: Output: DDR PHY DATA0 Register configuration is in progress .......
CortxA8: Output: DDR PHY DATA1 Register configuration is in progress .......
CortxA8: Output: Setting IO control registers.......
CortxA8: Output: EMIF Timing register configuration is in progress .......
CortxA8: Output: EMIF Timing register configuration is done .......
CortxA8: Output: PHY is READY!!
CortxA8: Output: DDR PHY Configuration done
CortxA8: GEL Output: Turning on EDMA...
CortxA8: GEL Output: EDMA is turned on...
CortxA8: Output: ****  AMIC110_ICE Initialization is Done ******************

10.3.13.6. Running Board Diagnostics

The Processor SDK RTOS Diagnostic package is designed to be a set of baremetal tests to run on a given board to provide data path continuity testing on peripherals.

To run diagnostics on the AMIC110 ICE, follow the procedure given in the RTOS Software Developer Guide

10.3.14. 66AK2G Audio DC AddOn

Please refer to K2G Audio DC AddOn