7.1.1. Introduction¶

7.1.2. DUAL_EMAC¶

ICSS DUAL EMAC FIRMWARE is a single port Ethernet MAC (Media Access Control) i.e. Layer 2 of OSI Model. It implements a 2 port ethernet mac supporting 10/100 Mbps. DUAL EMAC FIRMWARE is standardized to IEEE 802.1 Ethernet Standards. Primary use case of the protocol is to demonstrate basic ethernet functionality via both PRU cores on 10/100 Mbit Ethernet cable. ICSS DUAL EMAC FIRMWARE can be used independently on two PRU’s to implement two independent MAC’s with two different MAC addresses and two different IP addresses. To provide an analogy, this is somewhat similar to a two port Ethernet PCIe NIC card on a PC.Ethernet interface in this case is available along with Host processor on a single SoC. Following are high level features:

7.1.3. SWITCH¶

ICSS SWITCH FIRMWARE is a three port learning Ethernet switch i.e. Layer 2 of OSI Model. It implements a 2 port cut through ethernet switch supporting at 100 Mbps. SWITCH FIRMWARE is standardized to IEEE 802.1 Ethernet Standards. The primary use case of the protocol is to use Ethernet to automate applications which require short cut-through latency and low hardware costs. ICSS SWITCH FIRMWARE uses two PRU to implement three port Ethernet switch with one single MAC and IP address. To provide an analogy, this is somewhat standard network switch only here the network functionality is available to the host core within the single SOC. The following are the high level features it supports.

7.1.4. Code Organization¶

7.1.5. Firmware Build Instruction¶

Refer to the Processor SDK RTOS Building page for information on setting up build environment.

7.1.6. Supported EVMs¶

The following is a list of EVMS supported and the PRU-ICSS ethernet ports to be used:

7.1.7. Running ICSS-EMAC FIRMWARES Example¶

Please go through the following page for example demonstrating the use of the firmware via icss-emac driver. [1]

Firmware Design Guide

NOTE: For normal use case, there is no need to refer this document. Unless you wish to go through the internal working for firmware and/or wanted to modify it.

7.2.1. Introduction¶

7.2.2. DUAL_EMAC¶

ICSS DUAL EMAC FIRMWARE is a single port Ethernet MAC (Media Access Control) i.e. Layer 2 of OSI Model. It implements a 2 port Ethernet mac supporting 100Mbps and 1Gbps. DUAL MAC FIRMWARE is standardized to IEEE 802.1 Ethernet Standards. Primary use case of the protocol is to demonstrate basic Ethernet functionality via both PRU/RTU cores. ICSS-G DUAL EMAC FIRMWARE can be used independently on two PRUs to implement two independent MACs with two different MAC addresses and two different IP addresses.

Following are high level features:

7.2.3. Firmware Code Location and Build Instruction¶

Firmware is located at <PDK>packages/ti/drv/emac/firmware/icss_eth/src directory.

The CLPRU toolchain has to be used to build the firmware. The toolchain can be downloaded from <https://software-dl.ti.com/codegen/esd/cgt_public_sw/PRU/2.2.1/ti_cgt_pru_2.2.1_linux_installer_x86.bin>

To build the firmware:

• cd to <PDK>packages/ti/drv/emac/firmware/icss_eth/src directory
• make CLPRU_INSTALL_PATH=<dir_where_the_toolchain_installed>.

The firmware will be located in the <PDK>packages/ti/drv/emac/firmware/icss_eth/src/dm directory.

7.3.1. Introduction¶

7.3.2. Protocol Overview¶

The SORTE protocol is a TI-developed industrial Ethernet protocol that supports 4-µs cycle time. The SORTE protocol operates on the PRU-ICSS, which is an industrial peripheral within Sitara and KeyStone processors from Texas Instruments. SORTE protocol operates exclusively on the PRU-ICSS; therefore, the ARM Cortex-A8, A9 or A15 processors – depending on the device family – are available for industrial applications. The SORTE protocol differentiate between two network components: the master and one or more slave devices. For in depth details of the protocol please refer to the the design documents as listed in the References section below.

7.3.3. Code Organization¶

THE SORTE ARM application and firmware sources can be found under the following directory :

<PDK>/packages/ti/drv/pruss/example/apps/sorte/

Refer to the README.txt in this directory for details of directory layout.

In addition, there is a README.txt which provides high-level over of how the protocol is implmented for master and slave device network compoments which can be found at:

<PDK>/packages/ti/drv/pruss/example/apps/sorte/firmware/src/master/README.txt

<PDK>/packages/ti/drv/pruss/example/apps/sorte/firmware/src/slave/README.txt

7.3.4. Building the Examples¶

7.3.5. Supported EVMs¶

The following is a list of EVMS supported and the PRU-ICSS ethernet ports to be used:

7.3.6. Running the PRUSS SORTE Example¶

In order to run the SORTE applications, you will require 1 EVM running as master and 2 EVMs running as slave(slave1/slave2). Use CCS to load and run the master and slave applications respectively.

Prior to running the applications its best to connect the EVMS as follows:

Connect master Port0 to slave1 Port0. Connect slave1 Port1 to slave2 Port0.

Note that the master device will wait until it discovers 2 slave devices in the network. UART console on the master will print the following until 2 slave devices are detected:

sorte master: waiting for atleast 2 SLAVE devices connected

Once 2 slave devices are detected by the master, the following print will be seen on UART console and master will continue with state machine and protocol processing:

sorte master: 2 SLAVE devices connected

The slave device via the UART console will continuosly display the number of packets its received during input output exchange state of the protocol until pass criteria is reached as follows(as an example):

sorte slave: test in progress: current receive packet count: 35000

sorte slave: test in progress: current receive packet count: 40000

Once pass criteria number of packets have been received, the following print will be displayed on UART console:

All tests have passed

7.3.7. Additional Reference¶

7.4.1. Introduction¶

7.4.2. FIRMWARE FEATURES¶

I2C FW supports the standard two pin I2C interface through three GPIO pins from the PRU-ICSS module. The I2C SCL pin is implemented using a single GPIO configured in GPO mode. The I2C SDA pin is implemented using two GPIO pins: one pin configured in GPI mode for sampling SDA, and a second pin configured in GPO mode for driving the SDA. Depending on the I2C clock speed, I2C FW can emulate multiple I2C instances from a single PRU core. Following are high-level I2C FW features:

7.4.3. Firmware Organization¶

7.4.4. Firmware Build Instruction¶

7.4.5. Supported EVMs¶

Supported EVMs and pin configurations for these EVMs are listed below.

icev2AM335x

idkAM437x

idkAM572x/idkAM574x

7.4.6. I2C FIRMWARE Example¶

Sample code for I2C transaction:

/* Refer to I2C FW Example for details */
...

/* Initialize the I2C FW configuration */
I2C_socInitFwCfg();

/* Get the default I2C init configuration */
I2C_socGetFwCfg(I2C_TEST_INSTANCE1, &i2c_cfg);

/* Modify the default I2C configurations if necessary */

/* Set the default I2C init configurations */
I2C_socSetFwCfg(I2C_TEST_INSTANCE1, &i2c_cfg);
...

Board_init(boardCfg);
...

I2C_init();

handle = I2C_open(I2C_TEST_INSTANCE1, &i2cParams);
...

/* Initiate I2C transfers */
I2C_transactionInit(&i2cTransaction);
i2cTransaction.slaveAddress = I2C_EEPROM_ADDR;
...

status = I2C_transfer(handle, &i2cTransaction);
if (status!= I2C_STS_SUCCESS) {
    /* I2C transaction failed */
}

Sample code for SMBus transaction:

/* Refer to I2C FW Test for details */
...

testCmd.transferCmd = SMBUS_WRITE_BYTE_CMD;
testCmd.cmdCode = WRITE_SMBUS_COMMAND_CODE;
controlStatus = I2C_control(handle, I2C_CMD_SMBUS_TYPE, ((void*)&testCmd));
I2C_transactionInit(&i2cTransaction);
...

status = I2C_transfer(handle, &i2cTransaction);
if (status != I2C_STS_SUCCESS) {
    /* I2C transaction failed */
}

Examples List

Refer to the Release Notes for details concerning I2C support across different EVMs.

Firmware Design Guide

NOTE: For normal use of I2C FW, there is no need to refer to the design guide. This document can be cosulted in case of interest in details of internal firmware operation, or a desire to modify the firmware.