MCUSW
Eth & EthTrcv User Guide

Introduction

This document details AUTOSAR BSW ETH & ETHTRCV module implementations

  • Supported AUTOSAR Release : 4.3.1
  • Supported Configuration Variants : Pre-Compile/LinkTime/PostBuild for Eth and Pre-Compile for EthTrcv
  • Vendor ID : ETH_VENDOR_ID (44), ETHTRCV_VENDOR_ID (44)
  • Module ID : ETH_MODULE_ID (88), ETHTRCV_VENDOR_ID (73)

The ETH module initializes, configures and controls the Gigabit Ethernet Switch (CPSW) in the Jacinto (J7xx) as well as SITARA MPU (AM6xx) device families as detailed in the AUTOSAR BSW ETH Driver Specification.

The ETHTRCV module initializes and configures the Ethernet transceiver (PHY) as detailed in the AUTOSAR BSW ETHTRCV Driver Specification.

Attention
The ETHTRCV driver is provided only for testing purposes on TI EVM as it only supports DP83867.

Following section highlights key aspects of this implementation, which would be of interest to an integrator.

Supported SoCs

SoC Family Supported SoCs CPSW instances
Jacinto J721E, J7200, J721S2, J784S4 CPSW2G

Back To Top

SDK/PDK dependency

None

Back To Top

Eth Driver Architecture/Design

Please refer the ETH design page, which is included as part of release [3].

Functional Description

This ETH driver implementation supports the Gigabit Ethernet Switch (CPSW) peripheral present in the devices listed in Supported SoCs section.

Depending on the device's CPSW instance, the CPSW peripheral has either 1 (port 1) or 2 (port 1 and port 2) Ethernet port which supports RGMII and RMII interfaces, and a host port (port 0) which supports the internal Communications Port Programming Interface (CPPI).

The ETH driver uses the UDMA (Jacinto devices) or DMSS (Sitara MPU) to setup data transfers to/from the CPPI port.

The ETH driver implements single DMA channel for data transmission and single channel (flow) for data reception. Only the CPSW default thread ID is enabled and configured according to the DMA receive channel's default flow. Interrupts can be enabled for DMA transmit and receive completion events.

The DMA transfers are based on descriptors called Host Mode Packet Descriptors (HMPD). The descriptors are given to and retrieved from the UDMA via Ring Accelerators. There are three rings used per data direction in this implementation:

  • Transmit
    • Free Queue Ring - Descriptors with the address and length of the buffers to be transmitted are queued into this ring. In normal conditions, only CPSW will dequeue descriptors from this queue.
    • Completion Queue Ring - Descriptors that correspond to Ethernet frames which have already been consumed by the CPSW are placed in this queue. CPSW is the producer and host is the consumer of this ring.
    • Tear-down Completion Queue Ring - This ring is used only when the UDMA channel is torn down.
  • Receive
    • Free Queue Ring - Descriptors with the address and length of free buffers to be filled with incoming Ethernet frames are queued into this ring. In normal conditions, only the CPSW will dequeue descriptors from this queue.
    • Completion Queue Ring - Descriptors that correspond to buffers filled with new data from incoming Ethernet frames are placed in this queue. CPSW is the producer and host is the consumer of this ring.
    • Tear-down Completion Queue Ring - This ring is used only when the UDMA channel is torn down.

The depth of each ring as well as its associated memory is configurable. The ring memories can be any memory in the system, but it's recommended that they are placed in a fast memory (i.e. OCMRAM or MSMC3). The depth of these rings is determined by the number of TX and RX buffers set in the driver configuration (EthCtrlConfigEgress/EthCtrlConfigEgressFifo and EthCtrlConfigIngress/EthCtrlConfigIngressFifo).

Similarly, the HMPDs can be placed in any memory of the system, but it's recommended that they are placed in OCMRAM or MSMC3 as well.

The Management Data I/O interface (MDIO) of the CPSW peripheral is used by the ETH driver to implement the MII register read and write APIs which are ultimately used by the ETHTRCV driver to configure the Ethernet transceiver (PHY). The ETH driver handles the MDIO interrupt which indicates the completion event of the Ethernet transceiver register accesses.

The Address Lookup Engine (ALE) of the CPSW peripheral is used by the ETH driver to implement the receive filter API. The ALE provides 64 entries that can be used to set filter rules.

The Statistics submodule of the CPSW peripheral is used by the ETH driver to implement the statistics and drop count APIs.

Back To Top

Ethernet interrupt to ISR mapping

The following table lists the mapping between Ethernet interrupts and the corresponding interrupt service routines.

Interrupt Number Description Associated ISR
Configurable DMA RX Completion Eth_RxIrqHdlr_0
Configurable DMA TX Completion Eth_TxIrqHdlr_0
35 (Jacinto) / 135 (Sitara MPU) MDIO Access Completion Eth_MdioIrqHdlr_0

The DMA interrupt numbers can be set via the Ethernet driver configuration parameters EthDmaTxChIntrNum and EthDmaRxChIntrNum.

The table below summarizes the interrupt ranges allocated by default in TI SDK for the SoCs and the processing cores where the MCAL ETH driver is supported.

SOC Starting Resource (Value) Range
J7xx Devices MCU0_INTR_NAVSS0_R5_0_PEND_0 (74) 9

The interrupt numbers passed to the Ethernet driver configuration must be within the range stated above for each device, otherwise the interrupt allocation will fail while enabling the Ethernet controller.
Please refer to the UDMA Driver Resource Manager allocation for further details.

There are no interrupts in the ETHTRCV module.

Back To Top

Configuration

Configuration files struture

The Eth Driver implementation in this release supports the Pre-Compile/LinkTime/ PostBuild configuration variant.

The driver expects generated: Eth_Cfg.h, Eth_Cfg.c, Eth_Lcfg.c and Eth_PBcfg.c to be present at the locations specified in the Eth File Structure section.

The EthTrcv Driver implementation only supports the Pre-Compile variant.

The driver expects generated EthTrcv_Cfg.h and EthTrcv_Cfg.c to be present at the locations specified in the EthTrcv File Structure section.

DMA configuration guideline

Use sysconfig tools to open your sysconfig file to get all DMA information

eth_ug_dma_resource_allocation_markdown.png
Ethernet DMA resource allocation detail


Native Eth Driver - EthDmaConfig Container

Look at the column MCU_0_R5_0 to get DMA information for Rx channel, Tx channel, Rx Ring, Rx Flow, Virtual Intertupt,Global Event

  • EthDmaTxChStartNum - equal MCU NAVSS UDMA Normal capacity Tx channels
  • EthDmaRxChStartNum - equal MCU NAVSS UDMA Normal capacity Rx channels
  • EthDmaRingStartNum - equal MCU NAVSS Ring accelerator Free rings
  • EthDmaFlowStartNum - equal MCU NAVSS UDMA Rx free flows
  • EthDmaVirtualIntrStartNum - equal MCU NAVSS Interrupt aggregator Virtual interrupts
  • EthDmaGlobalStartNum - equal MCU NAVSS Interrupt aggregator Global events

Virtual Eth Driver - EthVirtMacDmaConfig Container

Look at the column MAIN_0_R5_2 to get DMA information for Tx channel, Rx Ring, Rx Flow, Virtual Intertupt, Global Event

  • EthDmaTxChStartNum - equal Main NAVSS UDMA Normal capacity Tx channels
  • EthDmaRingStartNum - equal Main NAVSS Ring accelerator Free rings
  • EthDmaVirtualIntrStartNum - equal MAIN NAVSS Interrupt aggregator Virtual interrupts
  • EthDmaGlobalStartNum - equal MAIN NAVSS UDMA Interrupt aggregator Global events

DMA Initilization

The Ethernet driver will not initialize all DMA resources such as Rings, TX channel, Rx Chanlel, RX flows, etc.
Bootloader or application code must take care of initializating all such DMA resources.
Please refer to sdk_path/mcusw/mcal_drv/mcal/examples/utils/src/app_utils_eth.c for reference implementation.

Multiple Controller and QoS Resource CPSW3G

CPSW DMA resource need to be shared with MCU0_0 core to support multiple controller and QoS.

eth_ug_am62px_dma_sharing.png
AM62PX CPSW DMA sharing


After the resource sharing change, DMA resouce need to be changed from normal DMA to CPSW DMA(Tx/Rx/Ring/Flow) in plugin configuration.

eth_ug_am62px_dma_configuration.png
AM62PX CPSW DMA configuration


Back To Top

IRQ pacing configuration guideline

IRQ pacing support to reduce number of hardware IRQ raise due to high load enviroment. IRQ pacing support for TX/RX separately, below are IRQ pacing configuration parameters

  • EthHwTimerClockFreq: hardware timer clock frequency
  • EthRxHwTimerId: Rx hardware timer Id, check TRM session Timers to see how many free hardware timer this timer must not be used by other modules(Os counter, GPT)
  • EthTxHwTimerId: Tx hardware timer Id, check TRM session Timers to see how many free hardware timer this timer must not be used by other modules(Os counter, GPT)
  • EthRxHwIrqPacingInterval: Rx IRQ pacing interval (in milliseconds)
  • EthTxHwIrqPacingInterval: Tx IRQ pacing interval (in milliseconds)

The table below summarizes the hardware timer ID ranges allocated by default in TI SDK for the SoCs and the processing cores where the MCAL ETH driver is supported.

SOC MCU MAIN
J7xx Devices MCU_TIMER0 -> MCU_TIMER9 TIMER0 -> TIMER19

The following table lists the mapping between Ethernet interrupts and the corresponding interrupt service routines.

Interrupt Number Description Associated ISR
Configurable (base on Rx hardware timer ID) Rx overflow timer interrupt Eth_RxIrqPacingHdlr_0
Configurable (base on Tx hardware timer ID) Tx overflow timer interrupt Eth_TxIrqPacingHdlr_0

The table below summarizes the interrupt ranges allocated by default in TI SDK for the SoCs and the processing cores where the MCAL ETH driver is supported. J7xx Devices

Domain Starting Resource (Value) Range
MCU MCU_TIMER0_INTR_PEND_0 -> MCU_TIMER4_INTR_PEND_0 38 -> 41
MCU MCU_TIMER5_INTR_PEND_0 -> MCU_TIMER9_INTR_PEND_0 108 -> 113
MAIN TIMER0_INTR_PEND_0 -> TIMER19_INTR_PEND_0 108 -> 127

Cpsw Mdio Errata i2329 Manual Mode Delay Math

In devices impacted by errata i2329 (such as J721E, J7200, J721S2, AM62x), it is possible that MDIO interface returns corrupt data or sends incorrect data on MDIO reads and writes. It is also possible that MDIO becomes unavailable until next peripheral reset.

The workaround for this is to emulate MDIO by reading and writing to the appropriate bits within the MDIO_MANUAL_IF_REG register of the MDIO peripheral to directly manipulate MDIO clock and data pins.

After timing the workaround on the different boards, it was discovered that the current implementation without additional delays will occur such that the read and write edges will generates times such that High Read signal duration >= High Write signal duration >= Low Read signal duration == Low Write signal duration.

As a result, adding delay manually to the read and write signals while attempting to achieve 50% duty cycles will be broken into the following scenarios:

  • First, delay the Write Low signal to achieve the same duration as the Write High signal.
  • Second, delay both the Write Low and Write High signals equally to have the full Write period achieve the same duration as a full Read period.
  • Third, delay the Read Low signal until its the duration is the same as the Read High signal duration. During this time, delay the Write Low and Write High signals equally to maintain the full Write period the same duration as the full Read period.
  • Last, delay Read Low, Read High, Write Low, and Write High signals equally to maintain equal read and write periods and 50% duty cycle.

These additional delay scenarios will be expanded on in later subsections.

The measured base durations and the recommended delay durations for each of the signals will be provided with the targeted boards, but the real-world times could be slightly different due to many factors. During testing, it was seen that the theoretical delay times are about 10% too much than the real-world measurements.

As a result, users will be able to fine tune all the signal base and delay time macros and the multiplicative error factors on top of the recommended values.

The detailed math will be explained below, with provided macros and some additional helper variables for the math:

ETH plugin parameters:

  • EthMdioWriteLowBaseNsec - undelayed write low signal duration in nanoseconds (fixed per SoC)
  • EthMdioWriteHighBaseNsec - undelayed write high signal duration in nanoseconds (fixed per SoC)
  • EthMdioReadLowBaseNsec - undelayed read low signal duration in nanoseconds (fixed per SoC)
  • EthMdioReadHighBaseNsec - undelayed read high signal duration in nanoseconds (fixed per SoC)
  • EthMdioWriteLowDelayNsec - write low signal delay in nanoseconds (from user input, with recommended value per SoC at 2MHz)
  • EthMdioWriteHighDelayNsec - write high signal delay in nanoseconds (from user input, with recommended value per SoC at 2MHz)
  • EthMdioReadLowDelayNsec - read low signal delay in nanoseconds (from user input, with recommended value per SoC at 2MHz)
  • EthMdioReadHighDelayNsec - read high signal delay in nanoseconds (from user input, with recommended value per SoC at 2MHz)

Helper Variables:

  • wPeriod - period of base write cycle (= EthMdioWriteHighBaseNsec + EthMdioWriteLowBaseNsec)
  • wOffset - offset/difference to 50% write duty cycle (= EthMdioWriteHighBaseNsec - EthMdioWriteLowBaseNsec)
  • rPeriod - period of base read cycle (= EthMdioReadHighBaseNsec + EthMdioReadLowBaseNsec)
  • rOffset - offset/difference to 50% read duty cycle (= EthMdioReadHighBaseNsec - EthMdioReadLowBaseNsec)
  • wDutyPatch - extends the write duty to 50% read period (= rPeriod / 2 - EthMdioWriteHighBaseNsec)
  • wDutyExtraPatch - further extends the write duty to read duty duration after wDutyPatch (= EthMdioReadHighBaseNsec - rPeriod / 2)

Scenario 0: No Delay: Highest MDIO Clock Frequency

eth_mdio_errata_scenario_0.png
MDIO Delay Scenario 0

No additional delays added, paced by MDIO register read/write latency.

Condition: N/A, but notice that the highest frequency means the target period cannot be smaller than wPeriod (since target period = 1 / target frequency). Also notice that RH >= WH >= RL == WL.

  • EthMdioWriteLowDelayNsec = 0
  • EthMdioWriteHighDelayNsec = 0
  • EthMdioReadLowDelayNsec = 0
  • EthMdioReadHighDelayNsec = 0

Scenario 1: Delay Until MDIO Clock has 50% Duty Cycle in Register Write

eth_mdio_errata_scenario_1.png
MDIO Delay Scenario 1

Condition: wPeriod <= target period <= wPeriod + wOffset

  • EthMdioWriteLowDelayNsec = (target period - wPeriod)
  • EthMdioWriteHighDelayNsec = 0
  • EthMdioReadLowDelayNsec = 0
  • EthMdioReadHighDelayNsec = 0

Scenario 2: Delay Until Same MDIO Clock Frequency in PHY Register Read and Write

eth_mdio_errata_scenario_2.png
MDIO Delay Scenario 2

Condition: wPeriod + wOffset <= target period <= rPeriod

  • EthMdioWriteLowDelayNsec = wOffset + (target period - wPeriod - wOffset) / 2
  • EthMdioWriteHighDelayNsec = (target period - wPeriod - wOffset) / 2
  • EthMdioReadLowDelayNsec = 0
  • EthMdioReadHighDelayNsec = 0

Scenario 3: Delay Until MDIO Clock Frequency has 50% Duty Cycle in PHY Register Read and Write

eth_mdio_errata_scenario_3.png
MDIO Delay Scenario 3

Condition: rPeriod <= target period <= rPeriod + rOffset

  • EthMdioWriteLowDelayNsec = wOffset + wDutyPatch + (target period - rPeriod) / 2
  • EthMdioWriteHighDelayNsec = wDutyPatch + (target period - rPeriod) / 2
  • EthMdioReadLowDelayNsec = (target period - rPeriod)
  • EthMdioReadHighDelayNsec = 0

Scenario 4: Delay After MDIO Clock Frequency has 50% Duty Cycle in PHY Register Read and Write

eth_mdio_errata_scenario_4.png
MDIO Delay Scenario 4

Condition: rPeriod + rOffset <= target period

  • EthMdioWriteLowDelayNsec = wOffset + wDutyPatch + wDutyExtraPatch + (target period - rPeriod - rOffset) / 2
  • EthMdioWriteHighDelayNsec = wDutyPatch + wDutyExtraPatch + (periodNs - rPeriod - rOffset) / 2
  • EthMdioReadLowDelayNsec = rOffset + (periodNs - rPeriod - rOffset) / 2
  • EthMdioReadHighDelayNsec = (periodNs - rPeriod - rOffset) / 2

Zero Copy Transmission

The current ETH driver implementation supports zero copy API to reduce memory copy operation for transmission path. In normal case user will ask driver for transmition buffer by using API Eth_ProvideTxBuffer, driver will find free buffer and return that buffer to user, and user can fill their data(i.e. via memcpy) and call Eth_Transmit API to transmit ETH frame.

When zero copy API is enabled (via configurator), user can use the API Eth_ProvideExtTxBuffer with buffer pointer is an external buffer or user buffer (not from internal ETH driver), with this way user will prevent one unnecessary memory copy operation. After that user calls Eth_Transmit API to transmit ETH frame as usual.

Note: Eth_ProvideExtTxBuffer API is not a standard MCAL ETH function

Variance / Deviation from the specification

Ethernet Switch Interface

The driver doesn't call Ethernet Switch Interface APIs.

Back To Top

Ethernet Transceiver Wake-Up

The wake-up related APIs are not implemented in this release:

  • EthTrcv_SetTransceiverWakeupMode()
  • EthTrcv_GetTransceiverWakeupMode()
  • EthTrcv_CheckWakeup()

The wake-up related functionality of other non wake-up specific APIs (i.e. EthTrcv_TransceiverInit(), EthTrcv_SetTransceiverMode(), etc) are not implemented in this release either.

Back To Top

Ethernet Transceiver Manual/Auto-Negotiation Mode

The current EthTrcv driver implementation only supports auto-negotiation mode. The following APIs are impacted and partial functionality of the API is implemented:

Back To Top

Ethernet Transceiver ECUC

The following EthTrcv ECUC APIs are not implemented in this release:

  • EthTrcvPhysLayerType
  • EthTrcvConnNeg
  • EthTrcvMainFunctionPeriod

Back To Top

Non Standard Service APIs

None.

Back To Top

Interrupt Configuration

The Ethernet driver doesn't register any interrupt handlers (ISR), it is expected that consumer of this driver registers the required interrupt handler.

The Ethernet interrupts are:

  • TX DMA Completion - Asserted when a packet has been consumed by CPSW for transmission. The interrupt number is configurable and is passed via Ethernet configuration parameters. Please refer to the resource partitioning information for further details about what interrupt numbers are allocated for the MCU
  • RX DMA Completion - Asserted when a packet has been received. The interrupt number is configurable and is passed via Ethernet configuration parameters. Please refer to the resource partitioning information for further details about what interrupt numbers are allocated for the MCU
  • MDIO Access Completion - Asserted when an Ethernet transceiver (PHY) register read or write operation is complete. The interrupt number is 35 (Jacinto) / 135 (Sitra MPU)

Other CPSW interrupts (like the Statistics Pending interrupt) are not handled by the driver.

Please refer to the EthApp_InterruptConfig() function in Eth demo application for the implementation details of the interrupt registration.

Back To Top

Power-up

The driver doesn't configure the functional clock and power for the Ethernet module. It is expected that a Secondary Bootloader (SBL) or a Secondary Program loadeder (SPL) powers up and initialized the required modules.

When running the Ethernet driver MCAL example test application in Sitara MPU, it is recommened to use the SBL for SOC Initialization instead of SPL, since running the linux and side loading the Eth MCAL may have some conflict in resource usage.

Back To Top

Packet Timestamping

Eth driver supports timestamping of PTP packets only. The gPTP multicast address(es) have to be explicitly added to the RX filter through Eth_UpdatePhysAddrFilter() by the upper layer in order for the gPTP multicast packets not to be dropped.

Back To Top

Build and Running the Application

Please follow steps detailed in section (Build) to build library or example.

Building the host-side example application

The GCC compiler is required to build the host-side application.

The steps to build the host-side application in Linux are listed below:

$ cd mcal_drv/mcal/examples/Eth/eth_test_app/host/
$ make

Building the target-side example application in loopback mode

The Eth example application can run an internal loopback test when configured accordingly in the driver's configuration parameters.

The example application per se doesn't need any change for loopback, but the loopback parameter must be set to TRUE as shown below. The example application can then be rebuilt following the regular steps listed in Build.

Pre-Compile Variant

diff --git a/mcal_drv/mcal/examples_config/Eth_Demo_Cfg/output/generated/soc/j721e/mcu1_0/include/Eth_Cfg.h b/mcal_drv/mcal/examples_config/Eth_Demo_Cfg/output/generated/soc/j721e/mcu1_0/include/Eth_Cfg.h
index 069e3ff69..cb9cf4af7 100644
bbb a/mcal_drv/mcal/examples_config/Eth_Demo_Cfg/output/generated/soc/j721e/mcu1_0/include/Eth_Cfg.h
+++ b/mcal_drv/mcal/examples_config/Eth_Demo_Cfg/output/generated/soc/j721e/mcu1_0/include/Eth_Cfg.h
@@ -370,7 +370,7 @@ extern "C" {
#define Eth_GetMacAddressLow(CtrlIndex) ( 0xeeffU )
#define Eth_UseDefaultMacAddress(CtrlIndex) ( TRUE )
#define Eth_GetMiiConnectionType(CtrlIndex) ( ETH_MAC_CONN_TYPE_RGMII_FORCE_1000_FULL )
-#define Eth_GetLoopBackMode(CtrlIndex) ( FALSE )
+#define Eth_GetLoopBackMode(CtrlIndex) ( TRUE )
#define Eth_GetHardwareLoopTimeout(CtrlIndex) ( 32000U )
#define Eth_IsPacketMemCacheable(CtrlIndex) ( TRUE )
#define Eth_IsRingMemCacheable(CtrlIndex) ( TRUE )

LinkTime/PostBuild Variant

diff --git a/mcal_drv/mcal/examples_config/Eth_Demo_Lcfg/output/generated/soc/j721e/mcu1_0/src/Eth_Lcfg.c b/mcal_drv/mcal/examples_config/Eth_Demo_Lcfg/output/generated/soc/j721e/mcu1_0/src/Eth_Lcfg.c
index 423b34d02..b10a2f0f2 100644
--- a/mcal_drv/mcal/examples_config/Eth_Demo_Lcfg/output/generated/soc/j721e/mcu1_0/src/Eth_Lcfg.c
+++ b/mcal_drv/mcal/examples_config/Eth_Demo_Lcfg/output/generated/soc/j721e/mcu1_0/src/Eth_Lcfg.c
@@ -544,7 +544,7 @@ CONST(Eth_ControlerConfigType, ETH_VAR_NO_INIT) EthConfig_0_Controler_0 =
/* macAddrLow */ 0xeeffU,
/* useDefaultMac */ TRUE,
/* connType */ ETH_MAC_CONN_TYPE_RGMII_FORCE_1000_FULL,
- /* loopback */ FALSE,
+ /* loopback */ TRUE,
/* hwLoopTimeout */ 32000U,
/* mdioBusFreqHz */ 2200000U,
/* mdioOpMode */ ETH_MDIO_OPMODE_MANUAL,

Back To Top

Steps to run example application

Running the loopback test

In order to run the loopback test, it's required to set the Ethernet driver's 'loopback' configuration parameter to TRUE as described in Building the target-side example application in loopback mode. In loopback mode, CPSW is configured with ALE in bypass mode and loopback is enabled in the MAC port (port 1).

This test doesn't require any additional external setup and the example can run standalone on the device. The example application will transmit and receive 1000 frames, and will verify the frame content.

Running the default (non-loopback) test

This test consists of two applications: host-side application that runs on a Linux machine, and a target-side application that is loaded to the device (DUT).

Please refer to the Building the host-side example application section for instructions to build the host-side application.

  1. Connect a CAT5e/CAT6 Ethernet cable to the MCU ETHERNET connector of the DUT and to the PC's Ethernet port
  2. Disconnect from Linux's Network Manager the PC Ethernet interface to ensure that only the raw the raw traffic is to/from DUT and host PC apps
    • This is needed because the test app uses a rundimentary L2 handshaking to run the test cases.
    • List the available interface and identify the interface to be used for testing
      $ nmcli device status
    • Disconnect the interface from NM, i.e eno1:
      $ nmcli device disconnect eno1
  3. Put the host-side interface in promiscuous mode in order to receive VLAN tagged packets sent by the DUT.
    $ ifconfig <interface> promisc
  4. Run the host-side application with root privileges (needed for raw sockets) and specify the interface name to be used, for instance:
    $ cd mcal_drv/mcal/examples/Eth/eth_test_app/host/
    $ sudo ./EthHostTestApp -i <interface>
  5. At this point, the host-side application will be waiting for the DUT
  6. Load the target-side application to the device and run it. The host-side application should detect that the device is now ready and all tests will be run (including frame transmission with and without confirmation, frame reception, filtering MAC addresses, transmission and reception of VLAN tagged packets, transmit throughput, etc)
  7. Check the logs printed in the Linux terminal and verify that the host-side application didn't report any errors
  8. Check the logs printed in the serial console (or CCS console if UART is not enabled) and verify that the target-side application didn't report any errors
  9. Put the host-side interface back in non-promiscuous mode.
    $ ifconfig <interface> -promisc

The example applications on either side (host or target) will report a fail status if any test Ethernet frames is lost. So even frames which are lost due to physical link will cause the example application to report as a failure.

Back To Top

Memory Mapping

Various objects of this implementation (e.g. variables, functions, constants) are defined under different sections. The linker command file at (Examples Linker File (Select memory location to hold example binary)) defines separate section for these objects. When the driver is integrated, it is expected that these sections are created and placed in appropriate memory locations. (Locations of these objects depend on the system design and performance needs)

Section ETH_CODE ETH_VAR ETH_VAR_NOINIT ETH_CONST ETH_CONFIG ETH_UDMA_RING ETH_UDMA_DESC ETH_TX_DATA ETH_RX_DATA
ETH_TEXT_SECTION USED
ETH_ISR_TEXT_SECTION USED
ETH_CONST_32_SECTION USED
ETH_CONFIG_SECTION USED
ETH_DATA_INIT_UNSPECIFIED_SECTION USED
ETH_DATA_NO_INIT_UNSPECIFIED_SECTION USED
ETH_UDMA_RING_SECTION USED
ETH_UDMA_DESC_SECTION USED
ETH_TX_DATA_SECTION USED
ETH_RX_DATA_SECTION USED


Section ETHTRCV_CODE ETHTRCV_VAR ETHTRCV_VAR_NOINIT ETHTRCV_CONST ETHTRCV_CONFIG
ETHTRCV_TEXT_SECTION USED
ETHTRCV_CONST_32_SECTION USED
ETHTRCV_CONFIG_SECTION USED
ETHTRCV_DATA_INIT_UNSPECIFIED_SECTION USED
ETHTRCV_DATA_INIT_32_SECTION USED
ETHTRCV_DATA_NO_INIT_UNSPECIFIED_SECTION USED
ETHTRCV_DATA_NO_INIT_16_SECTION USED

Back To Top

Cache

This driver implementation has been validated with cache enabled. For optimal performance it's recommended to place (Memory Mapping) sections in cache enabled memory area.

The Ethernet driver supports ring and descriptor memory placement in non-cached memory. It's configurable through the following parameters:

  • EthRingInCachedMem - Cache management operations will be performed in ring memory only if this parameter is set.
  • EthDescInCachedMem - Cache management operations will be performed in descriptor memory only if this parameter is set.

Cache management operations refer to invalidate, write-back and write-back invalidate calls.

Back To Top

Dependencies on SW Modules

DET

This implementation depends on the DET in order to report development errors and can be turned OFF. Refer to the Development Error Reporting section for detailed error codes.

Back To Top

SchM

This implementation requires 1 level of exclusive access to guard critical sections. Invokes SchM_Enter_Eth_ETH_EXCLUSIVE_AREA_0(), SchM_Exit_Eth_ETH_EXCLUSIVE_AREA_0() to enter critical section and exit.

In the example implementation (SchM_Eth.c), all the interrupts on CPU are disabled. However, disabling of the enabled Ethernet related interrupts should suffice.

Back To Top

File Structure

Eth File Structure

eth_ug_dir_detailed.png
Ethernet Detailed Directory Structure
  • Ethernet driver
    • Driver:
      • include: Eth.h, Eth_Irq.h, Eth_LL.h, Eth_LL_Types.h, Eth_Packet.h, Eth_Types.h, Eth_VirtMac.h
      • src: Eth.c, Eth_Irq.c, Eth_Packet.c, Eth_Priv.c, Eth_Priv.h, Eth_Rpc.c, Eth_Rpc.h, Eth_RpcPriv.h, Eth_VirtMac.c, Eth_IrqPacing.h, Eth_IrqPacing.c, udma/*, csl/*, and cpsw/*
    • Example Configuration:
      • include: Eth_Cfg.h
      • src: Eth_Cfg.c, Eth_Lcfg.c, Eth_PBcfg.c
    • Example Application by: EthApp.c, EthUtils.c, EthUtils.h and EthUtils_Patterns.h

EthTrcv File Structure

ethtrcv_ug_dir_detailed.png
Ethernet Transceiver Detailed Directory Structure
  • Ethernet Transceiver driver
    • Driver implemented by: EthTrcv.c, EthTrcv_Priv.c, EthTrcv.h and EthTrcv_Priv.h
    • Example Configuration by: EthTrcv_Cfg.c and EthTrcv_Cfg.h
    • Example Application is common for Eth and EthTrcv

Back To Top

Error Handling

Development Error Reporting

Development errors are reported to the DET using the service Det_ReportError(), when enabled. The driver interface files (Eth.h and EthTrcv.h shown in the driver directory structure of the File Structure section) lists the service IDs.

Back To Top

Error codes

Production error are reported to DET via Det_ReportError(). Only the error codes in the Ethernet and Ethernet Transceiver driver specifications are reported which are listed below. There are no implementation specific error codes being reported.

Ethernet driver error codes

Type of Error Related Error code Value (Hex)
Invalid controller index ETH_E_INV_CTRL_IDX 0x01
Eth module was not initialized ETH_E_UNINIT 0x02
Invalid pointer in parameter list ETH_E_PARAM_POINTER 0x03
Invalid parameter ETH_E_INV_PARAM 0x04
Initialization failure ETH_E_INIT_FAILED 0x05
Invalid mode ETH_E_INV_MODE 0x06

Ethernet Transceiver driver error codes

Type of Error Related Error code Value (Hex)
Invalid transceiver index ETHTRCV_E_INV_TRCV_IDX 0x01
EthTrcv module was not initialized ETHTRCV_E_NOT_INITIALIZED 0x02
Invalid pointer in parameter list ETHTRCV_E_PARAM_POINTER 0x03
Initialization failure ETHTRCV_E_INIT_FAILED 0x04

Back To Top

Production Code Error Reporting

Production error are reported to DEM via the service DEM_ReportErrorStatus(). There are no implementation specific error codes being reported. Only the error codes in the Ethernet and Ethernet Transceiver driver specifications are reported which are listed below.

Type of Error Related Error code
Ethernet Controller Access Failure ETH_E_ACCESS
Ethernet Frames Lost ETH_E_RX_FRAMES_LOST
CRC Failure ETH_E_CRC
Frame Size Underflow ETH_E_UNDERSIZEFRAME
Frame Size Overflow ETH_E_OVERSIZEFRAME
Frame Alignment Error ETH_E_ALIGNMENT
Single Frame Collision ETH_E_SINGLECOLLISION
Multiple Frame Collision ETH_E_MULTIPLECOLLISION
Late Frame Collision ETH_E_LATECOLLISION


Type of Error Related Error code
Ethernet Transceiver Access Failure ETHTRCV_E_ACCESS

Back To Top

API Description

The AUTOSAR BSW Eth Driver specification details the APIs [1].

The AUTOSAR BSW EthTrcv Driver specification details the APIs [2].

The wake-up related APIs are not implemented in this release. Refer to the Ethernet Transceiver Wake-Up section for more details on impacted APIs.

The wake-up related functionality of other non wake-up specific APIs (i.e. EthTrcv_TransceiverInit(), EthTrcv_SetTransceiverMode(), etc) are not implemented in this release either.

The current EthTrcv driver implementation only supports auto-negotiation mode. Refer to the Ethernet Transceiver Manual/Auto-Negotiation Mode section for more details on the impacted APIs.

The following EthTrcv ECUC APIs are not implemented in this release. Refer to Ethernet Transceiver ECUC section for more details.

Back To Top

Example Application

The example application demonstrate use of Eth module. The example consists of an application that runs on the Supported SoCs device (DUT) and an application that runs on a Linux PC (host). The host and target (DUT) applications communicate with each other to start the different stages of the example tests.

The Eth example relies on shared utils which provide helper functions (i.e. filling an Ethernet frame with test data, verifying frame contents, etc) which are useful on the DUT and host sides.

The following table summarizes the different tests implemented by the example application.

Test ID Summary Description
test_0001 Basic DUT frame reception Host will send 1000 Ethernet frames, the DUT will receive and verify that the frame content matches the expected patterns
test_0002 Basic DUT frame transmission The DUT will send 1000 non-VLAN tagged frames without TX confirmation. The host PC will check that all frames are received and that the frame content matches the expected patterns
test_0003 External loopback The DUT will send frames to the host, the host will receive the frames and will send them back to the DUT
test_0004 Default filter operation Host will send 500 frames with DUT's MAC address and 500 frames with other MAC address. The DUT will reject the 500 frames that don't matches DUT's address
test_0005 Different filter configurations This test is split in different stages that will exercise different filter operations like adding/removing unicast address, entering/exiting promiscuous mode, etc.
test_0006 DUT frame transmission with confirmation The DUT will send 1000 non-VLAN tagged frames and will request TX confirmation. The host PC will check that all frames are received and that the frame content matches the expected patterns
test_0007 Transmission of VLAN tagged frames The DUT will send 1000 VLAN tagged frames and will request TX confirmation. The host PC will check that all frames are received and that the frame content matches the expected patterns
test_0008 Transmission of different frame lengths The DUT will send non-VLAN tagged frames of different lengths, including short frames. The host PC will check that all frames are received and that the frame content matches the expected patterns
test_0009 VLAN tagged frame reception Host will send 1000 VLAN tagged Ethernet frames, the DUT will receive and verify that the frame content matches the expected patterns
test_0010 Controller mode changes The application will set the controller to DOWN mode and then back to ACTIVE mode. Ethernet frame transmission and reception tests will be run afterwards. 10 iterations of these steps will be executed.
test_0100 Transmit throughput DUT transmit throughput is measured over 150,000 Ethernet frames sent from the host PC.
test_0200 Internal loopback (MAC) The DUT will send and receive 1000 Ethernet frames and will check the frame correctness against expected patterns. Note: This test runs only when Ethernet driver configuration's loopback mode is enabled
test_0101 Receive thoughput The host PC will send 150000 Ethernet frames. The DUT will receive the frames and compute the throughput.
test_0300 Egress timestamp test The DUT will transmit 10 Ethernet frames with the Egress timestamping enabled. It will then check that the Tx timestamp is returned.
test_0301 Ingress timestamp test The DUT will receive 10 Ethernet frames from the host PC. It will then check that the Rx timestamp is returned.
test_0302 Get current time test The DUT will transmit 10 Ethernet frames with a specific interval, then check the accurate timestamp in between transmit attempts.

The following list identifies key steps performed by the DUT side application:

  • EthApp_Startup ()
    • Pin mux configuration
    • Set Ethernet connection type in MMR
    • Interrupt controller initialization and ISR registration for the following interrupts:
      • TX DMA completion
      • RX DMA completion
      • MDIO completion (register access completion)
    • Initialize counters required for timed operations
  • EthApp_init()
  • Loop through all tests
    • EthApp_test_0001: Basic DUT frame reception test:
      • Send test START command
      • Receive frames until the STOP is detected
    • EthApp_test_0002: Basic DUT frame transmission test:
      • Send test START command
      • Transmit 1000 non-VLAN tagged frames without confirmation
    • EthApp_test_0003: External loopback test. The DUT sends frames to the host, the host receives the frames and sends them back to the DUT. The following operations are performed on the DUT side:
      • Send START command
      • Send and receive 1000 frames, for each of them:
        • A different payload is set
        • EtherType and payload are verified on the received frame
    • EthApp_test_0004: Default filter operation. Test the operation of the default DUT's filter configuration (only frames with DUT's MAC address are accepted, all others are rejected). The DUT performs these operations:
      • Send START command
      • Receive frames until the STOP is detected
      • The number of frames expected to be received is 500 as only one half of the total frames sent by the host (1000) have the DUT's MAC address
    • EthApp_test_0005: Different filter configurations test. Test the different modes of the DUT's filter configuration. The DUT performs these operations:
      • Send START command
      • Part 1
        • Filter is reset to accept only frames with DUT's MAC address
        • Host side transmits 1000 frames and then transmits the STOP command
        • Receive frames until STOP is detected
          • Frame 1: Source MAC address is DUT's. It should be accepted
          • Frame 2: Source MAC address is not DUT's. It should be rejected
          • Expected to receive 500 frames
      • Part 2
        • A second unicast MAC address is added to the DUT's filter
        • Host side transmits 1000 frames and then transmits the STOP command
        • Receive frames until STOP is detected
          • Frame 1: Source MAC address is DUT's. It should be accepted
          • Frame 2: Source MAC address is second valid MAC address. It should be accepted
          • Expected to receive 1000 frames
      • Part 3
        • A multicast address is added to the DUT's filter
        • Host side transmits 1000 frames and then transmits the STOP command
        • Receive frames until STOP is detected
          • Frame 1: Source MAC address is DUT's. It should be accepted
          • Frame 2: Source MAC address is multicast address. It should be accepted
          • Expected to receive 1000 frames
      • Part 4
        • The multicast address is removed from the DUT's filter
        • Host side transmits 1000 frames and then transmits the STOP command
        • Receive frames until STOP is detected
          • Frame 1: Source MAC address is DUT's. It should be accepted
          • Frame 2: Source MAC address is multicast address. It should be rejected
          • Expected to receive 500 frames
      • Part 5
        • The filter is opened up (promiscuous mode)
        • Host side transmits 1000 frames and then transmits the STOP command
        • Receive frames until STOP is detected
          • Frame 1: Source MAC address is DUT's. It should be accepted
          • Frame 2: Source MAC address is not DUT's. It should be accepted
          • Expected to receive 1000 frames
      • Part 6
        • The filter is reset back to accept only DUT's unicast address
        • Host side transmits 1000 frames and then transmits the STOP command
        • Receive frames until STOP is detected
          • Frame 1: Source MAC address is DUT's. It should be accepted
          • Frame 2: Source MAC address is not DUT's. It should be rejected
          • Expected to receive 500 frames
    • EthApp_test_0006: Transmission with confirmation test. DUT frame transmission test with TX confirmation. The DUT performs these operations:
      • Send START command
      • Transmit 1000 non-VLAN tagged frames with confirmation
    • EthApp_test_0007: Transmission of VLAN tagged frames test. DUT frame transmission test of VLAN tagged frames. The DUT performs these operations:
      • Send START command
      • Transmit 1000 VLAN tagged frames with confirmation
    • EthApp_test_0008: Transmission of different frame lengths. DUT frame transmission test of different frame lengths, including short frames (less than 64 octets). The DUT performs these operations:
      • Send START command
      • Transmit 10 frames for lengths starting at 10 octets in increments of 10 octets until 1500 octets
    • EthApp_test_0009: VLAN tagged frame reception test
      • Host side transmits 1000 frames and then transmits the STOP command
      • The DUT performs these operations:
        • Send START command
        • Receive frames until the STOP is detected
      • The number of frames expected to be received is 1000
    • EthApp_test_0010: Controller mode change test. The DUT performs the following operations:
      • Send START command
      • Run 10 iterations of:
        • Set controller mode to DOWN state
        • Set controller mode to ACTIVE state
        • Transmit frames (run test 0002)
        • Receive frames (run test 0001)
    • EthApp_test_0100: DUT transmit throughput test. Measure DUT transmit throughput over 150000 frames
      • Host side transmits 150000 frames and then transmits the STOP command
      • The DUT performs the following operations:
        • Get the initial timestamp corresponding to the first frame received
        • Receive frames until the STOP is detected and get the final timestamp
        • Compute the transmit throughput from the number of received frames and the time difference between the two captured timestamps
    • EthApp_test_0200: Internal loopback test (MAC). The DUT performs the following operations:
      • Send and receive 1000 frames, for each of them:
        • A different payload is set
        • EtherType and payload are verified on the received frame
    • EthApp_test_0101: DUT receive throughput test.
      • Send START command
      • The Host transmits 150000 frames and then transmits the STOP command
      • The DUT performs the following operations:
        • Get the initial timestamp corresponding to the first frame received
        • Receive frames until the STOP is detected and get the final timestamp
        • Compute the transmit throughput from the number of received frames and the time difference between the two captured timestamps
    • EthApp_test_0300: Egress timestamp test
      • Send START command
      • The DUT performs the following operations:
        • Transmit 10 frames with confirmation, at 1 second intervals, then send STOP command
        • When Tx Confirmation API is called, EthIf_TxConfirmation(), get Egress timestamp save timestamp
    • EthApp_test_0301: Ingress timestamp test
      • Send START command
      • The DUT performs the following operations:
        • Receive frames until STOP is detected
        • When Rx Indication API is called, validate the frame and update the counter stats
        • For each frame received, get the Ingress timestamp
    • EthApp_test_0302: Get current timestamp test
      • Send START command
      • The DUT performs the following operations:
        • Transmit 10 frames with confirmation, sleep at 1 second intervals, then send STOP command
        • Get current timestamp after each 1 second delay
  • EthApp_showStats()
    • Get and print the Ethernet controller statistics (Eth_GetEtherStats())
  • EthApp_showDropCount()
    • Get and print the Ethernet controller drop counts (Eth_GetDropCount())
  • EthApp_deinit()
  • Check for error status and print the result

EthApp_test_0200 will run only when loopback is enabled via Ethernet driver configuration. All other tests will not run. Conversely, when loopback is disabled EthApp_test_0200 will not run.

The host application steps are not presented in this guide, but can be found documented in the host side code. Please refer to the File Structure section for the directory where the HostApp.c file can be found.

The configuration files are present can be found at the directories shown in the File Structure section.

Back To Top

Example Log

J721E/J7200

Default (non-loopback) test application log(eth_test_app)

Target-side application log
Eth Application Starts
MAC Port 1 Address: 24:76:25:96:dc:d4
EthTrcv mode: ACTIVE
EthTrcv link state: Up
EthTrcv baud rate: 1000Mbps
EthTrcv duplexity: Full
EthApp_TrcvModeIndication: Active
Waiting for Host..
No Response from Host, remaining retry = 100
Host App detected! Sending Read ACK CMD...


-----------------------------------------------------------
test_0001: START
test_0001: received 1000 of 1000 frames
test_0001: END
Test Result: Pass 0
-----------------------------------------------------------


-----------------------------------------------------------
test_0002: START
test_0002: END
Test Result: Pass 0
-----------------------------------------------------------


-----------------------------------------------------------
test_0003: START
test_0003: END
Test Result: Pass 0
-----------------------------------------------------------


-----------------------------------------------------------
test_0004: START
test_0004: received 500 of 500 frames
test_0004: END
Test Result: Pass 0
-----------------------------------------------------------


-----------------------------------------------------------
test_0005: START
test_0005:  Null: Exp1: exp 500, got 500
test_0005:  Null: Exp2: exp   0, got   0
test_0005: Ucast: Exp1: exp 500, got 500
test_0005: Ucast: Exp2: exp 500, got 500
test_0005: Mcast: Exp1: exp 500, got 500
test_0005: Mcast: Exp2: exp 500, got 500
test_0005: Mcast: Exp1: exp 500, got 500
test_0005: Mcast: Exp2: exp   0, got   0
test_0005: Bcast: Exp1: exp 500, got 500
test_0005: Bcast: Exp2: exp 500, got 500
test_0005:  Null: Exp1: exp 500, got 500
test_0005:  Null: Exp2: exp   0, got   0
test_0005: END
Test Result: Pass 0
-----------------------------------------------------------


-----------------------------------------------------------
test_0006: START
test_0006: END
Test Result: Pass 0
-----------------------------------------------------------


-----------------------------------------------------------
test_0007: START
test_0007: END
Test Result: Pass 0
-----------------------------------------------------------


-----------------------------------------------------------
test_0008: START
test_0008: END
Test Result: Pass 0
-----------------------------------------------------------


-----------------------------------------------------------
test_0009: START
test_0009: received 1000 of 1000 frames
test_0009: END
Test Result: Pass 0
-----------------------------------------------------------


-----------------------------------------------------------
test_0010: START
Set CtrlMode DOWN
Get CtrlMode DOWN
EthApp_CtrlModeIndication: DOWN
Set CtrlMode ACTIVE
Get CtrlMode ACTIVE
EthApp_CtrlModeIndication: ACTIVE
test_0002: START
test_0002: END
test_0001: START
test_0001: received 1000 of 1000 frames
test_0001: END
Set CtrlMode DOWN
Get CtrlMode DOWN
EthApp_CtrlModeIndication: DOWN
Set CtrlMode ACTIVE
Get CtrlMode ACTIVE
EthApp_CtrlModeIndication: ACTIVE
test_0002: START
test_0002: END
test_0001: START
test_0001: received 1000 of 1000 frames
test_0001: END
Set CtrlMode DOWN
Get CtrlMode DOWN
EthApp_CtrlModeIndication: DOWN
Set CtrlMode ACTIVE
Get CtrlMode ACTIVE
EthApp_CtrlModeIndication: ACTIVE
test_0002: START
test_0002: END
test_0001: START
test_0001: received 1000 of 1000 frames
test_0001: END
Set CtrlMode DOWN
Get CtrlMode DOWN
EthApp_CtrlModeIndication: DOWN
Set CtrlMode ACTIVE
Get CtrlMode ACTIVE
EthApp_CtrlModeIndication: ACTIVE
test_0002: START
test_0002: END
test_0001: START
test_0001: received 1000 of 1000 frames
test_0001: END
Set CtrlMode DOWN
Get CtrlMode DOWN
EthApp_CtrlModeIndication: DOWN
Set CtrlMode ACTIVE
Get CtrlMode ACTIVE
EthApp_CtrlModeIndication: ACTIVE
test_0002: START
test_0002: END
test_0001: START
test_0001: received 1000 of 1000 frames
test_0001: END
Set CtrlMode DOWN
Get CtrlMode DOWN
EthApp_CtrlModeIndication: DOWN
Set CtrlMode ACTIVE
Get CtrlMode ACTIVE
EthApp_CtrlModeIndication: ACTIVE
test_0002: START
test_0002: END
test_0001: START
test_0001: received 1000 of 1000 frames
test_0001: END
Set CtrlMode DOWN
Get CtrlMode DOWN
EthApp_CtrlModeIndication: DOWN
Set CtrlMode ACTIVE
Get CtrlMode ACTIVE
EthApp_CtrlModeIndication: ACTIVE
test_0002: START
test_0002: END
test_0001: START
test_0001: received 1000 of 1000 frames
test_0001: END
Set CtrlMode DOWN
Get CtrlMode DOWN
EthApp_CtrlModeIndication: DOWN
Set CtrlMode ACTIVE
Get CtrlMode ACTIVE
EthApp_CtrlModeIndication: ACTIVE
test_0002: START
test_0002: END
test_0001: START
test_0001: received 1000 of 1000 frames
test_0001: END
Set CtrlMode DOWN
Get CtrlMode DOWN
EthApp_CtrlModeIndication: DOWN
Set CtrlMode ACTIVE
Get CtrlMode ACTIVE
EthApp_CtrlModeIndication: ACTIVE
test_0002: START
test_0002: END
test_0001: START
test_0001: received 1000 of 1000 frames
test_0001: END
Set CtrlMode DOWN
Get CtrlMode DOWN
EthApp_CtrlModeIndication: DOWN
Set CtrlMode ACTIVE
Get CtrlMode ACTIVE
EthApp_CtrlModeIndication: ACTIVE
test_0002: START
test_0002: END
test_0001: START
test_0001: received 1000 of 1000 frames
test_0001: END
test_0010: completed 10 of 10 iterations
test_0010: END
Test Result: Pass 0
-----------------------------------------------------------


-----------------------------------------------------------
test_0011: START
test_0011: END
Test Result: Pass 0
-----------------------------------------------------------


-----------------------------------------------------------
test_0300: START
Egress timestamp 0 Ts: 157644315 70  0
Egress timestamp 1 Ts: 188656403 70  0 [Exp: 0.030999999 Actual: 0.031012088]
Egress timestamp 2 Ts: 250667379 70  0 [Exp: 0.061999999 Actual: 0.062010977]
Egress timestamp 3 Ts: 375677115 70  0 [Exp: 0.125000000 Actual: 0.125009730]
Egress timestamp 4 Ts: 625687867 70  0 [Exp: 0.250000000 Actual: 0.250010759]
Egress timestamp 5 Ts: 125699867 71  0 [Exp: 0.500000000 Actual: 0.500011981]
Egress timestamp 6 Ts: 875711835 71  0 [Exp: 0.750000000 Actual: 0.750011981]
Egress timestamp 7 Ts: 875722867 72  0 [Exp: 1.000000000 Actual: 1.000010967]
Egress timestamp 8 Ts: 875732811 74  0 [Exp: 2.000000000 Actual: 2.000010014]
Egress timestamp 9 Ts: 875743003 79  0 [Exp: 5.000000000 Actual: 5.000010014]
test_0300: END
Test Result: Pass 0
-----------------------------------------------------------


-----------------------------------------------------------
test_0301: START
test_0301: received 10 of 10 frames
Ingress timestamp 0 Ts: 820358067 83  0
Ingress timestamp 1 Ts: 852879899 83  0 [Exp: 0.030999999 Actual: 0.032521833]
Ingress timestamp 2 Ts: 916703285 83  0 [Exp: 0.061999999 Actual: 0.063823387]
Ingress timestamp 3 Ts:  43024663 84  0 [Exp: 0.125000000 Actual: 0.126321375]
Ingress timestamp 4 Ts: 294354649 84  0 [Exp: 0.250000000 Actual: 0.251329988]
Ingress timestamp 5 Ts: 795613237 84  0 [Exp: 0.500000000 Actual: 0.501258612]
Ingress timestamp 6 Ts: 546805611 85  0 [Exp: 0.750000000 Actual: 0.751192391]
Ingress timestamp 7 Ts: 548114965 86  0 [Exp: 1.000000000 Actual: 1.001309395]
Ingress timestamp 8 Ts: 549324011 88  0 [Exp: 2.000000000 Actual: 2.001209021]
Ingress timestamp 9 Ts: 550473971 93  0 [Exp: 5.000000000 Actual: 5.001150131]
test_0301: END
Test Result: Pass 0
-----------------------------------------------------------


-----------------------------------------------------------
test_0302: START
Current timestamp 0 Ts: 667579211 98  0
Current timestamp 0 Ts: 815994289 99  0
Current timestamp 0 Ts: 967562175 100  0
Current timestamp 0 Ts: 118584271 102  0
Current timestamp 0 Ts: 268766247 103  0
Current timestamp 0 Ts: 417965177 104  0
Current timestamp 0 Ts: 569251105 105  0
Current timestamp 0 Ts: 718330557 106  0
Current timestamp 0 Ts: 869915315 107  0
Current timestamp 0 Ts:  19926483 109  0
test_0302: END
Test Result: Pass 0
-----------------------------------------------------------


-----------------------------------------------------------
test_0110: START
test_0100 frames 150000 size 1500: START
test_0100: 10 frames size 1500
test_0100: END
test_0100 frames 150000 size 512: START
test_0100: 10 frames size 512
test_0100: END
test_0100 frames 150000 size 256: START
test_0100: 10 frames size 256
test_0100: END
test_0100 frames 150000 size 128: START
test_0100: 10 frames size 128
test_0100: END
test_0100 frames 150000 size 64: START
test_0100: 10 frames size 64
test_0100: END
test_0110: DONE
Test Result: Pass 0
-----------------------------------------------------------


-----------------------------------------------------------
test_0101: START
receiveTput-1500: received 149992 frames in 1.83 secs (82022.03 frames/s, 984.26 Mbps) Lost 8
receiveTput-512: received 149996 frames in 0.64 secs (233255.97 frames/s, 955.42 Mbps) Lost 4
receiveTput-256: received 84346 frames in 0.34 secs (248305.02 frames/s, 508.53 Mbps) Lost 65654
receiveTput-128: received 144228 frames in 0.57 secs (250912.06 frames/s, 256.93 Mbps) Lost 155772
receiveTput-64: received 178782 frames in 0.71 secs (250759.27 frames/s, 128.39 Mbps) Lost 121218
test_0101: END
Test Result: Pass 0
-----------------------------------------------------------


-----------------------------------------------------------
test_0610: START
test_0610: END
Test Result: Pass 0
-----------------------------------------------------------


-----------------------------------------------------------
test_0611: START
receiveQosTput-0: received 149958 frames in 3.66 secs (41006.11 frames/s, 487.48 Mbps)
receiveQosTput-7: received 149964 frames in 3.66 secs (41007.75 frames/s, 487.50 Mbps)
test_0611: END
Test Result: Pass 0
-----------------------------------------------------------

----------------------------
Controller 0 Counters
----------------------------
Buffer overruns   : 39
CRC errors        : 0
Undersize packets : 0
Oversized packets : 0
Alignment errors  : 0
SQE errors        : -1
Discarded inbound : -1
Erroneous inbound : 0
Discarded outbound: -1
Erroneous outbound: 0
Single collision  : 0
Multiple collision: 0
Deferred transm   : 0
Late collisions   : 0
Excessive colls   : 0
Carrier loss      : 0
----------------------------
Controller 0 Rx Statistics
----------------------------
Rx Drop Events       : 4039
Rx Octets            : 865150608
Rx Packets           : 1370097
Rx Bcast Packets     : 0
Rx Mcast Packets     : 1087
Rx CRC/Align Errors  : 0
Rx Undersized Packets: 0
Rx Oversized Packets : 0
Rx Fragments         : 0
Rx Jabbers           : 0
Rx Collisions        : -1
Rx 64 bytes or less Packets   : -1
Rx 65 to 127 bytes Packets    : -1
Rx 128 to 255 bytes Packets   : -1
Rx 256 to 511 bytes Packets   : -1
Rx 512 to 1023 bytes Packets  : -1
Rx 1024 to 1518 bytes Packets : -1
Rx Unicast Packets            : 1369010
----------------------------
Controller 0 Tx Statistics 
----------------------------
Tx Num octets          : 541567730
Tx No Unicast Packets  : 855786
Tx Unicast Packets     : 0
--------------------------------
Controller 0 Tx Error Counters 
--------------------------------
Tx Deferred transm      : 0
Tx Single collisions    : 0
Tx Multiple collisions  : 0
Tx Late collisions      : 0
Tx Excessive collisions : 0
ETH Stack Usage: 2356 bytes
Final Tests Results: PASS
Eth Application Completed
------------
Host-side application log
Interface    : enp4s0
MAC address  : 1c:fd:08:72:59:77


Waiting for DUT..
Recv Ready CMD, sending READY SYN ACK...
Waiting for DUT's READY ACK command...
DUT detected: 24:76:25:96:dc:d4


-----------------------------------------------------------
test_0001: START
test_0001: transmitted 1000 of 1000 frames
test_0001: END
Test Result: Pass
-----------------------------------------------------------


-----------------------------------------------------------
test_0002: START
test_0002: received 1000 of 1000 frames
test_0002: END
Test Result: Pass
-----------------------------------------------------------


-----------------------------------------------------------
test_0003: START
test_0003: looped back 1000 frames
test_0003: END
Test Result: Pass
-----------------------------------------------------------


-----------------------------------------------------------
test_0004: START
test_0004: completed 500 of 500 iterations
test_0004: END
Test Result: Pass
-----------------------------------------------------------


-----------------------------------------------------------
test_0005: START
test_0005: END
Test Result: Pass
-----------------------------------------------------------


-----------------------------------------------------------
test_0006: START
test_0006: received 1000 of 1000 frames
test_0006: END
Test Result: Pass
-----------------------------------------------------------


-----------------------------------------------------------
test_0007: START
test_0007: received 1000 of 1000 frames
test_0007: END
Test Result: Pass
-----------------------------------------------------------


-----------------------------------------------------------
test_0008: START
test_0008: END
Test Result: Pass
-----------------------------------------------------------


-----------------------------------------------------------
test_0009: START
test_0009: transmitted 1000 of 1000 frames
test_0009: END
Test Result: Pass
-----------------------------------------------------------


-----------------------------------------------------------
test_0010: START
test_0002: START
test_0002: received 1000 of 1000 frames
test_0002: END
test_0001: START
test_0001: transmitted 1000 of 1000 frames
test_0001: END
test_0002: START
test_0002: received 1000 of 1000 frames
test_0002: END
test_0001: START
test_0001: transmitted 1000 of 1000 frames
test_0001: END
test_0002: START
test_0002: received 1000 of 1000 frames
test_0002: END
test_0001: START
test_0001: transmitted 1000 of 1000 frames
test_0001: END
test_0002: START
test_0002: received 1000 of 1000 frames
test_0002: END
test_0001: START
test_0001: transmitted 1000 of 1000 frames
test_0001: END
test_0002: START
test_0002: received 1000 of 1000 frames
test_0002: END
test_0001: START
test_0001: transmitted 1000 of 1000 frames
test_0001: END
test_0002: START
test_0002: received 1000 of 1000 frames
test_0002: END
test_0001: START
test_0001: transmitted 1000 of 1000 frames
test_0001: END
test_0002: START
test_0002: received 1000 of 1000 frames
test_0002: END
test_0001: START
test_0001: transmitted 1000 of 1000 frames
test_0001: END
test_0002: START
test_0002: received 1000 of 1000 frames
test_0002: END
test_0001: START
test_0001: transmitted 1000 of 1000 frames
test_0001: END
test_0002: START
test_0002: received 1000 of 1000 frames
test_0002: END
test_0001: START
test_0001: transmitted 1000 of 1000 frames
test_0001: END
test_0002: START
test_0002: received 1000 of 1000 frames
test_0002: END
test_0001: START
test_0001: transmitted 1000 of 1000 frames
test_0001: END
test_0010: completed 10 of 10 iterations
test_0010: END
Test Result: Pass
-----------------------------------------------------------


-----------------------------------------------------------
test_0011: START
test_0011: received 1000 of 1000 frames
test_0011: END
Test Result: Pass
-----------------------------------------------------------


-----------------------------------------------------------
test_0300: START
test_0300: END
Test Result: Pass
-----------------------------------------------------------


-----------------------------------------------------------
test_0301: START
test_0301: transmitted 10 of 10 frames
test_0301: END
Test Result: Pass
-----------------------------------------------------------


-----------------------------------------------------------
test_0302: START
test_0302: END
Test Result: Pass
-----------------------------------------------------------


-----------------------------------------------------------
test_0110: START
receiveTput-1500: received 150000 frames in 1.85 secs (81275.57 frames/s, 984.41 Mbps) Lost 0
receiveTput-512: received 150000 frames in 0.77 secs (193594.36 frames/s, 814.65 Mbps) Lost 0
receiveTput-256: received 150000 frames in 0.75 secs (198931.86 frames/s, 429.69 Mbps) Lost 0
receiveTput-128: received 150000 frames in 0.76 secs (197442.20 frames/s, 224.29 Mbps) Lost 0
receiveTput-64: received 150000 frames in 0.76 secs (197406.34 frames/s, 123.18 Mbps) Lost 0
test_0110: DONE
Test Result: Pass
-----------------------------------------------------------


-----------------------------------------------------------
test_0101: START
transmitTput: TX side transmitted 150000 frames in 1.83 secs (82070.41 frames/s, 984.84 Mbps)
transmitTput: TX side transmitted 150000 frames in 0.64 secs (233411.81 frames/s, 956.05 Mbps)
transmitTput: TX side transmitted 150000 frames in 0.34 secs (442284.75 frames/s, 905.80 Mbps)
transmitTput: TX side transmitted 300000 frames in 0.56 secs (531372.19 frames/s, 544.13 Mbps)
transmitTput: TX side transmitted 300000 frames in 0.70 secs (426879.16 frames/s, 218.56 Mbps)
test_0101: END
Test Result: Pass
-----------------------------------------------------------


-----------------------------------------------------------
test_0610: START
receiveTput-COS 0: received 43427 frames in 1.09 secs (39661.57 frames/s, 479.11 Mbps)
receiveTput-COS 1: received 0 frames in 1.09 secs (0.00 frames/s, 0.00 Mbps)
receiveTput-COS 2: received 0 frames in 1.09 secs (0.00 frames/s, 0.00 Mbps)
receiveTput-COS 3: received 0 frames in 1.09 secs (0.00 frames/s, 0.00 Mbps)
receiveTput-COS 4: received 0 frames in 1.09 secs (0.00 frames/s, 0.00 Mbps)
receiveTput-COS 5: received 0 frames in 1.09 secs (0.00 frames/s, 0.00 Mbps)
receiveTput-COS 6: received 0 frames in 1.09 secs (0.00 frames/s, 0.00 Mbps)
receiveTput-COS 7: received 45562 frames in 1.09 secs (41611.45 frames/s, 502.67 Mbps)
test_0610: END
Test Result: Pass
-----------------------------------------------------------


-----------------------------------------------------------
test_0611: START
test_0611: END
Test Result: Pass
-----------------------------------------------------------

Final Tests Results: Pass

Back To Top

Known Limitations

None

Back To Top

References

Sl No Specification Comment / Link
1 AUTOSAR 4.3.1 AUTOSAR Specification for Eth Driver Internet Link
2 AUTOSAR 4.3.1 AUTOSAR Specification for EthTrcv Driver Internet Link
3 - Design Page (Eth Design Document)

Back To Top

Document Revision History

Revision Date Author Description Status
0.1 08 Oct 2018 Misael Lopez First version Approved
0.2 22 Oct 2018 Misael Lopez Addressed review comments Approved
0.3 30 Nov 2018 Misael Lopez Updated UDMA interrupt information Approved
0.4 06 Dec 2018 Misael Lopez Updating Status Approved
0.5 16 Oct 2019 Sujith S Updates profile numbers for release 01.00.00 Approved
0.6 29 May 2020 Misael Lopez Updated for AUTOSAR 4.3.1 Approved
0.7 02 Dec 2022 Quan Tran Updated DMA configuration and lastest driver update Approved
0.8 30 Jun 2023 Quan Tran Updated limitation and lastest test log Approved
0.9 06 Nov 2023 Allan Co Updated to merged Jacinto and Sitara MPU User Guide Approved
0.10 30 May 2024 Quan Tran Updated example app name Approved