This example shows how to build and run an ICS host application on Linux on the AM64x-EVM, connected over SPI to a TICS100MOD target. It supports EtherCAT, EtherNet/IP, and PROFINET, with one build configuration per protocol, and includes an EtherCAT demo with TwinCAT.

Before starting, complete the Quick Start Guide and flash the protocol firmware for your chosen protocol onto the target, as described in the Configurator guide.

Overview

am64-main-app is an ICS host application for Linux. In the installed TICS100MOD SDK, the project is located under:

<TICS_SDK_INSTALL_DIR>\examples\ics-host\linux\am64-main-app

Import this folder into Eclipse IDE. The imported project is named ics-host-app-am64-linux.

Item	Details
Host	AM64x-EVM
Target	TICS100MOD
Host-target interface	MCU SPI0 plus GPIO handshake and reset lines
Operating system	Linux (`ti-processor-sdk-linux-am64xx-evm-11.01.05.03`)
Protocols	EtherCAT, EtherNet/IP, PROFINET
Project name	`ics-host-app-am64-linux`

Prerequisites

Item	Details
Hardware	AM64x-EVM, TICS100MOD (Carrier Board and ICS Development Board), 8 jumper wires, industrial network controller
Host PC software	Eclipse IDE for C/C++ Developers, Arm GNU Toolchain (AArch64 Linux), MinGW `make`
Linux SDK	Patched kernel and device tree (see AM64x Linux SDK Modifications)
Target firmware	Firmware for the chosen protocol, flashed as described in the Quick Start Guide
Controller software	TwinCAT (EtherCAT), a PROFINET controller and PRONETA (PROFINET), or an EtherNet/IP scanner (EtherNet/IP)

Hardware Setup

Connect the AM64x-EVM to the TICS100MOD target with jumper wires according to the table below.

Signal	AM64x-EVM pin (Safety Connector)	TICS100MOD pin	Wiring Color Code
CLOCK	16 (MCU_SPI0_CLK)	SPI0_CLK	Blue
MOSI	4 (MCU_SPI0_D0)	SPI0_D0	Red
MISO	2 (MCU_SPI0_D1)	SPI0_D1	Green
CS	12 (MCU_GPIO0_9)	SPI0_CS	Yellow
TARGET BUSY	5 (MCU_GPIO0_8)	GPIO8	Orange
TARGET REQUEST	9 (MCU_GPIO0_7)	GPIO14	Purple
TARGET RESET	20 (MCU_I2C0_SCL)	PORZ_HOST	Grey
GND	23 (DGND)	GND	Black

AM64x-EVM to TICS100MOD host interface connections

Warning: Power off both boards before changing any wiring.

Host Environment Setup

This section describes the software tools, development environment, and target-specific modifications used to develop and build the ICS host application for the AM64x EVM platform.

Development Environment

The host application was initially developed on Windows using Eclipse IDE for C/C++ Developers.

While the current workflow is Eclipse-based, future development may migrate toward a more platform-independent build system, such as CMake or Autotools, to simplify integration with environments such as Yocto and other Linux-based build systems.

Eclipse IDE

Install Eclipse IDE for C/C++ Developers.

Download: LINK

Arm GNU Toolchain

Install the Arm GNU cross-compilation toolchain used to build the Linux application for the AM64x target.

Download: LINK

After installation, add the toolchain bin directory to the system PATH.

MinGW

Install MinGW to provide the make utility required by the build process.

Download: LINK

Select the mingw32-base package and add the MinGW bin directory to the system PATH.

Create a copy of mingw32-make.exe and rename the copied file to make.exe.

AM64x Linux SDK Modifications

Note: The patch below was developed and validated against the Linux SDK version ti-processor-sdk-linux-am64xx-evm-11.01.05.03. If a different SDK version is used, the patch may require manual review or adaptation before being applied successfully.

Several Linux kernel and device-tree modifications are required on the AM64x EVM to support the host application.

Since no Main Domain SPI interface is exposed through the board connectors, the mcu_spi0 peripheral is used for communication with the target device.

The industrial LED GPIO expander driver must also be enabled by setting:

CONFIG_GPIO_TPIC2810=m

All the required GPIOs are configured as well.

In addition, the onboard red LED was repurposed for application testing and validation, and its default device-tree configuration was disabled.

All required Linux SDK modifications are provided in the patch below:

diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
index 0bc42c8f1..f44b396ae 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
@@ -193,18 +193,6 @@ vtt_supply: regulator-5 {
        regulator-boot-on;
    };
 
-   leds {
-       compatible = "gpio-leds";
-
-       led-0 {
-           label = "am64-evm:red:heartbeat";
-           gpios = <&exp1 16 GPIO_ACTIVE_HIGH>;
-           linux,default-trigger = "heartbeat";
-           function = LED_FUNCTION_HEARTBEAT;
-           default-state = "off";
-       };
-   };
-
    mdio_mux: mux-controller {
        compatible = "gpio-mux";
        #mux-control-cells = <0>;
@@ -489,6 +477,61 @@ AM64X_IOPAD(0x0104, PIN_OUTPUT, 2) /* (W7) PRG1_PRU0_GPO19.PRG1_IEP0_EDC_SYNC_OU
    };
 };
 
+&mcu_pmx0 {
+
+   mcu_spi0_pins: mcu-spi0-pins {
+       pinctrl-single,pins = <
+           /* (E6) MCU_SPI0_CLK */
+           AM64X_MCU_IOPAD(0x0008, PIN_OUTPUT, 0)
+           /* (D6) MCU_SPI0_CS0 */
+           AM64X_MCU_IOPAD(0x0000, PIN_OUTPUT, 0)
+           /* (C6) MCU_SPI0_CS1 */
+           AM64X_MCU_IOPAD(0x0004, PIN_OUTPUT, 0)
+           /* (E7) MCU_SPI0_D0 */
+           AM64X_MCU_IOPAD(0x000c, PIN_OUTPUT, 0)
+           /* (B6) MCU_SPI0_D1 */
+           AM64X_MCU_IOPAD(0x0010, PIN_INPUT, 0)
+       >;
+   };
+
+   mcu_gpio0_pins: mcu-gpio0-pins {
+       pinctrl-single,pins = <
+           /* Pins used by ICS */
+           /* (D7) MCU_SPI1_CLK.MCU_GPIO0_7        ------> Pin 9 in Safety Connector*/
+           AM64X_MCU_IOPAD(0x001c, PIN_INPUT, 7)
+           /* (C7) MCU_SPI1_D0.MCU_GPIO0_8         ------> Pin 5 in Safety Connector*/
+           AM64X_MCU_IOPAD(0x0020, PIN_INPUT, 7)
+           /* (C8) MCU_SPI1_D1.MCU_GPIO0_9         ------> Pin 12 in Safety Connector*/
+           AM64X_MCU_IOPAD(0x0024, PIN_OUTPUT, 7)
+           /* (E9) MCU_I2C0_SCL.MCU_GPIO0_18       ------> Pin 20 in Safety Connector*/
+           AM64X_MCU_IOPAD(0x0048, PIN_OUTPUT, 7)
+           /* (A10) MCU_I2C0_SDA.MCU_GPIO0_19      ------> Pin 17 in Safety Connector*/
+           AM64X_MCU_IOPAD(0x004c, PIN_OUTPUT, 7)
+
+           /* Pins unused by ICS */
+           /* (A7) MCU_SPI1_CS0.MCU_GPIO0_5 */
+           AM64X_MCU_IOPAD(0x0014, PIN_INPUT, 7)
+           /* (B7) MCU_SPI1_CS1.MCU_GPIO0_6 */
+           AM64X_MCU_IOPAD(0x0018, PIN_INPUT, 7)
+
+
+           /* (A11) MCU_I2C1_SCL.MCU_GPIO0_20 */
+           AM64X_MCU_IOPAD(0x0050, PIN_INPUT, 7)
+           /* (B10) MCU_I2C1_SDA.MCU_GPIO0_21 */
+           AM64X_MCU_IOPAD(0x0054, PIN_INPUT, 7)
+
+           /* (B8) MCU_UART1_CTSn */
+           AM64X_MCU_IOPAD(0x0040, PIN_INPUT, 7)
+           /* (B9) MCU_UART1_RTSn */
+           AM64X_MCU_IOPAD(0x0044, PIN_INPUT, 7)
+           /* (C9) MCU_UART1_RXD */
+           AM64X_MCU_IOPAD(0x0038, PIN_INPUT, 7)
+           /* (D9) MCU_UART1_TXD */
+           AM64X_MCU_IOPAD(0x003c, PIN_INPUT, 7)
+       >;
+   };
+};
+
 &fss {
    bootph-all;
 };
@@ -555,6 +598,14 @@ exp1: gpio@22 {
                  "TP87", "TP86", "TP89", "TP91";
    };
 
+   exp2: gpio@60 {
+       compatible = "ti,tpic2810";
+       reg = <0x60>;
+       gpio-controller;
+       #gpio-cells = <2>;
+       gpio-line-names = "LED1","LED2","LED3","LED4","LED5","LED6","LED7","LED8";
+   };
+
    /* osd9616p0899-10 */
    display@3c {
        compatible = "solomon,ssd1306fb-i2c";
@@ -575,13 +626,22 @@ &main_gpio0 {
    bootph-all;
 };
 
-/* mcu_gpio0 and mcu_gpio_intr are reserved for mcu firmware usage */
-&mcu_gpio0 {
-   status = "reserved";
+&mcu_spi0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&mcu_spi0_pins>;
+   ti,pindir-d0-out-d1-in;
+   status = "okay";
+
+       spidev0: spi@0 {
+       compatible = "rohm,dh2228fv";
+       reg = <0>;
+       spi-max-frequency = <10000000>;
+   };
 };
 
-&mcu_gpio_intr {
-   status = "reserved";
+&mcu_gpio0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&mcu_gpio0_pins>;
 };
 
 &main_spi0 {
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 9b139d534..b77a304b6 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -710,6 +710,7 @@ CONFIG_GPIO_MXC=y
 CONFIG_GPIO_PL061=y
 CONFIG_GPIO_RCAR=y
 CONFIG_GPIO_SYSCON=y
+CONFIG_GPIO_TPIC2810=m
 CONFIG_GPIO_UNIPHIER=y
 CONFIG_GPIO_VISCONTI=y
 CONFIG_GPIO_WCD934X=m

AM64x EVM preparation

After applying the Linux SDK patch:

Rebuild the Linux kernel and device tree.
Deploy the generated artifacts to the boot SD card.
Boot the AM64x EVM.
Establish an SSH connection to the target so you can send the application binary later.

Build

The project provides one build configuration for each supported protocol:

Configuration	Protocol
`Debug Ethernetip`	EtherNet/IP
`Debug Profinet`	PROFINET
`Debug Ethercat`	EtherCAT

In Project Explorer, right-click ics-host-app-am64-linux.
Select Build Configurations -> Set Active and choose the configuration for your protocol.
Select Project -> Build Project.
Verify that the build completes without errors.

Runtime Preparation

Install the rebuilt kernel modules, including the TPIC2810 driver, alongside the matching kernel and device tree. Confirm that /dev/spidev1.0 and the configured GPIO chips are available, and grant the application the required device access. Install the matching libgpiod runtime, ensure the binary has execute permission, and launch it from a writable working directory for file-transfer tests.

In Eclipse, set the Cross GCC toolchain path to the actual compiler installation directory and verify its AArch64 Linux compiler prefix. The project's saved compiler directory is independent of the shell PATH.

Run

After a successful build:

Ensure that the host and target boards are powered on.
Ensure that the protocol firmware corresponding to the selected build configuration has been flashed onto the target device (via the configurator tool).
Connect the Ethernet port of the TICS100MOD target to the industrial network controller (for example, a PLC or TwinCAT PC), directly or through a switch.
Send the built application binary to your AM64x-EVM board (e.g. with ssh).
Launch the application from the Linux terminal.

The controller-side configuration for each protocol is described in the EtherCAT, EtherNet/IP, and PROFINET demo sections below.

Test the Application

Common Tests

The following tests are common to all protocols:

Auto increment variable test
Emergency variable test
T2N test (target to network)
LED test (network to target)

These common tests demonstrate how the same ICS API can be used across all of the supported industrial protocols: EtherCAT, EtherNet/IP, and PROFINET.

Console Interface

The application console interface is used for executing test commands when launched from an interactive terminal.

The available commands allow you to start and stop supported tests and check their status where applicable.

Auto Increment Variable Test

The auto increment variable test validates the acyclic network-to-target object read/get request and the associated object read callback mechanism. The test verifies that the callback is triggered whenever the object is read by a network controller.

When a network controller (for example, a PLC) requests the value of the auto increment variable, the read callback is triggered on the host. The callback increments the current variable value by 1 and returns the updated value to the requester. As a result, each successive read operation returns a value that is one greater than the previous one.

Emergency Variable Test

The emergency variable test validates the acyclic network-to-target object write/set request and the associated object write callback mechanism. The test verifies that the callback is triggered whenever the object is written by a network controller.

When the emergency variable is written, the callback compares its value against the configured EMERGENCY_THRESHOLD of 100. Values greater than the threshold set the emergency output pin high; otherwise, it is set low.

LED Test

The LED test reads the cyclic network-to-target LED status variable and updates the corresponding host LEDs.

Start the test:

LED_TEST start

Stop the test:

LED_TEST stop

Display the current LED status:

LED_TEST status

T2N Test

The Target-to-Network (T2N) test periodically increments a 16-bit variable and applies the updated value to the target.

Start the test:

T2N_TEST start

Stop the test:

T2N_TEST stop

Display the current T2N test status:

T2N_TEST status

Bus State Monitoring Test

The bus state monitoring test periodically refreshes and reads the bus state variable. The result is reported in the application debug logs.

Start the test:

BUS_STATE_MONITOR_TEST start

Stop the test:

BUS_STATE_MONITOR_TEST stop

EtherCAT SubDevice Demo

Starting the Demo

Ensure that the am64-main-app application has been built using the Debug Ethercat build configuration and that the corresponding EtherCAT SubDevice firmware is running on the target TICOM100MOD.
Connect the AM64x-EVM host to TICOM100MOD target as described in the Hardware Setup section.
Connect the EtherCAT Maindevice to ECAT IN port of the TICOM100MOD. EtherCAT Subdevice ports and RUN/ERR LEDs are indicated in the below image.

EtherCAT Subdevice Ports and LEDs
Launch the Linux host application using the procedure described in Run.

./ics-host-app-am64-linux
Verify that the Linux host application initializes successfully with the TICOM100MOD target being identified before proceeding with the TwinCAT setup.

EtherCAT demo launch

TwinCAT Setup

Launch TwinCAT.
Copy the EtherCAT ESI XML file, TICS100MOD Simple.xml, to the TwinCAT directory:

C:\TwinCAT\3.1\Config\Io\EtherCAT\
Create a new TwinCAT (XML Format) project.
Ensure that TwinCAT is in Config Mode _(the icon in the Windows system tray should be Blue)_.
In Solution Explorer, expand I/O, right-click Devices, and select Scan.
Select the network adapter connected to the EtherCAT network and follow the prompts to scan for connected devices.
Once the scan is completed, select the TICS100MOD device.

TICS100MOD detected in TwinCAT
Open the device's Online tab to monitor its EtherCAT state.

TICS100MOD Online tab in TwinCAT
Verify that the TICS100MOD reaches OP (Operational) state.

Common Application Features

The following demonstrations illustrate the common functionality provided by the ICS host application. The same application-level interfaces are used across all of the supported industrial protocols.

LED Test

The LED test reads the cyclic network-to-target LED status variable and updates the corresponding host LEDs.

Start the test by entering the following command in the Linux host application's console:

LED_TEST start

Starting the LED test
In TwinCAT, expand RxPDO and select i2c-leds.

Selecting the i2c-leds variable
Open the Online tab and for example, write 255 to the variable.

Writing 255 to the LED variable
Verify that the updated value is reflected in TwinCAT and in the Linux host application's console output.

LED variable value reaching 255 in TwinCAT

Linux host console showing all eight LEDs ON

The host console should report the LED states, with all eight LEDs shown as ON when the value is 255.

T2N Test

The Target-to-Network (T2N) test periodically increments a variable and applies the updated value to the target. The value is transferred cyclically and can be monitored in TwinCAT.

In TwinCAT, locate the process-data variable associated with the T2N test.

Initial T2N process-data value in TwinCAT
Start the test by entering the following command in the Linux host application's console:

T2N_TEST start

Starting the T2N test in the Linux host console
Monitor the variable in TwinCAT's process-data view and verify that its value changes while the test is running.

T2N process-data value changing in TwinCAT
Stop the test by entering the following command in the Linux host application's console:

T2N_TEST stop

Emergency Variable Test

The emergency variable test validates acyclic object write access and the associated host-side write callback. When the emergency variable is written through TwinCAT, the host application logs the received value and controls the emergency output pin according to the configured EMERGENCY_THRESHOLD of 100.

In TwinCAT, open the CoE - Online tab and locate the emergency message variable in the object dictionary.

Emergency variable in the TwinCAT CoE object dictionary
Write a value greater than 100 (for example, 101) to the variable.

Writing a value greater than 100 to the emergency variable in TwinCAT
Verify that the Linux host application's terminal logs the received value and that the emergency output pin is set HIGH.

Linux host terminal logging the emergency value and setting the emergency output HIGH
Write a value less than or equal to 100 (for example, 100) to the variable. Verify that the terminal logs the new value and that the emergency output pin is set LOW.

Linux host terminal logging a value at or below 100 and setting the emergency output LOW

EtherCAT Specific Tests

File over EtherCAT (FoE)

The File Access over EtherCAT (FoE) test demonstrates file transfer between TwinCAT and the ICS application using the FoE service.

In TwinCAT, open the Online tab and locate the File Access over EtherCAT panel.

File Access over EtherCAT panel in the TwinCAT Online tab
In the Download section, select a test file and download it to the device. In this example, the target firmware .mcelf file is used.

Linux host terminal showing FoE download write requests and the file-close operation

Verify that the download completes successfully.
In the Upload section, upload the file from the device back to the PC, specifying the appropriate file name and destination.

Linux host terminal showing FoE upload activity and the end-of-file condition

Verify that the upload completes successfully.
Compare the uploaded file with the original test file and verify that their binary contents match.

Binary comparison confirming that the uploaded file matches the original firmware file

Ethernet over EtherCAT (EoE)

The Ethernet over EtherCAT (EoE) test demonstrates Ethernet communication over the EtherCAT connection. The test uses TwinCAT to configure EoE and verifies connectivity by pinging the configured IP address and observing the corresponding output in the Linux host application's terminal.

Note

The provided host application currently uses hardcoded MAC and IP addresses. Ensure that the EoE configuration in TwinCAT matches these settings:

MAC address: 02:01:05:20:03:E9
IP address: 192.168.1.15

In TwinCAT, select the device and open its EtherCAT tab. Click Advanced Settings.

TwinCAT EtherCAT tab showing the Advanced Settings button
In the Advanced Settings window, expand Mailbox and select EoE. Select the IP Port option, then select IP Address and verify that the EoE network configuration is correct.

TwinCAT EoE settings showing the Mailbox options, IP Port selection, and IP address configuration
Open the Windows Command Prompt and ping the configured IP address:

ping <IP_ADDRESS>

Replace <IP_ADDRESS> with the IP address configured for EoE.

Windows Command Prompt showing the ping command and its output
Verify that the Linux host application's terminal displays the corresponding received Ethernet traffic.

Linux host terminal showing received Ethernet traffic over EoE

ADS over EtherCAT (AoE)

The ADS over EtherCAT (AoE) test demonstrates read and write access through TwinCAT.

In TwinCAT, select the device and open the AoE - Online tab. For example, configure the test parameters as shown in the screenshot.

TwinCAT AoE - Online tab showing the configured parameters
Click Read and verify that the operation completes successfully.

TwinCAT AoE - Online interface showing the successful Read operation
Click Write to write the test data, then click Read again to verify that the returned data matches the written data.

TwinCAT AoE - Online interface showing the Write operation and subsequent Read result
Open the CoE - Online tab and verify that the corresponding object reflects the written value.

TwinCAT CoE - Online tab showing the updated object value at subindex 0x02

Diagnostic Messages

This test demonstrates the transmission of diagnostic messages and verifies that they are displayed in TwinCAT's diagnostic history. The example includes Info, Warning, and Error messages.

After launching the provided Linux host application binary, the terminal displays the configured diagnostic messages being sent, including their diagnostic codes and message types.

Linux host terminal showing Info, Warning, and Error diagnostic messages
In TwinCAT, select the device and open the Diag History tab. Click Update History and verify that the diagnostic messages appear with the corresponding Info, Warning, and Error types.

TwinCAT diagnostic history showing Info, Warning, and Error messages

Ethernet/IP Demo

The EtherNet/IP demo showcases both cyclic and acyclic data exchange between an EtherNet/IP network controller (for example, a PLC) and the host application through the ICS software stack.

The demo creates a custom EtherNet/IP object and a set of assemblies that can be used to validate different communication paths and callback mechanisms implemented by the host application.

Created Objects

The demo creates a custom EtherNet/IP object with:

Class ID: 0x70
Instance ID: 0x01

Created Attributes

Attribute ID	Size in bytes	Purpose	Related Test
`0x300`	2	Cyclic	T2N Test
`0x301`	2	Cyclic	-
`0x302`	2	Cyclic	-
`0x303`	2	Cyclic	-
`0x310`	1	Cyclic	LED Test
`0x311`	2	Cyclic	-
`0x312`	2	Cyclic	-
`0x313`	2	Cyclic	-
`0x320`	1	Cyclic	-
`0x321`	1	Cyclic	-
`0x322`	1	Cyclic	-
`0x323`	1	Cyclic	-
`0x380`	4	Acyclic	Auto Increment Variable Test
`0x381`	4	Acyclic	Emergency Variable Test
`0x400`	2	Acyclic (Class Attribute)

The demo test variables are mapped to their corresponding EtherNet/IP object attributes in examples/ics-host/linux/am64-main-app/linux-app/ethernetip/ics_protocol_ethernetip.c, as shown below:

static void IcsProtocol_mapUserObjectsToAppObjects()
{
    leds_status_byte = Class0x70_Instance0x01_Attr0x310;
    auto_increment_word = Class0x70_Instance0x01_Attr0x300;
    increment_by_read = Class0x70_Instance0x01_Attr0x380;
    emergency_uint32 = Class0x70_Instance0x01_Attr0x381;
}

The mapping associates the application variables used by the demo test cases with their corresponding EtherNet/IP object attributes:

leds_status_byte → Attribute 0x310 (LED Test)
auto_increment_word → Attribute 0x300 (T2N Test)
increment_by_read → Attribute 0x380 (Auto Increment Variable Test)
emergency_uint32 → Attribute 0x381 (Emergency Variable Test)

Created Assemblies

Assembly Type	Instance ID	Mapped Attributes
Configuration Assembly	`0x04`	`0x320`, `0x321`
Configuration Assembly	`0x05`	`0x322`, `0x323`
Input Assembly	`0x64`	`0x300`, `0x301`
Output Assembly	`0x65`	`0x310`, `0x311`
Input Assembly	`0x66`	`0x302`, `0x303`
Output Assembly	`0x67`	`0x312`, `0x313`

Created Custom CIP Services

In addition to the custom object and assemblies, the demo creates two custom CIP services under Class 0x70.

Service Code	Class ID	Instance ID	Response Type	Purpose
`0x4B`	`0x70`	`0x00`	Synchronous	Demonstrates a custom class-level CIP service.
`0x4C`	`0x70`	`0x01`	Asynchronous	Demonstrates a custom instance-level CIP service.

Service 0x4B - Synchronous Custom Service

This service is implemented at the class level (Class 0x70, Instance 0x00) and returns its response synchronously.

The response size increases each time the service is executed. If the service has been invoked X times since startup, the response contains X bytes, where every byte has the value X.

This behavior allows users to verify that the service has been executed and that the returned payload is generated dynamically on each request.

Service 0x4C - Asynchronous Custom Service

This service is implemented at the instance level (Class 0x70, Instance 0x01) and demonstrates the use of the ICS asynchronous custom service response mechanism.

Upon receiving the service request, the host application does not return the response immediately. Instead, the request is completed asynchronously using the custom-service asynchronous response handler mechanism.

Tests

Note: The device adapter is configured by default with the static IP address 192.168.1.10. Ensure that the EtherNet/IP network controller is configured with an IP address in the same subnet (for example, 192.168.1.1 with subnet mask 255.255.255.0) to allow communication with the adapter.

The following sections describe each test in detail, including the corresponding attribute and the procedure required to validate its functionality.

Common Tests

> Auto Increment Variable Test

Associated Attribute: 0x380

The auto increment variable test validates the acyclic object read path and the associated object read callback mechanism.

To execute the test:

From the network controller (for example, a PLC), repeatedly issue a Get_Attribute_Single request targeting:
- Class: 0x70
- Instance: 0x01
- Attribute: 0x380
Observe the response value returned by the device.

Expected result:

The read callback is executed for every request.
The attribute value is incremented by 1 before the response is sent.
Each subsequent request therefore returns a value that is one greater than the value returned by the previous request.

> Emergency Variable Test

Associated Attribute: 0x381

The emergency variable test validates the acyclic object write path and the associated object write callback mechanism.

To execute the test:

From the network controller, issue a Set_Attribute_Single request targeting:
- Class: 0x70
- Instance: 0x01
- Attribute: 0x381
Write a value greater than 0x64 (100 decimal).

Expected result:

The write callback is executed.
The application compares the received value against the configured emergency threshold (100).
When the value is greater than 100, the red emergency LED on the AM64x-EVM board turns ON.
When the value is less than or equal to 100, the red emergency LED turns OFF.

> LED Test

In the Linux host console, run LED_TEST start before performing the controller steps below.

Associated Attribute: 0x310

The LED test validates the cyclic network-to-target communication path.

To execute the test:

Establish an I/O connection by sending a ForwardOpen request using the following connection string:

200424012C652C64
This connection identifies:
- Output Assembly: 0x65
- Input Assembly: 0x64
Modify the first byte of the Output Assembly 0x65 process data. This byte is mapped to Attribute 0x310.

Expected result:

The updated value is received by the host application.
A console log message is displayed showing:
- The new value.
- The ON/OFF state of each LED represented by the individual bits.
The industrial LEDs on the host board are updated accordingly.

> T2N Test

In the Linux host console, run T2N_TEST start before performing the controller steps below.

Associated Attribute: 0x300

The T2N (Target-to-Network) test validates the cyclic target-to-network communication path.

To execute the test:

Establish an I/O connection by sending a ForwardOpen request using the following connection string:

200424012C652C64
Monitor the Input Assembly 0x64, which contains Attribute 0x300.

Expected result:

The application continuously updates the variable mapped to Attribute 0x300 in the background.
The data contained in Input Assembly 0x64 therefore changes continuously.
The network controller should observe the cyclic input data values changing over time without issuing any explicit read requests.

Protocol Specific Tests

Custom CIP Services Test

The custom CIP services can be tested directly from the network controller by issuing requests to the corresponding service codes.

Service 0x4B (Synchronous Service)

Target:
- Class: 0x70
- Instance: 0x00
- Service: 0x4B

Expected result:

The service responds synchronously.
If the service has been executed X times since startup, the response contains X bytes, each having the value X.
Example responses:

Request Count	Response Data
1	`0x01`
2	`0x02 0x02`
3	`0x03 0x03 0x03`

Service 0x4C (Asynchronous Service)

Target:
- Class: 0x70
- Instance: 0x01
- Service: 0x4C

Expected result:

The service response is provided asynchronously by the host application.
The returned buffer is filled with a repeating byte pattern.
The first request returns a buffer filled with 0xFF.
Each subsequent request decrements the byte value by one.

Request Count	Response Pattern
1	All bytes = `0xFF`
2	All bytes = `0xFE`
3	All bytes = `0xFD`
4	All bytes = `0xFC`

Connection Timeout Event Test

This test validates the EtherNet/IP connection timeout notification mechanism.

To execute the test:

Establish cyclic I/O communication by sending a valid ForwardOpen request.
Verify that cyclic data exchange is active.
Physically disconnect the network by unplugging the RJ45 cable from the TICS100MOD device.
Wait for the connection timeout period to expire.

Expected result:

The EtherNet/IP adapter detects that the I/O connection has timed out.
A log message is displayed in the host application console identifying the timed-out connection.
Cyclic communication for the affected connection stops.

Adapter Configuration Change at Runtime Test

This test validates the ability of the host application to modify selected EtherNet/IP adapter configuration objects at runtime.

TCP/IP Host Name Update

Execute the following command from the host application console:

SET_HOSTNAME <hostname>

Example:

SET_HOSTNAME MyAdapter

Expected result:

The adapter TCP/IP Host Name attribute is updated with the specified value.
A subsequent Get_Attribute_Single request targeting the corresponding TCP/IP object attribute returns the updated host name.

QoS Attribute Increment

Execute:

SET_QOS increment

Expected result:

All built-in QoS object attribute values are incremented by 1.
Reading the corresponding QoS attributes confirms the updated values.

QoS Attribute Decrement

Execute:

SET_QOS decrement

Expected result:

All built-in QoS object attribute values are decremented by 1.
Reading the corresponding QoS attributes confirms the updated values.

Reset Service Test

This test validates the built-in EtherNet/IP Reset service implementation.

To execute the test:

Using the network controller, issue a Reset service request to the device.
Select the desired reset type according to the reset flags supported by the adapter.

Expected result:

The requested reset operation is executed.
The adapter performs the reset behavior associated with the selected reset flag.
Following completion of the reset operation, the device returns to its expected operational state.

PROFINET Demo

The Profinet demo showcases both cyclic and acyclic data exchange between a Profinet controller (for example, a PLC) and the host application through the ICS software stack.

The demo uses 4 submodules from the gsd file used as the following:

Variable	Module	Sub Module	Record/ InOut
IDM_IOM_V1_IDS_TIO2_Input_IDT_TI2	IDM_IOM_V1	IDS_TIO2	Input
IDM_IOM_V1_IDS_TIO4_Output_IDT_TO4	IDM_IOM_V1	IDS_TIO4	Output
IDM_IOM_V1_IDS_IOM_MAP_IDT_MOD_Param_Dummy_Byte0	IDM_IOM_V1	IDS_IOM_MAP	IDT_MOD_Param
IDM_IM_V1_IDS_IM_MAP_IDT_MOD_Param_Dummy_Byte0	IDM_IM_V1	IDS_IM_MAP	IDT_MOD_Param

Tests

Common Tests

> Auto Increment Variable Test

Associated Variable: IDM_IOM_V1_IDS_IOM_MAP_IDT_MOD_Param_Dummy_Byte0

The auto increment variable test validates the acyclic object read path and the associated object read callback mechanism.

To execute the test:

From the network controller (for example, a PLC), repeatedly issue a Record Read request targeting:
- Module: IDM_IOM_V1
- SubModule: IDS_IOM_MAP
- Record Index: 4096
- Length : 16
  
  PLC READ RECORD
Observe the response value returned by the device.

Expected result:

The read callback is executed for every request.
The attribute value is incremented by 1 before the response is sent.
Each subsequent request therefore returns a value that is one greater than the value returned by the previous request.

> Emergency Variable Test

Associated Variable: IDM_IM_V1_IDS_IM_MAP_IDT_MOD_Param_Dummy_Byte0

The emergency variable test validates the acyclic object write path and the associated object write callback mechanism.

To execute the test:

From the network controller, issue a Record Write request targeting:
- Module: IDM_IM_V1
- SubModule: IDS_IM_MAP
- Record Index: 4096
- Length : 16
  
  PLC RECORD WRITE
Write a value greater than 0x64 (100 decimal).

Expected result:

The write callback is executed.
The application compares the received value against the configured emergency threshold (100).
When the value is greater than 100, the red emergency LED on the AM64x-EVM board turns ON.
When the value is less than or equal to 100, the red emergency LED turns OFF.

> LED Test

In the Linux host console, run LED_TEST start before performing the controller steps below.

Associated Variable: IDM_IOM_V1_IDS_TIO4_Output_IDT_TO4

The LED test validates the cyclic network-to-target communication path.

To execute the test:

Plug the Submodule IDM_IOM_V1\IDS_TIO4
Modify the value inside the PLC Watch
Observe the LEDs on the Board

> T2N Test

In the Linux host console, run T2N_TEST start before performing the controller steps below.

Associated Variable: IDM_IOM_V1_IDS_TIO2_Input_IDT_TI2

The T2N (Target-to-Network) test validates the cyclic target-to-network communication path.

To execute the test:

Plug the Submodule IDM_IOM_V1\IDS_TIO2
Watch the value auto incrementing in the PLC Watch

Protocol Specific Tests

> Diagnostics

The Diagnostics test validates a special type of acyclic communication:

To add a diagnostic you can execute this command from the host ALARM_TX_TEST add_diag n where n could be from 1 to 5
You can observe the diagnostic in the PRONETA tool

proneta diag
To remove an added diagnostic you can execute the command ALARM_TX_TEST remove_diag n where n could be from 1 to 5
you can observe the diagnostic disappearing in the PRONETA tool

proneta no diag

Table of Contents

Overview

Prerequisites

Hardware Setup

Host Environment Setup

Development Environment

Eclipse IDE

Arm GNU Toolchain

MinGW

AM64x Linux SDK Modifications

AM64x EVM preparation

Build

Runtime Preparation

Run

Test the Application

Common Tests

Console Interface

Auto Increment Variable Test

Emergency Variable Test

LED Test

T2N Test

Bus State Monitoring Test

EtherCAT SubDevice Demo

Starting the Demo

TwinCAT Setup

Common Application Features

LED Test

T2N Test

Emergency Variable Test

EtherCAT Specific Tests

File over EtherCAT (FoE)

Ethernet over EtherCAT (EoE)

ADS over EtherCAT (AoE)

Diagnostic Messages

Ethernet/IP Demo

Created Objects

Created Attributes

Created Assemblies

Created Custom CIP Services

Service 0x4B - Synchronous Custom Service

Service 0x4C - Asynchronous Custom Service

Tests

Common Tests

> Auto Increment Variable Test

> Emergency Variable Test

> LED Test

> T2N Test

Protocol Specific Tests

Custom CIP Services Test

Connection Timeout Event Test

Adapter Configuration Change at Runtime Test

TCP/IP Host Name Update

QoS Attribute Increment

QoS Attribute Decrement

Reset Service Test

PROFINET Demo

Tests

Common Tests

> Auto Increment Variable Test

> Emergency Variable Test

> LED Test

> T2N Test

Protocol Specific Tests

> Diagnostics