am64x/am243x: hdsl: Update documentation

- Updated the landing page, design page and example page for HDSL
- Remove DDR Trace example specific page

Fixes: PINDSW-6913

Signed-off-by: Rajul Bhambay <r-bhambay@ti.com>
This commit is contained in:
Rajul Bhambay 2023-09-14 14:47:15 +05:30 committed by Dhaval Khandla
parent f03a3f1d23
commit 254d63a73e
14 changed files with 98 additions and 191 deletions

View File

@ -8,34 +8,36 @@ The HDSL firmware running on ICSS-PRU provides a defined well interface to execu
## Features Supported
- External pulse synchronization
- Safe position
- Supports upto 100m cable
- Communication status
- Register interface to be compatible with SICK HDSL FPGA IP Core.
(except registers that have different functionality for read and
write)
- Fast position, speed
- Communication status
- External pulse synchronization
- Register interface to be compatible with SICK HDSL FPGA IP Core (apart from the differences listed in \ref HDSL_EXCEPTIONS_LIST)
- Parameter channel communication
short message write
Short message read
Long message read
Long message write
- Short message
- Long message
- Safety
- Two channels support on am243x-evm
- Single channel support on am243x-lp
- Tested with three different encoder makes (EDM35, EKS36, EKM36)
## Features Not Supported
In general, peripherals or features not mentioned as part of "Features Supported" section are not
supported, including the below
- Pipeline channel
- Safety
- 100m cable
- Three channel support using single PRU-ICSSG slice
- Pipeline Channel
## SysConfig Features
@VAR_SYSCFG_USAGE_NOTE
SysConfig can be used to configure things mentioned below:
- Selecting the ICSSG0PRUx instance.(Tested on ICSSG0-PRU1)
- Configuring PINMUX.
- Configuring PINMUX
- Channel selection
- Mode Selection (Free run/Sync mode)
- Hardware selection (Booster Pack for am243x-lp)
## HDSL Design
@ -47,12 +49,11 @@ SysConfig can be used to configure things mentioned below:
## Exceptions
\subpage HDSL_EXCEPTIONS_LIST lists the exceptions TI's HDSL implementation when compared with SICK HDSL FPGA IP Core. Please note that all the corresponding register fields are not implemented.
\subpage HDSL_EXCEPTIONS_LIST lists the exceptions TI's HDSL implementation when compared with SICK HDSL FPGA IP Core. Please note that all the corresponding register fields are not implemented.
## Example
- \ref EXAMPLE_MOTORCONTROL_HDSL
- \ref EXAMPLE_MOTORCONTROL_HDSL_TRACE
\ref EXAMPLE_MOTORCONTROL_HDSL
## API
\ref HDSL_API_MODULE

View File

@ -89,3 +89,55 @@ Remote (DSL motor feedback system) registers that indicate interface information
Note: It should be noted that a "short message" can be triggered during a running "long message" transaction.
## Synchronization with External Pulse {#HDSL_DESIGN_SYNC}
According to the Hiperface DSL specification, the falling edge inside the EXTRA window should coincide with the external synchronization pulse.
At the beginning of the startup phase, the firmware measures the time interval of the external pulse and calculates the required number of bits for the H-Frame.
Based on this number the stuffing length and EXTRA window size is derived.
Afterwards, the PRU waits to match its timing with the timing of the external synchronization pulse and starts the transmission.
Since it is possible to use time intervals for the external pulse that are not multiples of the bit duration, the firmware needs to adjust the H-Frame size on the fly.
Furthermore, during the EXTRA window the PRU transmits the data (sample edge) with a granularity of 13.3ns to increase the synchronization accuracy. Figure "Synchronization of External Pulse with Sample Edge in EXTRA Window" and "Illustration of Synchronization Algorithm" depict the concept.
The EXTRA_TIME_WINDOW is a fixed value that is calculated at startup to match the external pulse frequency. The TIME_REST value gives the number of overclocked 1 that needs to be sent during the last bit of the EXTRA window.
\imageStyle{hdsl_external_sync.png,width:40%}
\image html hdsl_external_sync.png "Synchronization of External Pulse with Sample Edge in EXTRA Window"
In other words, the TIME_REST value represents the sample edge in a fine granularity dimension (13.3ns). While the sample edge can be send with a finer granularity, the granularity of the size of the EXTRA window is still in whole bit durations (106.67ns).
Consequently, there is an overhead, if the external pulse period is not a multiple of the bit duration. This overhead is compensated in the next H-Frame by changing the size of the EXTRA window. As a result, the size of the H-Frame is varying over time.
It is possible that these calculations lead to the excess of the maximum or minimum EXTRA window size. Therefore, the number of bits for the stuffing and EXTRA window is readjusted on a violation.
\imageStyle{hdsl_sync_algo.png,width:40%}
\image html hdsl_sync_algo.png "Illustration of Synchronization Algorithm"
The algorithm is given as C code in the following:
/* EXTRA_SIZE equals the number of bits for the EXTRA window minus 1 */
if(EXTRA_EDGE == 0)
TIME_REST += 8;
short b = (EXTRA_SIZE << 3) + TIME_REST;
short overhead = (EXTRA_SIZE << 3) + 8 - TIME_EXTRA_WINDOW;
EXTRA_SIZE = (b - overhead) >> 3;
TIME_REST = (b - overhead) - (EXTRA_SIZE << 3);
if(EXTRA_SIZE < 3) {
EXTRA_SIZE += 6;
NUM_STUFFING -= 1;
TIME_EXTRA_WINDOW += (8*6);
}
if(EXTRA_SIZE > 8) {
EXTRA_SIZE -= 6;
NUM_STUFFING += 1;
TIME_EXTRA_WINDOW -= (8*6);
}
EXTRA_EDGE represents the TIME_REST value in a format that can be pushed to the TX FIFO for transmission. For instance, if TIME_REST is 4, EXTRA_EDGE is 0xf0. The edge would be in the middle of the bit duration. The value NUM_STUFFING gives the number of stuffing blocks (each block consist of 6 bits).
For further improvement of the synchronization, the time difference (∆t) between the external pulse and the sample edge we transmit is measured (Figure "Time difference between External Pulse and Sample Edge").
\imageStyle{hdsl_external_sync_sample_edge.png,width:40%}
\image html hdsl_external_sync_sample_edge.png "Time difference between External Pulse and Sample Edge"
Sync pulse jitter is under 100ns. Please refer to the image below for jitter calculation waveforms.
\image html hdsl_sync_mode_waveforms.png "HDSL Sync mode waveforms for 2 channels"
\image html hdsl_sync_mode_jitter.jpg "HDSL Sync mode jitter analysis"

View File

@ -1,6 +1,5 @@
INPUT+= $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/examples/examples.md
INPUT+= $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/examples/hdsl_example.md
INPUT+= $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/examples/hdsl_example_trace.md
INPUT+= $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/examples/endat_example.md
INPUT+= $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/examples/tamagawa_example.md
INPUT+= $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/examples/sdfm_example.md

View File

@ -1,6 +1,5 @@
INPUT+= $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/examples/examples.md
INPUT+= $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/examples/hdsl_example.md
INPUT+= $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/examples/hdsl_example_trace.md
INPUT+= $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/examples/endat_example.md
INPUT+= $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/examples/tamagawa_example.md
INPUT+= $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/examples/sdfm_example.md

View File

@ -3,7 +3,6 @@ This page lists all the examples and demos supported in this SDK.
\cond SOC_AM64X || SOC_AM243X
-# \subpage EXAMPLE_MOTORCONTROL_ENDAT
-# \subpage EXAMPLE_MOTORCONTROL_HDSL
-# \subpage EXAMPLE_MOTORCONTROL_HDSL_TRACE
-# \subpage EXAMPLE_MOTORCONTROL_TAMAGAWA
-# \subpage EXAMPLE_MOTORCONTROL_SDFM
\endcond

View File

@ -5,7 +5,7 @@
The HDSL diagnostic application described here interacts with the firmware interface.
HDSL diagnostic application does below,
- Configures pinmux, GPIO, ICSS clock to 225MHz,
- Configures pinmux, GPIO, ICSS clock to 300MHz,
- Initializes ICSS0-PRU1, ICSS0-IEP0 and IEP1(for SYNC mode support.Timesync router is used to latch the loopback.),
- Loads lookup table for encoding/decoding of Hiperface data
- Loads the initialization section of PRU firmware & executes it.
@ -14,6 +14,15 @@ Firmware is split to three sections, initialization, datalink and transport.
At startup, the application displays details about encoder and status.
It then presents the user with menu options, based on the option selected, application communicates with HDSL interface and the result is presented to the user.
This example also allows the capability to save the HDSL register data into memory for the defined duration.
\cond SOC_AM243X
- For @VAR_BOARD_NAME_LOWER example, the data is stored in DDR.
- For @VAR_LP_BOARD_NAME_LOWER example, the data is stored in MSRAM.
\endcond
\note The HDSL register trace option is only available with debug mode builds for single channel examples.
## Important files and directory structure
<table>
@ -64,7 +73,7 @@ It then presents the user with menu options, based on the option selected, appli
ICSSG | ICSSG0
PRU | PRU1
Toolchain | ti-arm-clang
Board | @VAR_BOARD_NAME_LOWER, @VAR_LP_BOARD_NAME_LOWER
Board | @VAR_BOARD_NAME_LOWER (2 channel and 1 channel examples), @VAR_LP_BOARD_NAME_LOWER (1 channel example)
Example folder | examples/motorcontrol/hdsl_example
\endcond
@ -189,70 +198,26 @@ Other than the basic EVM setup mentioned in \htmllink{@VAR_MCU_SDK_DOCS_PATH/EVM
- Launch a CCS debug session and run the executable, see \htmllink{@VAR_MCU_SDK_DOCS_PATH/CCS_LAUNCH_PAGE.html, CCS Launch\, Load and Run}
- Refer to UART terminal for user interface menu options.
# Sync Mode:
- Note
This is a test feature, in real application - PWM syncout will be connected to Latch input instead of IEP1 sync.
## Synchronization with external Pulse
According to the Hiperface DSL specification, the falling edge inside the EXTRA window should coincide with the external synchronization pulse.
At the beginning of the startup phase, the firmware measures the time interval of the external pulse and calculates the required number of bits for the H-Frame.
Based on this number the stuffing length and EXTRA window size is derived.
Afterwards, the PRU waits to match its timing with the timing of the external synchronization pulse and starts the transmission.
Since it is possible to use time intervals for the external pulse that are not multiples of the bit duration, the firmware needs to adjust the H-Frame size on the fly.
Furthermore, during the EXTRA window the PRU transmits the data (sample edge) with a granularity of 13.3ns to increase the synchronization accuracy. Figure "Synchronization of External Pulse with Sample Edge in EXTRA Window" and "Illustration of Synchronization Algorithm" depict the concept.
The EXTRA_TIME_WINDOW is a fixed value that is calculated at startup to match the external pulse frequency. The TIME_REST value gives the number of overclocked 1 that needs to be sent during the last bit of the EXTRA window.
\imageStyle{hdsl_external_sync.png,width:40%}
\image html hdsl_external_sync.png "Synchronization of External Pulse with Sample Edge in EXTRA Window"
In other words, the TIME_REST value represents the sample edge in a fine granularity dimension (13.3ns). While the sample edge can be send with a finer granularity, the granularity of the size of the EXTRA window is still in whole bit durations (106.67ns).
Consequently, there is an overhead, if the external pulse period is not a multiple of the bit duration. This overhead is compensated in the next H-Frame by changing the size of the EXTRA window. As a result, the size of the H-Frame is varying over time.
It is possible that these calculations lead to the excess of the maximum or minimum EXTRA window size. Therefore, the number of bits for the stuffing and EXTRA window is readjusted on a violation.
\imageStyle{hdsl_sync_algo.png,width:40%}
\image html hdsl_sync_algo.png "Illustration of Synchronization Algorithm"
The algorithm is given as C code in the following:
/* EXTRA_SIZE equals the number of bits for the EXTRA window minus 1 */
if(EXTRA_EDGE == 0)
TIME_REST += 8;
short b = (EXTRA_SIZE << 3) + TIME_REST;
short overhead = (EXTRA_SIZE << 3) + 8 - TIME_EXTRA_WINDOW;
EXTRA_SIZE = (b - overhead) >> 3;
TIME_REST = (b - overhead) - (EXTRA_SIZE << 3);
if(EXTRA_SIZE < 3) {
EXTRA_SIZE += 6;
NUM_STUFFING -= 1;
TIME_EXTRA_WINDOW += (8*6);
}
if(EXTRA_SIZE > 8) {
EXTRA_SIZE -= 6;
NUM_STUFFING += 1;
TIME_EXTRA_WINDOW -= (8*6);
}
EXTRA_EDGE represents the TIME_REST value in a format that can be pushed to the TX FIFO for transmission. For instance, if TIME_REST is 4, EXTRA_EDGE is 0xf0. The edge would be in the middle of the bit duration. The value NUM_STUFFING gives the number of stuffing blocks (each block consist of 6 bits).
For further improvement of the synchronization, the time difference (∆t) between the external pulse and the sample edge we transmit is measured (Figure "Time difference between External Pulse and Sample Edge").
\imageStyle{hdsl_external_sync_sample_edge.png,width:40%}
\image html hdsl_external_sync_sample_edge.png "Time difference between External Pulse and Sample Edge"
# Mode, Channel(s) and Board Selection from sysconfig:
- Select Mode from sysconfig menu (Freerun/sync mode).
- Select Channel 0/channel 1 from sysconfig menu for channel selection.
- Select Boosterpack option from sysconfig for running application on AM243x-LP.
\imageStyle{hdsl_sysconfig_menu.png,width:60%}
\image html hdsl_sysconfig_menu.png "HDSL SYSCONFIG Menu"
# Sample Output
Shown below is a sample output when the application is run:
Shown below is a sample output when the application is run
- Freerun mode:
\imageStyle{hdsl_default_uart_menu.PNG,width:60%}
\image html hdsl_default_uart_menu.PNG "HDSL DDR UART Default Menu"
- Freerun mode
\image html hdsl_freerun_menu.png "HDSL Freerun mode Menu"
\image html hdsl_positional_commands_menu.png "HDSL Freerun mode Menu"
- Sync Mode:
\imageStyle{HDSL_SYNC.png,width:60%}
\image html HDSL_SYNC.png "HDSL Diagnostic in SYNC mode"
- Sync Mode
This is a test feature. In real application, PWM syncout will be connected to Latch input instead of IEP1 sync.
Enter 6000 as period in UART menu after loading application. Refer \ref HDSL_DESIGN_SYNC for more details about sync mode.
\image html hdsl_sync_mode_menu1.png "HDSL Sync mode Menu"
\image html hdsl_sync_mode_menu2.png "HDSL Sync mode Menu"
\image html hdsl_positional_commands_menu.png "HDSL Sync mode Menu"

View File

@ -1,108 +0,0 @@
# HDSL Diagnostic with Traces {#EXAMPLE_MOTORCONTROL_HDSL_TRACE}
[TOC]
## Introduction
The HDSL diagnostic application described here interacts with the firmware interface.
HDSL diagnostic application does below,
Configures pinmux, GPIO, ICSS clock to 225MHz,
Initializes ICSS0-PRU1, ICSS0-IEP0 and IEP1(for SYNC mode support.Timesync router is used to latch the loopback.),
Loads lookup table for encoding/decoding of Hiperface data
Loads the initialization section of PRU firmware & executes it.
Firmware is split to three sections, initialization, datalink and transport. At startup, the application displays details about encoder and status. It then presents the user with menu options, based on the option selected, application communicates with HDSL interface and the result is presented to the user.
## Important files and directory structure
<table>
<tr>
<th>Folder/Files
<th>Description
</tr>
<tr><td colspan="2" bgcolor=#F0F0F0> ${SDK_INSTALL_PATH}/examples/motor_control/hdsl_diagnostic_with_traces</td></tr>
<tr>
<td>hdsl_diagnostic_ddr.c
hdsl_diagnostic_ddr.h</td>
</tr>
<tr><td colspan="2" bgcolor=#F0F0F0> ${SDK_INSTALL_PATH}/source/position_sense/hdsl</td></tr>
<tr>
<td>driver/</td>
<td>Folder containing HDSL PRU driver sources.</td>
</tr>
<tr>
<td>include/</td>
<td>Folder containing HDSL PRU header sources.</td>
</tr>
<tr>
<td>firmware/</td>
<td>Folder containing HDSL PRU firmware sources.</td>
</tr>
</table>
\cond SOC_AM64X || SOC_AM243X
Parameter | Value
---------------|-----------
CPU + OS | r5fss0-0 freertos
ICSSG | ICSSG0
PRU | PRU1
Toolchain | ti-arm-clang
Board | @VAR_BOARD_NAME_LOWER
Example folder | examples/motorcontrol/hdsl_example
\endcond
# Steps to Run the Example
## Hardware Prerequisites
Other than the basic EVM setup mentioned in \htmllink{@VAR_MCU_SDK_DOCS_PATH/EVM_SETUP_PAGE.html, EVM Setup}, below additional HW is required to run this demo
- HDSL encoder
- Below are two options to connect encoder to AM64x/AM243x EVM.
- **Option 1**
- TIDA-00179 Universal Digital Interface to Absolute Position Encoders, http://www.ti.com/tool/TIDA-00179
- TIDEP-01015 3 Axis board
- Interface card connecting EVM and TIDEP-01015 3 Axis board
- Connect the Hiperface DSL encoder to HDSL+/-(Pin number 6 and 7) signals available on header J7 or Sub-D15 connector of the "Universal Digital Interface to Absolute Position Encoders" board.
- **Option 2**
- HDSL AM64xE1 Transceiver. If application is using this card, define the macro HDSL_AM64xE1_TRANSCEIVER in the CCS project/make file.
- Connect the Hiperface DSL encoder to J10.
- HDSL AM64xE1 Transceiver supports two channels that can be used to support HDSL safety, multi axis servo drives.
- Schematics are shared in the MCU+SDK package. For more design details of the transceiver card, please contact TI via E2E/FAE.
- \htmllink{../am64x_am243x/HDSL_AM64xE1_Schematics.pdf, HDSL Transceiver Card Schematics} document.
## Hardware Setup(Using TIDA-00179, TIDEP-01015 and Interface board)
\imageStyle{HDSL_Connections.png,width:40%}
\image html HDSL_Connections.png "Hardware Setup"
## Hardware Setup(Using HDSL AM64xE1 Transceiver)
\imageStyle{HDSL_AM64xE1.png,width:60%}
\image html HDSL_AM64xE1.png "Hardware Setup"
## Build, load and run
- **When using CCS projects to build**, import the CCS project and build it using the CCS project menu (see \htmllink{@VAR_MCU_SDK_DOCS_PATH/CCS_PROJECTS_PAGE.html, Using SDK with CCS Projects}).
- **When using makefiles to build**, note the required combination and build using
make command (see \htmllink{@VAR_MCU_SDK_DOCS_PATH/MAKEFILE_BUILD_PAGE.html, Using SDK with Makefiles})
- Launch a CCS debug session and run the executable, see \htmllink{@VAR_MCU_SDK_DOCS_PATH/CCS_LAUNCH_PAGE.html, CCS Launch\, Load and Run}
- Refer to UART terminal for user interface menu options.
\imageStyle{hdsl_ddr_trace.png,width:60%}
\image html hdsl_ddr_trace.png "HDSL DDR Traces Flow Chart"
###Note:
- If you are using load_dmsc.js file for initialization, Then Go to menu Scripts --> AM64 DDR Initialization -> AM64_DDR_Initialization_ECC_Disabled to initialize DDR.
- If you are using SBL NULL. DDR initialization will be taken care itself.
# Sample Output
Shown below is a sample output when the application is run:
- Freerun mode:
\imageStyle{hdsl_ddr_uart.png,width:60%}
\image html hdsl_ddr_uart.PNG "HDSL DDR UART Menu"

Binary file not shown.

After

Width:  |  Height:  |  Size: 82 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 98 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 112 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 124 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 74 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 119 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 356 KiB