Gateway is one of the major use cases in modern cars. Performance requirements for gateway applications are ever increasing due to the advanced connected car architecture having multiple domain controllers. The CAN-Ethernet gateway demo showcases P2P (Protocol to Protocol) translation i.e. translating data and control information between incompatible networks like Ethernet and CAN for communication on the J7200 device through the IEEE-1722 protocol.
The demo application enables full duplex routing between: CAN-to-Ethernet, Ethernet-to-CAN, CAN-to-CAN, and Ethernet-to-Ethernet. The demo uses MCAL drivers running on one Main R5F core, along with a Ethernet remote switch server running on the other Main R5F.
- FreeRTOS support
- CAN-Eth Gateway Demo : Ported to FreeRTOS and removed support for TI-RTOS. (validated for J7200)
- CAN Traffic Generator and Low Latency Demo : Ported to FreeRTOS but not functional.
- Compiler Migration from TI GGT 20.2.0.LTS to TI Arm Clang 2.1.3.LTS.
- Customers are requested to use the Regular Demo for evaluation.
- No other bug fixes or feature additions
- Before getting into more details, readers should familiarize themselves with the assumptions made in this document and general demo requirements.
- This document refers to three types of demos
- Regular Demo : This is done with PCAN-USB devices
- Out of Box Demo : This is identical to the Regular demo except that there is no PCAN-USB device involved and CAN traffic is generated or received through MCAN 0/1 ports on an application running on MCU1_0. Out of Box Demo can only be executed via the Automated framework.
- Low Latency Demo : This demo is an optimized version of the CAN 2 CAN routing done by regular demo. It runs on MCU 1_0 and can be created from the CAN generator application by adding a macro.
- Basic familiarity with operating any CAN device capable of sending and receiving CAN-FD messages. This includes knowledge of wiring and signals.
- Basic familiarity with Python3, as it is used for implementing test automation.
- Basic familiarity with Ethernet interface and IEEE 1722 protocol
- Knowledge of raw sockets is helpful, but not essential.
- Operation of a PC/System running Linux. Since raw sockets are used, Windows is not supported.
- Basic familiarity with Jacinto 7 Architecture
- For details on individual parts of the Jacinto 7, such as MCAN, Main domain, and other parts, readers are asked to read SoC documentation first (if they haven't done so already).
- J7200 EVM Board (SOM Board and Common Board), a GESI add-on card (for CAN) and SGMII daughter card
- CAN Receiver/Transmitter with minimum of 2x ports. This demo shows CAN functionality with 2x PCAN-USB tools, but it's not limited to PCAN tools. Refer to J7 Board setup section for further details.
- If CAN devices are not available then Out of Box configuration can be used.
- 2x LAN Cables (preferably CAT6)
- 2x Micro USB cable (for UART and JTAG)
- Linux PC (recommended: Ubuntu 20.04) with minimum of 2x Gigabit ports and root access. If ports are not available natively, then USB-Ethernet adapters can be used.
- Use native Linux installation instead of Virtual Machine. Demo has not been evaluated on a Virtual Machine.
Root access is required because the demo uses raw sockets, and raw sockets are only accessible with root privileges.
- Ubuntu 18.04 is required if user intends to run the GUI which is provided as a precompiled binary.
- Code Composer Studio (CCS) version 9.3.0 and above
- PC Ethernet tools - Required for receiving and transmitting data over Ethernet
- Use/run
recv_1722.outandsend_1722.oututilities on host PC. These utilities are available at<SDK_INSTALL_PATH>/gateway-demos/pctools
- Use/run
- Test Automation Framework - Can only be used with PCAN-USB tool and Ethernet adapters attached to Linux PC
- Use/run
run_demo.pyto run automation tools. There is a separate section on using the test automation framework below. - Python3 base installation on Ubuntu PC
- libpopt-dev installation for compiling Peak CAN linux driver
- Use/run
- CAN tool software (PCAN drivers and PCAN View if using PCAN-USB tool) for regular demo and low latency demo.
- PCAN Driver 8.16.0 for Linux (if using the test automation framework) from PEAK-System Technik GmbH for regular demo. See Download Link https://www.peak-system.com/fileadmin/media/linux/files/peak-linux-driver-8.16.0.tar.gz
- For Out of Box configuration CAN software is not required.
The following block diagram shows the various functional blocks and the data flow used in the gateway demo application for J7200. As shown in the diagram, PC Ethernet applications are used for transmitting and receiving Ethernet frames between PC and the J7200 EVM. Similarly, any compatible CAN tool can be used for CAN message reception and transmission.
The routing is done based on a queue-based architecture, where the gateway task periodically polls the CAN and Ethernet queues, which are, in turn, populated by the respective drivers in the interrupt context. This architecture allows full packet inspection of packet and allows matching two asynchronous interfaces like Ethernet and CAN.
The CAN/Ethernet demo application is supported only on the Main_Cortex_R5_0_1 core of the Jacinto device along with the accompanying remote switch driver, which runs on the Main_Cortex_R5_0_0 core.
- Routing at L2 within application, through IEEE 1722 protocol for CAN-to-CAN, CAN-to-Eth, Eth-to-CAN and Eth-to-Eth
- PC-based raw socket applications for sending/receiving 1722 frames
- Weighted average bridge delay computation for all routed packets
- Test Automation Framework to automatically run the demo and report throughput and latency numbers without user intervention
- A GUI binary to provide improved look and feel
The CAN_ETH Gateway demo is located in the Processor SDK RTOS release under the following directory path
<SDK_INSTALL_PATH>/gateway-demos
This contains two folders :
- can_eth_gateway : Contains sources for CAN Eth Gateway application (which does the routing)
- can_traffic_generator : Contains sources for CAN traffic generator application (running on MCU1_0) which is used for Out of Box demo experience and for providing Sciclient services.
Users must run either the can_traffic_generator app or the default sciclient test application for regular demo. For Out of Box configuration, users must run the can_traffic_generator application.
User must issue make command from <SDK_INSTALL_PATH>/gateway-demos location. Detailed description of other directories is given below:
- binary - directory where gateway app and other compiled binaries are generated
- pctools - directory containing Ethernet PC tools sources, patch for pcan tools and python scripts for Test Automation
- docs - Contains User Guide PDF
- mcuss_demos - Contains MCUSW components which are specific to gateway app
- build - Contains the makefile infrastructure
RTOS components:
- FreeRTOS
Processor SDK RTOS drivers:
- MCUSW components like CAN, Eth
- Eth Firmware
- UART
- Board
- OSAL
- CSL
- udma
- sciclient
- CPSW LLD
- IPC
Note : Windows build is at least 10-15x slower than Linux and since Gateway-Demo uses PDK, EthFW and MCUSW modules, the cumulative build time is huge.
Note : Running the automated CAN-Ethernet Gateway-Demo script is currently only supported on Linux given limitations with PCAN-USB driver and difficulties in automation of Layer2 Ethernet send/receive.
Given these two limitations, it has been decided to support Gateway-Demo build only on Linux. If you are a Windows user, please use a Virtual Machine running Linux to build Gateway-Demo.
- The demo applications (
can_eth_gateway_appandcan_traffic_generator_app) are built using makefile. The low latency demo is also built using thecan_traffic_generator_appcommand but with an additional macroLOW_LATENCY_DEMO
Refer to PDK rules.mk for setting tools paths. Run following commands after this has been done.
- Type the following in <SDK_INSTALL_PATH>/gateway-demos to see makefile options:
make help
- The following are steps to clean the demo and delete both applications:
cd <SDK_INSTALL_PATH>/gateway-demos make allclean
- The following are steps to compile the
can_eth_gateway_appwith all dependencies for J7200:cd <SDK_INSTALL_PATH>/gateway-demos make -s can_eth_gateway_app BOARD=j7200_evm
- This will generate binaries for both CAN Eth Gateway application (under <SDK_INSTALL_PATH>/gateway-demos/binary) and EthFw application (under <SDK_INSTALL_PATH>/ethfw/out)
Note : can_traffic_generator_app has not been enabled on FreeRTOS.
- The following are steps to compile the
can_traffic_generator_appwith all dependencies for J7200:cd <SDK_INSTALL_PATH>/gateway-demos make -s can_traffic_generator_app BOARD=j7200_evm CORE=mcu1_0
- To compile the Low latency demo, uncomment line #81 in
can_traffic_generator/makefileto enable the macroLOW_LATENCY_DEMOand repeat the step above.
If you are building the applications for the first time or after a clean build then all PDK dependencies are built first. For can_eth_gateway_app MCU2_1 dependencies get built and for can_traffic_generator_app MCU1_0 dependencies.
- If that doesn't happen then you will get a build error during linking.
- If you see this issue, please build the dependencies first. For eg. for
can_eth_gateway_appuse the command (for J7200)make -s depend_can_eth_gateway BOARD=j7200_evm
- For
can_traffic_generator_appuse the commandmake -s depend_can_generator BOARD=j7200_evm
The PC tools for Ethernet reception, transmission and Test Automation are located under pctools directory. These tools can be built only for Linux:
cd <SDK_INSTALL_PATH>/gateway-demos/pctools make all
The python scripts can be used without any changes. Usage is described below under "Test Automation Framework"
The regular demo can be run either using the Automated Test Framework or manually. The Automated Test Framework has the limitation that it can only be used with the PCAN-USB tool from PEAK-System Technik GmbH.
If using a CAN tool from another manufacturer, please refer to the section which describes how to manually run the demo. The setup for both the systems looks the same, so it is described below before we discuss the Automated Test Framework.
The connections for J7200 are identical except the CPSW 9G ports which use the SGMII ports on the add on QSGMII add-on card. Shown below:
On J7200, the MCAN9 port is referred to as the MCAN8 port, but pins and wiring remains the same. The change is in the software.
As shown in the figure above, connect the two CPSW 9G Ethernet ports to PC's Ethernet ports and assign a fixed local IP to the interfaces to avoid unnecessary ARP traffic. If built-in NIC's are not available, then USB Ethernet NIC's can be used.
As shown in the picture below, connect the two USB-CAN analyzers to MCAN4 and MCAN8/9 instances, which are labeled as J30 and J32 respectively on the GESI card. The MCAN pin connection is as follows:
- Pin 1 (CAN_H)
- Pin 2 (GRD)
- Pin 3 (CAN_L)
The following diagram shows the MCAN4 and MCAN9 connections on GESI card. MCAN8/9 has the same pin orientation (CAN_H, CAN_L and GND) as MCAN4.
If using the PCAN tool, the DB-9 connection is as follows:
Routing inside the gateway demo is now configurable, users can configure it as per their requirements.
This is achieved through the use of a simple lookup table inside the gateway application with 256 entries. Each entry has two masks, one for Ethernet and one for CAN.
The masks tell which ports are open for Transmit. So if Eth mask is set to 0 then no packets are sent out of any Ethernet port, same for CAN.
See figure below on how this is done.
Using the CAN ID as an index allows for O(1) lookup time.
The framework has two parts
- Raw socket based Ethernet tools (provided by TI)
- Linux Peak CAN driver (Open source driver from PEAK-System Technik GmbH)
In addition to these two, there is a GUI based on open frameworks, which allows the user to visualize the CPU Load, latency, and throughput.
There are two raw socket based Ethernet tools, send_1722.out and recv_1722.out which are used for sending and receiving IEEE 1722 frames, respectively. Their usage is described below.
The tools can be built by the user by executing the make all command in the <SDK_INSTALL_PATH>/gateway-demos/can_eth_gateway/pctools directory. The tools provide multiple options to the user, and they can be accessed by running them with the –help option. So, for example, to understand the options provided with send_1722.out run the command:
sudo send_1722.out --help
Example usage:
sudo ./send_1722.out --eth_interface eth0 --gateway_mac 70:ff:76:1d:92:c1 --dst_mac f8:b1:56:a6:86:e6 --ipg 1000 --route ETH --timeout 12 sudo ./recv_1722.out --eth_interface eth1 --timeout 12
sudo option is required since raw sockets in Linux require super user permission. As a result, even the python scripts that execute the automated tests require super user permission.
The analogous tool for CAN is called pcanfdtst, which supports both Tx and Rx modes. Its installation and usage is described below.
To install the PCAN Linux driver, follow these steps on your Linux PC. Supported from Ubuntu 20.04.
- Download the Peak CAN Linux driver ver. 8.16.0 from https://www.peak-system.com/fileadmin/media/linux/files/peak-linux-driver-8.16.0.tar.gz
- Extract the package into your home directory or any other location.
- Install the dependency of libpopt-dev package:
sudo apt-get install -y libpopt-dev
- Run the following commands to build and install the driver:
cd peak-linux-driver-8.16.0 make all sudo make install
- Finally, run the following command to enable the driver:
sudo modprobe pcan
- If the command is successful and the PCAN-USB tool is plugged into PC, then the green light on the device will come up.
- The default
pcanfdtsttool provided in the Linux driver doesn't have the necessary extensions required for the automation. To do that, user needs to apply thepcanfdtst.patchprovided ingateway-demos/pctoolsto the filepcanfdtst.cin the folderpeak-linux-driver-8.16.0/test/src. - To patch and build the tool, copy the
pcanfdtst.patchfromgateway-demos/pctoolstopeak-linux-driver-8.16.0/test/srcand then execute the following commands in the directorypeak-linux-driver-8.16.0/test/src:patch pcanfdtst.c pcanfdtst.patch cd .. make all
- This will build
pcanfdtsttool in the peak-linux-driver-8.16.0/test directory.
The pcanfdtst tool has many options, to see all of them run the command:
./pcanfdtst --help
Example usage to receive packets at 1 Mbps bitrate and 5 Mbps data rate:
./pcanfdtst rx --bitrate 1000000 --dbitrate 5000000 --clock 80000000 --brs --fd -q -M 12 /dev/pcan32
There are four routes to test in the demo:
- CAN-to-CAN
- CAN-to-Eth
- Eth-to-CAN
- Eth-to-Eth
Each route requires running sender(s) and listener(s) tasks simultaneously. This is automatically done by the Python script called run_demo.py. Besides these four routes, the script supports running System tests which enables all four routes simultaneously. The system tests can only be run with the GUI, which is described in Running GUI section.
Since the python script uses pcanfdtst utility from PCAN Linux Driver, the user first needs to copy the pctools folder to the folder peak-linux-driver-8.16.0/test:
cp -Rf <SDK_INSTALL_PATH>/gateway-demos/can_eth_gateway/pctools peak-linux-driver-8.16.0/test
User can now run the script from the peak-linux-driver-8.16.0/test folder. To find out what all option the script supports, run the command:
python3 pctools/run_demo.py --help
Due to hardcoded dependencies in the path of executables, the script must be run from the test folder as described above.
To run the demo, the Python script needs the following information:
- CAN devices attached to the PC. The script needs to know which device is connected to MCAN4, and which one is connected to MCAN9. Users can see this by running the command:
lspcan
- Ethernet devices attached to the PC (two are required). Users can see this by running the command:
ifconfig
- MAC address of the Gateway application running on the Jacinto 7 EVM. This is either determined automatically or updated manually.
Providing so much information to the script is not easy, so the script provides a way to read this from a file. The file is called app_config.txt and should be kept in the same folder as the script. A sample app_config.txt file is provided in <SDK_INSTALL_PATH>/gateway-demos/can_eth_gateway/pctools folder. If the Python script cannot find the file, then the script tries to generate it automatically with the help from the user. The interaction is self-explanatory, but an example is provided below with comments.
Example usage:
python3 pctools/run_demo.py --iterations 1 --run_time 5 --system_test 0 --gui_enabled 0
Here --iterations 1 tells the script to run the unit tests only once, --run_time 5 tells the script to run each iteration for 5 seconds and --gui_enabled 0 tells the script not to invoke the GUI.
If the script cannot find app_config.txt, it will prompt the user with the following prompts:
Please remove any PCAN devices connected to the PC....hit Enter when ready Now connect the first PCAN device to MCAN4 interface (J14) on the GESI card...refer to the setup diagram
At this point, if the user connects a PCAN-USB device to PC, then user will get the prompt:
Found one interface
Continuing with the prompts, the user gets:
Now connect the second PCAN device to MCAN9 interface (J6) on the GESI card...refer to the setup diagram Please select the primary interface. Its usually the built in Ethernet card on a laptop or PC
Now, the user will be prompted with different ethernet interfaces on the PC and must select the appropriate interfaces connected to the Jacinto 7 EVM by entering Y or N. (See setup diagram)
For example, if eth0 and eth1 are connected to the Jacinto 7 EVM, then those must be selected:
Please select the secondary interface. Its usually a USB dongle on a laptop or a secondary NIC on a PC
At this prompt, user must select the second ethernet interface. Once that's done, the script will display something like:
--------Two CAN and two Ethernet Interfaces were added as shown below-------- CAN Interface for MCAN4 : /dev/pcanusbfd32 CAN Interface for MCAN9 : /dev/pcanusbfd33 Primary Eth Interface : enp1s2 Secondary Eth Interface : enxd037455f8444 If this is ok, then hit Y else hit N (to exit)
If the user proceeds and everything (Ethernet connection, CAN adapter, drivers, setup, cables) is OK, then user will get the prompt:
Found Gateway MAC. Good!
and the script will create the file app_config.txt file in the folder where the Python script is being run from. Else, the user will get the prompt:
Didn't get any packet from gateway, are you sure you are running it ? Maybe run wireshark and check ?
If this happens, then the user must debug the issue by checking each route manually and trying to figure out where the problem lies.
One can also attempt to create app_config.txt manually, if one is confident about the connections. Please see manually checking the routes section to debug the issue.
The routing table configuration is done automatically by the automation script. If you open run_demo.py file then you will see the following line.
sudo ./pctools/send_1722.out --eth_interface gateway_interfaces[3] --can_id gateway_interface_lut[gateway_interfaces[1]] --update_hash_table 1 --can_mask 0x1 --eth_mask 0x0
This line is used to configure the gateway for CAN 2 CAN routing such that CAN frames can only go out of the first port. No transmit from Ethernet ports is permitted.
The –can_id option is used to provide the CAN ID and –can_mask and –eth_mask are used to configure the Eth and CAN entries.
Below, one can see the sample output from a successful unit test run for all four routes for J7200:
J7200
The setup found an existing config file : ./pctools/app_config.txt and it will be used. If you think that's incorrect or if your setup has changed then please delete : ./pctools/app_config.txt and run this script again Script will run for 1 iteration(s) Each test will run for 5 second(s) Iteration # 0 : Script will now run individual tests Script will now run CAN 2 CAN tests -------------------CAN 2 CAN Test Results---------------------- Number of CAN frames sent : 27823 Number of CAN frames received : 27810 Test ran for : 5 seconds Average CAN 2 CAN delay : 101 us Max CAN 2 CAN delay : 382 us Average CPU Load : 13.297297 % Average SWI Load : 0.000000 % Average ISR Load : 0.000000 % CAN Rx rate : 5564 msgs/sec CAN Tx rate : 5562 msgs/sec CPU Load for 8k CAN (Rx + Tx) : 191.21452375388708 Mhz Script will now run CAN 2 Eth tests -------------------CAN 2 ETH Test Results---------------------- Number of CAN frames sent : 27823 Number of Eth frames received : 27820.0 Test ran for : 5 seconds Average CAN 2 Eth delay : 132 us Max CAN 2 Eth delay : 336 us Average CPU Load : 13.297297 % Average SWI Load : 0.000000 % Average ISR Load : 0.000000 % CAN Rx rate : 5564 msgs/sec Eth Tx rate : 5564 msgs/sec CPU Load for 8k CAN Rx + 8k Eth Tx : 191.18015922937298 Mhz Script will now run Eth 2 Eth tests -------------------ETH 2 ETH Test Results---------------------- Number of Eth frames sent : 66408 Number of Eth frames received : 66408 Test ran for : 5 seconds Average ETH 2 ETH delay : 222 us Max ETH 2 ETH delay : 877 us Average CPU Load : 13.297297 % Average SWI Load : 0.000000 % Average ISR Load : 0.000000 % Eth Rx rate : 13281 msgs/sec Eth Tx rate : 13281 msgs/sec CPU Load for 8k Eth Rx + Tx : 80.0945488495362 Mhz Script will now run Eth 2 CAN tests -------------------ETH 2 CAN Test Results---------------------- Number of Eth frames sent : 29556 Number of CAN frames received on 1st interface : 29556 Test ran for : 5 seconds Average ETH 2 CAN delay for 1st interface : 119 us Max ETH 2 CAN delay for 1st interface : 202 us Average CPU Load : 13.297297 % Average SWI Load : 0.000000 % Average ISR Load : 0.000000 % Eth Rx rate : 5911 msgs/sec CAN Tx rate : 5911 msgs/sec CPU Load for 8k Eth Rx + 8k CAN Tx : 179.96071186899445 Mhz Iteration # 0 completed
The command used to execute this test is:
python3 pctools/run_demo.py --iterations 1 --run_time 5 --system_test 0 --gui_enabled 0
As explained before, to run the unit tests, execute the command:
python3 pctools/run_demo.py --iterations 1 --run_time 5 --system_test 0 --gui_enabled 0
This will cycle through all the 4 routes, CAN-to-CAN, CAN-to-Eth, Eth-to-Eth and Eth-to-CAN cyclically once, while also displaying the statistics.
To run system tests, first run the GUI.
The GUI is packaged as a downloadable tarball in the Processor SDK Linux download page. The link is titled can-eth-gateway-demo-gui.tar.gz.
The GUI binaries have been compiled on an x86 machine running Ubuntu 18.04. If another Operating System or Ubuntu version is being used, then this will not work. At the moment, there is no plan to provide sources for compiling the GUI on a different Operating System.
The GUI has run-time dependencies on the Open Framework module, to install them follow the steps below.
- Go to the downloads page and get the Linux package for GCC6+
- Run the command
./install_dependencies.shas described on this page
To run the GUI, extract the tarball in your machine at the location <GUI_INSTALL_DIR> and run the following commands to run the data aggregator:
cd <GUI_INSTALL_DIR>/aggregator/bin ./makefifo.sh ./ces-gui-data-aggregator
This will create the pipes and launch the aggregator, which serves as an Inter Process Communication system between the GUI and the PC tools.
Now, to run the actual GUI, run the following command in another terminal:
cd <GUI_INSTALL_DIR>/gui/bin ./ces2020-gui-template
This will launch a GUI which looks like this:
Now to see the GUI in action, run the following command in peak-linux-driver-8.16.0/test folder:
python3 pctools/run_demo.py --iterations 1 --run_time 20 --system_test 1 --gui_enabled 1
This will run the system tests for 20 seconds. If you see the GUI while the test is running, you will see the bars and dials moving.
This section describes how to manually check all four routes using the PCAN-USB FD tool or, for that matter, any other tool. Information provided here can also be used to debug the setup. We now describe how to test each route separately.
Note: Do not use 0xAA as the first byte of any CAN message sent to CAN Eth Gateway as it's reserved for test automation
There are two CAN-to-CAN routes, MCAN4 to MCAN9 and vice versa. The routing is decided based on the value of some bytes in the CAN-FD message. These byte offsets have been chosen keeping future requirements in mind. If the user is using the customised tools provided with the demo, then this is handled automatically based on command line arguments. But if user has their own tools, then they need to re-create the message and use the particular Message ID.
The CAN ports on the Gateway (Jacinto 7 EVM) can only accept a particular extended message ID. This is documented below:
| CAN Port | Message ID |
|---|---|
| MCAN4 | 0xD0 |
| MCAN9 | 0xE0 |
If you see the sample app_config.txt file, then you will find the same information.
To send an extended CAN FD message from MCAN4 to MCAN9, run the following command in peak-linux-driver-8.16.0/test directory:
./pcanfdtst tx CAN_ONLY --bitrate 1000000 --dbitrate 5000000 --clock 80000000 -n 1 -ie 0xD0 --fd -l 64 --tx-pause-us 1000 /dev/pcanusbfd32
Here, we assume that /dev/pcanusbfd32 is connected to MCAN4.
This will send 1 CAN message with the ID 0xD0 with correct formatting to the gateway, which will route it to MCAN9.
To listen and display the CAN message being received on MCAN9, run the following command in another terminal:
./pcanfdtst rx --bitrate 1000000 --dbitrate 5000000 --clock 80000000 --fd -M 10 /dev/pcanusbfd33
If routing from MCAN9 to MCAN4, use the same message but change the message ID and CAN port. So the command will change to:
./pcanfdtst tx CAN_ONLY --bitrate 1000000 --dbitrate 5000000 --clock 80000000 -n 1 -ie 0xE0 --fd -l 64 --tx-pause-us 1000 /dev/pcanusbfd33
On the listener side, we will change the command to listen on a different port:
./pcanfdtst rx --bitrate 1000000 --dbitrate 5000000 --clock 80000000 --fd -M 10 /dev/pcanusbfd32
To do CAN-to-ETH routing, we need to configure the routing table appropriately as described in this section
To send on second Eth port, set the eth_mask field to 0x2. If sending on both Ethernet ports then eth_mask field should be 0x3. While doing CAN to Eth routing, can_mask should be 0 or else there will be CAN 2 CAN routing.
To send packet from MCAN4 to both ETH ports, run this command:
./pcanfdtst tx ETH_ONLY --bitrate 1000000 --dbitrate 5000000 --clock 80000000 -n 1 -ie 0xD0 --fd -l 64 --tx-pause-us 1000 /dev/pcanusbfd32
On the listener side, we need to run this command in pctools directory to check for Ethernet frames:
sudo ./recv_1722.out --eth_interface eth0 --timeout 12 --pipes 0
Here, we assume that eth0 interface is connected to one of the GESI ethernet ports as shown in J7 Board setup.
To do Eth to Eth routing there are two requirements.
- The ethernet packet to be sent must have the gateway MAC ID as it's destination MAC ID, this is a general requirement for sending any ethernet packet to the gateway.
- The device must be aware of the MAC ID of the PC port on which it is to send a packet.
Both these requirements are taken care of by the send_1722.c tool, which reads the app_config.txt configuration file to know the PC and gateway device MAC addresses. The second requirement to tell the device about the MAC ID of the PC is also taken care of by the send_1722.c tool.
To configure the MAC address on the device, use the following command (also present in run_demo.py)
sudo ./pctools/send_1722.out --eth_interface ``70:ff:76:1d:92:c1`` --send_mac_address 1
Additionally user must configure the routing table by setting the can_mask to 0 and eth_mask to appropriate value based on routing requirement.
To send packets, run the following command in the pctools directory:
sudo ./send_1722.out --eth_interface eth0 --gateway_mac 70:ff:76:1d:92:c1 --dst_mac 00:ad:24:8f:f6:4e --ipg 1000 --route ETH --num_packets 10
This will send 10 packets on the interface eth0 to gateway device with a MAC ID of 70:ff:76:1d:92:c1, where the MAC ID of other ethernet interface is 00:ad:24:8f:f6:4e. Here, --ipg 1000 will add an approximate delay of 1000 us between two ethernet frames.
To receive packets, run the following command in the pctools directory:
sudo ./recv_1722.out --eth_interface eth1 --timeout 12 --pipes 0
To change routing from eth1 to eth0, swap the interface names and MAC ID in the sender and listener commands.
Here, we assume that eth0 and eth1 are ethernet interfaces connected to the GESI card.
To do Ethernet to CAN routing, we need to configure eth_mask and can_mask appropriately (see CAN to CAN section above) and run Ethernet sender and CAN receiver tasks.
Send 10 packets from eth0 to MCAN4 at an IPG of 1ms:
sudo ./send_1722.out --eth_interface eth0 --gateway_mac 70:ff:76:1d:92:c1 --ipg 1000 --route MCAN4 --num_packets 10
Listen on MCAN4 for CAN messages for 10 seconds:
./pcanfdtst rx --bitrate 1000000 --dbitrate 5000000 --clock 80000000 --fd -M 10 /dev/pcanusbfd32
Here, we assume that /dev/pcanusbfd32 is connected to MCAN4.
The tool also supports sending output to both CAN ports. To do that, change the --route option to BOTH:
sudo ./send_1722.out --eth_interface eth0 --gateway_mac 70:ff:76:1d:92:c1 --ipg 1000 --route BOTH --num_packets 10
For more details about installation of CCS and J7200 target creation, refer to the Processor SDK RTOS User's Guide inside "psdk_rtos/docs/user_guide" folder, which can be found in SDK installation.
- Connect a micro USB cable to JTAG port of J7200 EVM. The XDS110 JTAG connector is labeled
XDS110(J3). - Connect a micro USB cable to Main Domain UART port on J7200 EVM. Its labeled
Main UART(J44). This will create 4 UART ports from /dev/ttyUSB0 to /dev/ttyUSB3 - Set EVM's DIP switches
SW8andSW9for no-boot mode:- SW8 = 10001000
- SW9 = 01110000
- Power on the J7200 EVM board. Ensure that SD card is not present or QSPI flashed.
- Open up a serial terminal to ttyUSB2 (third instance) for UART communication. This will show logs from MAIN_Cortex_R5F_0_1 core where the Ethernet remote switch runs.
- Set serial parameters to: 115200 8N1.
- Set hardware and software flow control to "No".
- Below figure shows serial parameters set in Minicom.
- Open CCS and launch target config file for J7200 EVM.
- Initialize the SoC and load system firmware using the
launch.jsscript at <SDK_INSTALL_PATH>/pdk_j7200_11_00_00_21/packages/ti/drv/sciclient/tools/ccsLoadDmsc/j7200. - Wait for initialization and then connect to MCU_Cortex_R5_0. If there is already an application loaded then do a CPU Reset (Shift + Ctrl + R) and load and run the executable
<SDK_INSTALL_PATH>/gateway-demos/binary/can_traffic_generator_app_freertos/bin/j7200/can_traffic_generator_app_freertos_mcu1_0_release.xer5f.
- Now connect to MAIN_Cortex_R5F_0_1 and load and run the demo executable:
<SDK_INSTALL_PATH>/gateway-demos/binary/can_eth_gateway_app_freertos/bin/j7200/can_eth_gateway_app_freertos_mcu2_1_release.xer5f
- Now connect MAIN_Cortex_R5F_0_0 and load and run the demo executable:
<SDK_INSTALL_PATH>/ethfw/out/J7200/R5Ft/FREERTOS/release/app_remoteswitchcfg_server_ccs.xer5f
- To load all binaries at once, use the gateway launch script available in <SDK_INSTALL_PATH>/gateway-demos/launch_script/j7200/gateway_launch.js
Note: User must first run the gateway app on MAIN_Cortex_R5F_0_1 followed by a delay of 5 seconds before running the Ethernet firmware on MAIN_Cortex_R5F_0_0 to enable synchronization.
- The application should boot up with the CCS log shown below. Note that the Ethernet interface takes a few seconds to come up:
- The
70:ff:76:1d:92:c1value shown above refers to the MAC address of the Gateway and is the same one that is used in ETH to ETH routing. It will change from device to device. - If UART is connected, then the user will see the following log from remote switch driver indicating a successful boot:
OSPI boot is currently not functional for J7200, the alternative is to use CCS Boot. See (here)
- OSPI boot mode is the fastest boot mode and the recommended option for evaluating gateway demo applications.
- Download TI's uniflash tool from https://www.ti.com/tool/UNIFLASH (Ver. 6.1.0) and install in your Linux machine.
- Connect a micro USB cable to MCU Domain UART port on J7200 EVM. Its labeled
MCU UART(J43). - Open up a serial terminal to port ttyUSB1 for UART1 communication. This will be used to verify boot mode and flash OSPI binaries.
- Set serial parameters to: 115200 8N1.
- Set EVM's DIP switches
SW8andSW9for UART boot mode:- SW8 = 00000000
- SW9 = 01110000
Power cycle the EVM. You should see continuous
CCCCprints on the console. This means that the EVM is now in UART boot mode and ready to flash OSPI binaries.> Close the serial terminal or you won't be able to flash the binaries.
- Build the binaries required for a successful OSPI boot.
- Execute the following command in <SDK_INSTALL_PATH>/pdk_j7200_11_00_00_21/packages/ti/build:
make -s sbl_ospi_img
- Run the script
gen_combined_image.shin <SDK_INSTALL_PATH>/gateway-demos/pctools to generate the imageapp_switch2.appimage
- Execute the following command in <SDK_INSTALL_PATH>/pdk_j7200_11_00_00_21/packages/ti/build:
Please edit the script
gen_combined_image.shas per your requirement as the paths may not match sometimes
- Now copy the following binaries and keep them in one folder, let's call it <OSPI_BINARIES>.
- Copy the bootloader
<SDK_INSTALL_PATH>/pdk_j7200_11_00_00_21/packages/ti/boot/sbl/binary/j7200_evm/ospi/bin/sbl_ospi_img_mcu1_0_release.tiimageto <OSPI_BINARIES> and rename it totiboot3.bin. - Copy System firmware
<SDK_INSTALL_PATH>/pdk_j7200_11_00_00_21/packages/ti/drv/sciclient/soc/V1/tifs.binto <OSPI_BINARIES>. - Copy
app_switch2.appimageto <OSPI_BINARIES>. - Copy
pdk\packages\ti\board\src\flash\nor\ospi\nor_spi_patterns.binto <OSPI_BINARIES>
- Copy the bootloader
- Navigate to the folder where Uniflash tool was installed and run the following command:
sudo ./dslite.sh --mode processors -c /dev/ttyUSB1 -f /<PATH_TO_UNIFLASH_TOOL>/uniflash_6.1.0/processors/FlashWriter/j7200_evm/uart_j7200_evm_flash_programmer_release.tiimage -i 0
- If successful, then flash the following images, else power cycle the board and restart. Check for any open connections to the UART if trouble persists.
- Run the following commands in succession:
sudo ./dslite.sh --mode processors -c /dev/ttyUSB1 -f <OSPI_BINARIES>/tiboot3.bin -d 3 -o 0 sudo ./dslite.sh --mode processors -c /dev/ttyUSB1 -f <OSPI_BINARIES>/sysfw.bin -d 3 -o 80000 sudo ./dslite.sh --mode processors -c /dev/ttyUSB1 -f <OSPI_BINARIES>/app_switch2.appimage -d 3 -o 100000 sudo ./dslite.sh --mode processors -c /dev/ttyUSB1 -f <OSPI_BINARIES>/nor_spi_patterns.bin -d 3 -o 3FC0000(J7200)
- On J7200, Set EVM's DIP switches
SW8andSW9for xSPI boot mode- SW8 = 10000010
- SW9 = 00110000
- Connect a micro USB cable to Main Domain UART port on J7200_EVM. Its labeled
Main UART(J44). - Open up a serial terminal to port ttyUSB4 for UART2 communication. This will be used to verify whether gateway application has booted correctly.
- Set serial parameters to: 115200 8N1.
- Power cycle the EVM. Gateway application should boot up, and you will see the log from Ethernet Firmware (see above).
The Out of Box demo is identical to the regular demo with the exception that no PCAN-USB devices are used. Hence it's much easier to setup.
To run the demo, the following connections need to be made
- Connect MCAN 0 <--> MCAN 4
- Connect MCAN 1 <--> MCAN 9
See the picture below on how connections are made with the help of two color coded jumper cable strips.
Note: Out of Box demo does not support GUI or Manual checking of the routes
- The low latency demo is a modified version of the
can_traffic_generator_appand it's used to showcase that J7 family of devices are capable of routing traffic from one CAN port to another with extremely low latency. - See this section on how to build it.
- Running the demo is very simple. Connect a CAN device each to MCU MCAN0 and MCU MCAN1 ports.
- Send a message with the extended CAN ID
0xD0to MCU MCAN0 and it gets routed to MCU MCAN1 by default. The reverse is not true. - The latency is embedded in the 7th byte (counting from 1) of the payload in microsecond units.
- If using the patched PCAN tool, then the average and maximum values are reported by the tool itself.
- To send 10 CAN messages with the extended ID
0xD0on say /dev/pcan32 which is connected to MCU MCAN0, use the following command:./pcanfdtst tx --bitrate 1000000 --dbitrate 5000000 --clock 80000000 -ie 0xD0 --fd --brs -l 64 -w -n 10 /dev/pcan32
- To receive a CAN messages on say /dev/pcan33 which is connected to MCU MCAN1, use this command :
./pcanfdtst NO_GUI rx --bitrate 1000000 --dbitrate 5000000 --clock 80000000 -q /dev/pcan33
- When all packets have been sent, use Ctr-C to terminate the receiver application.
See picture below regarding connections. The MCU MCAN0 and MCU MCAN1 ports are the same ones which are used for OOB demo, except that they are connected to PCAN devices now.
Three types of statistics are of concern to use when running gateway application.
- Bridge Delay or Latency : The time taken by Gateway to route a packet. This is measured internally by the gateway through timestamps, which is then inserted into the outgoing packet by the Gateway so it can be parsed by external tools. See figure below to understand more on how this is done.
- Throughput : The number of packets sent/received in a given amount of time. This is calculated by external tools.
- CPU Load : Gateway application measures it periodically in percentage terms and communicates this to recv_1722.out application. The tool, in turn, calculates an average and displays it along with other test results.
When a unit test is run, the test automation script automatically displays all the statistics from the test run.
- Refer to the Release Notes (
index.html) at <SDK_INSTALL_PATH>/gateway-demos - Out of Box and low-latency demos can't be evaluated as Can traffic generator app is not functional on FreeRTOS.
- OSPI boot is not functional for both DRA829 and DRA821 platforms. Use CCS boot to evaluate the demo.
- Can Eth gateway app debug binary doesn't build for J7200 due to memory constraints. Use release binary instead.
- To get correct average CPU load figures, the demo must be run for at least 30 seconds.
- Correct performance numbers cannot be gauged with Out of Box Demo
| KPIs | CAN-CAN | CAN-ETH | ETH-ETH | ETH-CAN |
|---|---|---|---|---|
| Avg. CPU Load (%) | 31.6 | 31.1 | 35.9 | 26.8 |
| Avg. Delay (us) | 215 | 167 | 239 | 125 |
| Max Delay (us) | 407 | 377 | 1556 | 335 |
| Rx Packet Rate (pps) | 5564 | 5564 | 15632 | 6297 |
| Tx Packet Rate (pps) | 5564 | 5564 | 15611 | 6297 |
