-
-KR260 Documentation
-
-Redirecting to the main page.
-
+
+
+
+ Redirecting...
+
+
+ If you are not redirected automatically, please click here.
\ No newline at end of file
diff --git a/kd240/build/doctrees/docs/bist/bist_landing.doctree b/kd240/build/doctrees/docs/bist/bist_landing.doctree
index e3efc8f0..daf989f5 100644
Binary files a/kd240/build/doctrees/docs/bist/bist_landing.doctree and b/kd240/build/doctrees/docs/bist/bist_landing.doctree differ
diff --git a/kd240/build/doctrees/docs/bist/docs/known_issues.doctree b/kd240/build/doctrees/docs/bist/docs/known_issues.doctree
index e8e528e4..7b3e5662 100644
Binary files a/kd240/build/doctrees/docs/bist/docs/known_issues.doctree and b/kd240/build/doctrees/docs/bist/docs/known_issues.doctree differ
diff --git a/kd240/build/doctrees/docs/bist/docs/modules/can.doctree b/kd240/build/doctrees/docs/bist/docs/modules/can.doctree
index 3df0b26c..f4495bd9 100644
Binary files a/kd240/build/doctrees/docs/bist/docs/modules/can.doctree and b/kd240/build/doctrees/docs/bist/docs/modules/can.doctree differ
diff --git a/kd240/build/doctrees/docs/bist/docs/modules/disk.doctree b/kd240/build/doctrees/docs/bist/docs/modules/disk.doctree
index 0a742923..5ce32db0 100644
Binary files a/kd240/build/doctrees/docs/bist/docs/modules/disk.doctree and b/kd240/build/doctrees/docs/bist/docs/modules/disk.doctree differ
diff --git a/kd240/build/doctrees/docs/bist/docs/modules/display.doctree b/kd240/build/doctrees/docs/bist/docs/modules/display.doctree
index 9f8426f9..4ddf3ba9 100644
Binary files a/kd240/build/doctrees/docs/bist/docs/modules/display.doctree and b/kd240/build/doctrees/docs/bist/docs/modules/display.doctree differ
diff --git a/kd240/build/doctrees/docs/bist/docs/modules/eeprom.doctree b/kd240/build/doctrees/docs/bist/docs/modules/eeprom.doctree
index ab6a66ed..df0fe25f 100644
Binary files a/kd240/build/doctrees/docs/bist/docs/modules/eeprom.doctree and b/kd240/build/doctrees/docs/bist/docs/modules/eeprom.doctree differ
diff --git a/kd240/build/doctrees/docs/bist/docs/modules/eth.doctree b/kd240/build/doctrees/docs/bist/docs/modules/eth.doctree
index 12af1377..c6388f63 100644
Binary files a/kd240/build/doctrees/docs/bist/docs/modules/eth.doctree and b/kd240/build/doctrees/docs/bist/docs/modules/eth.doctree differ
diff --git a/kd240/build/doctrees/docs/bist/docs/modules/gpio.doctree b/kd240/build/doctrees/docs/bist/docs/modules/gpio.doctree
index c67bf548..f24d7eff 100644
Binary files a/kd240/build/doctrees/docs/bist/docs/modules/gpio.doctree and b/kd240/build/doctrees/docs/bist/docs/modules/gpio.doctree differ
diff --git a/kd240/build/doctrees/docs/bist/docs/modules/i2c.doctree b/kd240/build/doctrees/docs/bist/docs/modules/i2c.doctree
index ab44479d..fb2b9a29 100644
Binary files a/kd240/build/doctrees/docs/bist/docs/modules/i2c.doctree and b/kd240/build/doctrees/docs/bist/docs/modules/i2c.doctree differ
diff --git a/kd240/build/doctrees/docs/bist/docs/modules/iio.doctree b/kd240/build/doctrees/docs/bist/docs/modules/iio.doctree
index 44c6de5e..5d749f01 100644
Binary files a/kd240/build/doctrees/docs/bist/docs/modules/iio.doctree and b/kd240/build/doctrees/docs/bist/docs/modules/iio.doctree differ
diff --git a/kd240/build/doctrees/docs/bist/docs/modules/motor.doctree b/kd240/build/doctrees/docs/bist/docs/modules/motor.doctree
index 3641aa8e..1f6a567c 100644
Binary files a/kd240/build/doctrees/docs/bist/docs/modules/motor.doctree and b/kd240/build/doctrees/docs/bist/docs/modules/motor.doctree differ
diff --git a/kd240/build/doctrees/docs/bist/docs/modules/mtd.doctree b/kd240/build/doctrees/docs/bist/docs/modules/mtd.doctree
index 8bb83d8d..0f7c98ca 100644
Binary files a/kd240/build/doctrees/docs/bist/docs/modules/mtd.doctree and b/kd240/build/doctrees/docs/bist/docs/modules/mtd.doctree differ
diff --git a/kd240/build/doctrees/docs/bist/docs/modules/pwm.doctree b/kd240/build/doctrees/docs/bist/docs/modules/pwm.doctree
index 4b604f59..ebebeee1 100644
Binary files a/kd240/build/doctrees/docs/bist/docs/modules/pwm.doctree and b/kd240/build/doctrees/docs/bist/docs/modules/pwm.doctree differ
diff --git a/kd240/build/doctrees/docs/bist/docs/modules/spi.doctree b/kd240/build/doctrees/docs/bist/docs/modules/spi.doctree
index 994153be..8d40f9f0 100644
Binary files a/kd240/build/doctrees/docs/bist/docs/modules/spi.doctree and b/kd240/build/doctrees/docs/bist/docs/modules/spi.doctree differ
diff --git a/kd240/build/doctrees/docs/bist/docs/modules/tpm.doctree b/kd240/build/doctrees/docs/bist/docs/modules/tpm.doctree
index b56e3bec..90673239 100644
Binary files a/kd240/build/doctrees/docs/bist/docs/modules/tpm.doctree and b/kd240/build/doctrees/docs/bist/docs/modules/tpm.doctree differ
diff --git a/kd240/build/doctrees/docs/bist/docs/modules/tty.doctree b/kd240/build/doctrees/docs/bist/docs/modules/tty.doctree
index 6a5a1eb8..4bd3919e 100644
Binary files a/kd240/build/doctrees/docs/bist/docs/modules/tty.doctree and b/kd240/build/doctrees/docs/bist/docs/modules/tty.doctree differ
diff --git a/kd240/build/doctrees/docs/bist/docs/modules/video.doctree b/kd240/build/doctrees/docs/bist/docs/modules/video.doctree
index 72bb8f0f..46091b83 100644
Binary files a/kd240/build/doctrees/docs/bist/docs/modules/video.doctree and b/kd240/build/doctrees/docs/bist/docs/modules/video.doctree differ
diff --git a/kd240/build/doctrees/docs/bist/docs/overview.doctree b/kd240/build/doctrees/docs/bist/docs/overview.doctree
index 1ffa55cd..58592d8e 100644
Binary files a/kd240/build/doctrees/docs/bist/docs/overview.doctree and b/kd240/build/doctrees/docs/bist/docs/overview.doctree differ
diff --git a/kd240/build/doctrees/docs/bist/docs/run.doctree b/kd240/build/doctrees/docs/bist/docs/run.doctree
index 1310eccc..ae920515 100644
Binary files a/kd240/build/doctrees/docs/bist/docs/run.doctree and b/kd240/build/doctrees/docs/bist/docs/run.doctree differ
diff --git a/kd240/build/doctrees/docs/bist/docs/setup_kd240.doctree b/kd240/build/doctrees/docs/bist/docs/setup_kd240.doctree
index 09aa5d9b..ace4d1ba 100644
Binary files a/kd240/build/doctrees/docs/bist/docs/setup_kd240.doctree and b/kd240/build/doctrees/docs/bist/docs/setup_kd240.doctree differ
diff --git a/kd240/build/doctrees/docs/bist/docs/setup_kr260.doctree b/kd240/build/doctrees/docs/bist/docs/setup_kr260.doctree
index c25dede2..dfa5de6b 100644
Binary files a/kd240/build/doctrees/docs/bist/docs/setup_kr260.doctree and b/kd240/build/doctrees/docs/bist/docs/setup_kr260.doctree differ
diff --git a/kd240/build/doctrees/docs/bist/docs/setup_kv260.doctree b/kd240/build/doctrees/docs/bist/docs/setup_kv260.doctree
index ffe66fc6..e3f3c801 100644
Binary files a/kd240/build/doctrees/docs/bist/docs/setup_kv260.doctree and b/kd240/build/doctrees/docs/bist/docs/setup_kv260.doctree differ
diff --git a/kd240/build/doctrees/docs/build_vivado_design.doctree b/kd240/build/doctrees/docs/build_vivado_design.doctree
index f0210e9f..cfe85633 100644
Binary files a/kd240/build/doctrees/docs/build_vivado_design.doctree and b/kd240/build/doctrees/docs/build_vivado_design.doctree differ
diff --git a/kd240/build/doctrees/docs/building_the_design.doctree b/kd240/build/doctrees/docs/building_the_design.doctree
index d1646356..f920fe0e 100644
Binary files a/kd240/build/doctrees/docs/building_the_design.doctree and b/kd240/build/doctrees/docs/building_the_design.doctree differ
diff --git a/kd240/build/doctrees/docs/foc-motor-ctrl/docs/app_deployment.doctree b/kd240/build/doctrees/docs/foc-motor-ctrl/docs/app_deployment.doctree
new file mode 100644
index 00000000..ac28b30d
Binary files /dev/null and b/kd240/build/doctrees/docs/foc-motor-ctrl/docs/app_deployment.doctree differ
diff --git a/kd240/build/doctrees/docs/foc-motor-ctrl/docs/hw_description.doctree b/kd240/build/doctrees/docs/foc-motor-ctrl/docs/hw_description.doctree
new file mode 100644
index 00000000..b78d32d3
Binary files /dev/null and b/kd240/build/doctrees/docs/foc-motor-ctrl/docs/hw_description.doctree differ
diff --git a/kd240/build/doctrees/docs/foc-motor-ctrl/docs/introduction.doctree b/kd240/build/doctrees/docs/foc-motor-ctrl/docs/introduction.doctree
new file mode 100644
index 00000000..98e7289e
Binary files /dev/null and b/kd240/build/doctrees/docs/foc-motor-ctrl/docs/introduction.doctree differ
diff --git a/kd240/build/doctrees/docs/foc-motor-ctrl/docs/known_issues.doctree b/kd240/build/doctrees/docs/foc-motor-ctrl/docs/known_issues.doctree
new file mode 100644
index 00000000..3f7060c9
Binary files /dev/null and b/kd240/build/doctrees/docs/foc-motor-ctrl/docs/known_issues.doctree differ
diff --git a/kd240/build/doctrees/docs/foc-motor-ctrl/docs/sw_arch.doctree b/kd240/build/doctrees/docs/foc-motor-ctrl/docs/sw_arch.doctree
new file mode 100644
index 00000000..d49b0731
Binary files /dev/null and b/kd240/build/doctrees/docs/foc-motor-ctrl/docs/sw_arch.doctree differ
diff --git a/kd240/build/doctrees/docs/foc-motor-ctrl/foc_motor_control_landing.doctree b/kd240/build/doctrees/docs/foc-motor-ctrl/foc_motor_control_landing.doctree
index d0b40833..35817b47 100644
Binary files a/kd240/build/doctrees/docs/foc-motor-ctrl/foc_motor_control_landing.doctree and b/kd240/build/doctrees/docs/foc-motor-ctrl/foc_motor_control_landing.doctree differ
diff --git a/kd240/build/doctrees/docs/foc-motor-ctrl/src/app_deployment.doctree b/kd240/build/doctrees/docs/foc-motor-ctrl/src/app_deployment.doctree
index 321a3153..285b2150 100644
Binary files a/kd240/build/doctrees/docs/foc-motor-ctrl/src/app_deployment.doctree and b/kd240/build/doctrees/docs/foc-motor-ctrl/src/app_deployment.doctree differ
diff --git a/kd240/build/doctrees/docs/foc-motor-ctrl/src/canopen_obj_dic.doctree b/kd240/build/doctrees/docs/foc-motor-ctrl/src/canopen_obj_dic.doctree
index 387f13b5..d7d00c63 100644
Binary files a/kd240/build/doctrees/docs/foc-motor-ctrl/src/canopen_obj_dic.doctree and b/kd240/build/doctrees/docs/foc-motor-ctrl/src/canopen_obj_dic.doctree differ
diff --git a/kd240/build/doctrees/docs/foc-motor-ctrl/src/hw_description.doctree b/kd240/build/doctrees/docs/foc-motor-ctrl/src/hw_description.doctree
index efb69eb6..a61e330e 100644
Binary files a/kd240/build/doctrees/docs/foc-motor-ctrl/src/hw_description.doctree and b/kd240/build/doctrees/docs/foc-motor-ctrl/src/hw_description.doctree differ
diff --git a/kd240/build/doctrees/docs/foc-motor-ctrl/src/introduction.doctree b/kd240/build/doctrees/docs/foc-motor-ctrl/src/introduction.doctree
index eeaecf45..fe313981 100644
Binary files a/kd240/build/doctrees/docs/foc-motor-ctrl/src/introduction.doctree and b/kd240/build/doctrees/docs/foc-motor-ctrl/src/introduction.doctree differ
diff --git a/kd240/build/doctrees/docs/foc-motor-ctrl/src/known_issues.doctree b/kd240/build/doctrees/docs/foc-motor-ctrl/src/known_issues.doctree
index 63e2adc9..9a2ac70a 100644
Binary files a/kd240/build/doctrees/docs/foc-motor-ctrl/src/known_issues.doctree and b/kd240/build/doctrees/docs/foc-motor-ctrl/src/known_issues.doctree differ
diff --git a/kd240/build/doctrees/docs/foc-motor-ctrl/src/sw_arch.doctree b/kd240/build/doctrees/docs/foc-motor-ctrl/src/sw_arch.doctree
index 3ca3d59b..037a4744 100644
Binary files a/kd240/build/doctrees/docs/foc-motor-ctrl/src/sw_arch.doctree and b/kd240/build/doctrees/docs/foc-motor-ctrl/src/sw_arch.doctree differ
diff --git a/kd240/build/doctrees/docs/generating_custom_firmware.doctree b/kd240/build/doctrees/docs/generating_custom_firmware.doctree
index 36b28f3d..cb626693 100644
Binary files a/kd240/build/doctrees/docs/generating_custom_firmware.doctree and b/kd240/build/doctrees/docs/generating_custom_firmware.doctree differ
diff --git a/kd240/build/doctrees/docs/kria_starterkit_linux_boot.doctree b/kd240/build/doctrees/docs/kria_starterkit_linux_boot.doctree
index 39185063..23f6df4c 100644
Binary files a/kd240/build/doctrees/docs/kria_starterkit_linux_boot.doctree and b/kd240/build/doctrees/docs/kria_starterkit_linux_boot.doctree differ
diff --git a/kd240/build/doctrees/docs/library_dependency.doctree b/kd240/build/doctrees/docs/library_dependency.doctree
new file mode 100644
index 00000000..b9b47236
Binary files /dev/null and b/kd240/build/doctrees/docs/library_dependency.doctree differ
diff --git a/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/ros2_multinode_communication_via_tsn_landing.doctree b/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/ros2_multinode_communication_via_tsn_landing.doctree
index b319705a..a1b443df 100644
Binary files a/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/ros2_multinode_communication_via_tsn_landing.doctree and b/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/ros2_multinode_communication_via_tsn_landing.doctree differ
diff --git a/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/ros2_multinode_communication_via_tsn_landing2.doctree b/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/ros2_multinode_communication_via_tsn_landing2.doctree
new file mode 100644
index 00000000..76817034
Binary files /dev/null and b/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/ros2_multinode_communication_via_tsn_landing2.doctree differ
diff --git a/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/app_deployment.doctree b/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/app_deployment.doctree
index 38578f8a..baea8378 100644
Binary files a/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/app_deployment.doctree and b/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/app_deployment.doctree differ
diff --git a/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/hw_arch_platform.doctree b/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/hw_arch_platform.doctree
index c2bb2a78..60e24238 100644
Binary files a/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/hw_arch_platform.doctree and b/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/hw_arch_platform.doctree differ
diff --git a/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/introduction.doctree b/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/introduction.doctree
index 27dd2412..706fe030 100644
Binary files a/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/introduction.doctree and b/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/introduction.doctree differ
diff --git a/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/sw_arch_platform.doctree b/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/sw_arch_platform.doctree
index 29d5fa51..2bce41f0 100644
Binary files a/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/sw_arch_platform.doctree and b/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/sw_arch_platform.doctree differ
diff --git a/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/sw_build_instructions.doctree b/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/sw_build_instructions.doctree
index c0b0abd7..74453c68 100644
Binary files a/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/sw_build_instructions.doctree and b/kd240/build/doctrees/docs/ros2_multinode_communication_via_tsn/src/sw_build_instructions.doctree differ
diff --git a/kd240/build/doctrees/docs/yocto_port_example.doctree b/kd240/build/doctrees/docs/yocto_port_example.doctree
new file mode 100644
index 00000000..a2802002
Binary files /dev/null and b/kd240/build/doctrees/docs/yocto_port_example.doctree differ
diff --git a/kd240/build/doctrees/index.doctree b/kd240/build/doctrees/index.doctree
index af29c478..b2bab0d2 100644
Binary files a/kd240/build/doctrees/index.doctree and b/kd240/build/doctrees/index.doctree differ
diff --git a/kd240/build/html/.buildinfo b/kd240/build/html/.buildinfo
index b084eff8..a071a0dd 100644
--- a/kd240/build/html/.buildinfo
+++ b/kd240/build/html/.buildinfo
@@ -1,4 +1,4 @@
# Sphinx build info version 1
# This file hashes the configuration used when building these files. When it is not found, a full rebuild will be done.
-config: a61d5a4b0808988c06c270cf556ec6d2
+config: 5ead5f5b738485b68485d231e614c3a7
tags: 645f666f9bcd5a90fca523b33c5a78b7
diff --git a/kd240/build/html/_images/sw_ros2_control.png b/kd240/build/html/_images/sw_ros2_control.png
deleted file mode 100644
index 3e97d7f0..00000000
Binary files a/kd240/build/html/_images/sw_ros2_control.png and /dev/null differ
diff --git a/kd240/build/html/_sources/docs/foc-motor-ctrl/docs/app_deployment.md.txt b/kd240/build/html/_sources/docs/foc-motor-ctrl/docs/app_deployment.md.txt
new file mode 100644
index 00000000..80763ed9
--- /dev/null
+++ b/kd240/build/html/_sources/docs/foc-motor-ctrl/docs/app_deployment.md.txt
@@ -0,0 +1,223 @@
+
+
+
Kria™ KD240 Drives Starter Kit FOC Motor Control Application Tutorial
+
+
+
+
Setting up the Board and Application Deployment
+
+
+
+
+
+# Board Setup and Application Deployment
+
+## Introduction
+
+This document shows how to set up the board, and run the motor control application.
+
+This guide is targeted for Ubuntu® 22.04 and the AMD 2023.1 toolchain.
+
+## Prerequisite
+
+### Hardware Requirements
+
+* [KD240 Drives Starter Kit](https://www.xilinx.com/products/som/kria/kd240-drives-starter-kit.html)
+
+* [KD240 Motor Accessory Kit](https://www.xilinx.com/products/som/kria/kd240-motor-accessory-pack.html)
+
+* KD240 power supply and adapter (included with the KD240 Drives Starter Kit)
+ * 12V AC adapter for the KD240 Starter Kit and 24V AC adapter for the Motor Accessory Kit
+
+* USB-A to micro-B cable (included with the KD240 Drives Starter Kit)
+
+* MicroSD card (32 GB card is included with the KD240 Drives Starter Kit)
+
+* CAT6 Ethernet cable
+
+* Host machine with display
+
+### Hardware Setup
+
+
+
+* Connect the USB cable from the host machine to the J4 UART/JTAG interface on the board.
+
+ 
+
+* Connect the Ethernet cable from J24 to your local network with DHCP enabled to install the Linux packages.
+
+ 
+
+* Connect a 12V power supply to the J12 DC jack.
+
+ 
+
+* Connect a 24V power supply to the J29 DC link connector.
+
+ 
+
+* Connect the encoder header pins to the J42 QEI connector. Ensure J44 is in the "SE" selection.
+
+ 
+
+* Connect the motor input to a J32 3-phase inverter connector.
+
+ 
+
+### Tested Artifacts
+
+Testing was performed with the following artifacts:
+
+#### KD240 platform Artifacts
+
+| Component | Version |
+|--------------------------------|----------------------------|
+| Boot Firmware | K24-BootFW-01.01 |
+| Linux Kernel | 5.15.0-1027-xilinx-zynqmp |
+| xlnx-firmware-kd240-motor-ctrl | 0.10.1-0xlnx1 |
+
+To obtain the latest Linux image and boot firmware, refer to the [Kria Wiki](https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/1641152513/Kria+K26+SOM#Boot-Firmware-Updates).
+
+#### Application Packages
+
+| Package | Version |
+|--------------------------------|--------------|
+| xlnx-app-kd240-foc-motor-ctrl | 0.3.1-0xlnx5 |
+
+### Initial Setup
+
+1. Go through [Booting Kria Starter Kit Linux](https://xilinx.github.io/kria-apps-docs/kd240/linux_boot.html) to complete the minimum setup required to boot Linux before continuing with instructions on this page.
+
+2. Get the latest motor control application and firmware package:
+
+ * Download the firmware.
+ * Search package feed for packages compatible with the KD240.
+
+ ```bash
+ ubuntu@kria:~$ sudo apt search xlnx-firmware-kd240
+ Sorting... Done
+ Full Text Search... Done
+ xlnx-firmware-kd240-bist/jammy,now 0.10-0xlnx1 arm64 [installed]
+ FPGA firmware for Xilinx boards - kd240 bist application
+ xlnx-firmware-kd240-motor-ctrl-qei/jammy,now 0.10-0xlnx1 arm64 [installed]
+ FPGA firmware for Xilinx boards - kd240 motor-ctrl-qei application
+ ```
+
+ * Install the firmware binaries.
+
+ ```bash
+ sudo apt install xlnx-firmware-kd240-motor-ctrl-qei
+ ```
+
+ * Install the motor control application.
+
+ ```bash
+ sudo apt install xlnx-app-kd240-foc-motor-ctrl
+ ```
+
+## Run the Motor Control Application
+
+* Load the firmware:
+
+ * Show the list and status of available application firmware.
+
+ After installing the firmware, execute xmutil listapps to verify that it is captured under the listapps function and to have dfx-mgrd rescan and register all accelerators in the firmware directory tree.
+
+ ```bash
+ ubuntu@kria:~$ sudo xmutil listapps
+ Accelerator Accel_type Base Base_type #slots(PL+AIE) Active_slot
+
+ kd240-motor-ctrl-qei XRT_FLAT kd240-motor-ctrl-qei XRT_FLAT (0+0) -1
+ ```
+
+ * Load the desired application firmware.
+
+ When there is already another accelerator/firmware loaded, unload it first, then load the kd240-foc-motor-ctrl firmware.
+
+ ```bash
+ sudo xmutil unloadapp
+ sudo xmutil loadapp kd240-motor-ctrl-qei
+ ```
+
+* Run the bokeh server:
+
+ ```bash
+ # Run the application to launch bokeh server for the dashboard
+ export PATH=${PATH}:/opt/xilinx/xlnx-app-kd240-foc-motor-ctrl/bin
+ start_motor_dashboard
+ # Enter the sudo password if required and note the ip address of the board
+ ```
+
+ Sample screenshot of the terminal on launching the motor dashboard.
+
+ 
+
+## On the Host PC
+
+* Open <ip>:5006 in a web browser.
+
+ >**NOTE:** Once the server is running, it retains its settings no matter how many times the browser is closed, opened, or refreshed.
+
+* The system is set to OFF mode/state on starting the dashboard, observe the blue LED DS10 is off.
+* If the unit is plugged into a network with DHCP, an IP will be assigned automatically. If not on a network, then configure a static IP. For help on setting up static IP, see [Setting up a private network](https://github.com/Xilinx/vck190-base-trd/blob/2022.1/docs/source/run/run-dashboard.rst#setting-up-a-private-network).
+
+>**NOTE:** The open-loop mode of motor operation is a test mode intended for users with motor control knowledge and experience. Incorrect configurations of values of Vd and Vq can cause the motor to spin at speeds higher than its rating and potentially cause excessive motor heating. Use caution when using the open-loop mode.
+
+## Dashboard
+
+### Dashboard Features
+
+* The Mode drop-down is used to select the control system mode of operation.
+* The Sample Size text box is used to indicate how many samples are collected and plotted on the graphs for each type of data. The samples are collected at 100 microsecond intervals. The maximum number of samples is limited to 3000 due to dashboard performance limitations. For a large number of samples, there might be a small delay before a dashboard command takes effect.
+* The Refresh Interval text box is used to indicate how often the dashboard plots will refresh. A minimum refresh interval will be enforced based on the current sample size (a larger sample size requires a larger refresh interval).
+* The gain text boxes are used to adjust the proportional and integral gains of the corresponding control loop.
+* The Speed Setpoint text box is used to set the speed setpoint when running the motor in speed mode. The valid range of speed setpoints is -10000 to 10000 rpm.
+* The Torque Setpoint text box is used to set the torque setpoint when running the motor in torque mode. The valid range of torque setpoints is -2.5 to 2.5 amps.
+* The Open Loop - Vd text box is used to set the direct voltage (Vd). The valid range for Vd is -24 to 24 volts.
+ >**NOTE:** Normally this should be set to ~0V.
+* The Open Loop - Vq text box is used to set the quadrature voltage (Vq). The valid range for Vq is -24 to 24 volts.
+* The Fault Status indicators show if any faults have occured. When a critical fault occurs, the corresponding indicator will turn red. For a warning level faults, the corresponding indicator will turn yellow.
+* The Clear Faults button is used to clear all faults and put the system into Off mode.
+* The Electrical Data plot shows the currents and voltages for Phase A, B, and C. The voltage lines are hidden by default. The visibility of each current and voltage line can be toggled by clicking the legend labels. The current axis is shown on the left if any current lines are visible, and the voltage axis is shown on the right is any voltage lines are visible.
+* The Mechanical Data plot shows the speed and position of the motor. The visibility of each line can be toggled by clicking on the legend labels. The speed axis is shown on the left is speed is visible and the position axis is shown on the right if position is visible.
+* The Live Analysis plot shows the data that is selected for each axis using the buttons on the right.
+
+When the dashboard is first launched, the system will be in Off mode, and the dashboard will look similar to the following image. Observe that the electrical readings are near zero.
+
+
+
+To run the application in Speed mode, select **Speed** from the Mode drop-down, and use the Speed Setpoint text box to enter a speed setpoint. The following image shows the motor running in speed mode with a speed setpoint of 2000 rpm and the load disk that is included in the Motor Accessory Kit.
+
+
+
+To run the application in Torque mode, select **Torque** from the Mode drop-down and use the Torque Setpoint text box to enter a torque setpoint. The following image shows the motor running in torque mode with a torque setpoint of 1 amp and the load disk that is included in the Motor Accessory Kit.
+
+
+
+To run the application in Open Loop mode, select **Open Loop** from the Mode drop-down, and use the Vd/Vq text boxes to set Vd/Vq. The following image shows the motor running in open loop mode with Vd set to 0, Vq set to 4 volts, and the load disk that is included in the Motor Accessory Kit.
+
+
+
+The following images show what the dashboard looks like when a larger load is applied to the motor. As the load on the motor increases, the currents will increase and the I_alpha/I_beta circle will expand.
+
+
+
+
+
+## Next Steps
+
+* Go back to the [KD240 FOC Motor Control Application Start Page](../foc_motor_control_landing)
+
+
+
+
diff --git a/kd240/build/html/_sources/docs/foc-motor-ctrl/docs/hw_description.md.txt b/kd240/build/html/_sources/docs/foc-motor-ctrl/docs/hw_description.md.txt
new file mode 100644
index 00000000..62b86b9d
--- /dev/null
+++ b/kd240/build/html/_sources/docs/foc-motor-ctrl/docs/hw_description.md.txt
@@ -0,0 +1,305 @@
+
+
+
Kria™ KD240 Motor Control Starter Kit Motor Control Tutorial
+
+
+
+
Hardware Architecture of the Platform
+
+
+
+
+
+# Hardware Architecture of the Platform
+
+## Introduction
+
+ This section describes the design implemented in the programmable logic (PL). The following figure shows the top-level hardware architecture of the reference design.
+
+
+
+ At a high-level, the design is comprised of a motor control system, a data monitoring system, a data processing system, and a communication system.
+
+* Motor Control System: These are the blocks that control the motor speed and direction. All but the Gate Driver are High-Level Synthesis (HLS) blocks from the AMD Vitis™ Motor Control Library.
+
+ * Quadrature Encoder Interface (QEI)
+ * Field-Orientated Control (FOC)
+ * Space Vector Pulse Width Modulation (SVPWM)
+ * Pulse Width Modulation Generation (PWM Gen)
+ * Gate Driver
+
+* Data Monitoring System: These are the blocks that monitor data from the motor and DC power supply.
+
+ * ADC Sample Control
+ * Current and Voltage Analog to Digital Controller (ADC) Interface for Motor phases A, B, C, and DC Link
+ * Unicode Straight Binary (USB) to Binary Two's Complement (BTC) Conversion
+ * Bipolar Offset Binary (BOB) to BTC Conversion
+
+* Data Processing System: This is the block that controls the ADC interface and decides when to sample the ADCs. It also does basic filtering, scales the data, and formats it in Q-Scale format.
+
+ * ADC Hub
+
+* Time-Sensitive Networking (TSN) System: This system support transmission of Ethernet traffic based on traffic shaping protocols. The traffic can be control information to be passed between different nodes in a robotics system or between various Industrial Field devices. The requirement in these systems would be that the traffic is deterministic.
+
+ * TSN IP
+ * AXI Multi Channel DMA (MCDMA)
+ * Time Aware DMA (TADMA)
+ * Test PMOD controller
+
+## Motor Control System
+
+### QEI
+
+The QEI module from the Vitis Motor Control Library reads the encoder on the motor and provides the data to the FOC block.
+
+For more information, visit [Vitis Libraries Documentation](https://docs.xilinx.com/r/en-US/Vitis_Libraries/motor_control/index.html).
+
+### FOC
+
+The FOC module from the Vitis Motor Control Library implements a sensor-based field-orientated control. The eight control modes it supports cover basic speed and torque control modes, as well as field-weakening control.
+
+For more information, visit [Vitis Libraries Documentation](https://docs.xilinx.com/r/en-US/Vitis_Libraries/motor_control/index.html).
+
+### SVPWM
+
+The SVPWM module from the Vitis Motor Control Library implements the front-end for Space Vector Pulse Width Modulation to calculate phase ratios for the motor.
+
+For more information, visit [Vitis Libraries Documentation](https://docs.xilinx.com/r/en-US/Vitis_Libraries/motor_control/index.html).
+
+### PWM Gen
+
+The PWM Gen module from the Vitis Motor Control Library implements the back-end for Space Vector Pulse Width Modulation to generate output signals based on the ratios from SVPWM.
+
+For more information, visit [Vitis Libraries Documentation](https://docs.xilinx.com/r/en-US/Vitis_Libraries/motor_control/index.html).
+
+### Motor Control
+
+The motor control block collects all the fault information generated from ADC Hub and uses this information along with its own phase balance calculations on the Phase A, B, and C data to decide whether to allow the gate drivers to drive the motors.
+
+## Data Monitoring System
+
+### ADC Sample Control
+
+This custom IP converts the motor pwm_sync pulse from the HLS module hls_pwm_gen to an update signal that initiates the ADC capture cycle at regular intervals. The ADC Sample Control module acts much like a phase-locked loop (PLL), in that it tries to align the ADC captures to the pwm_sync pulse and keep the ADC samples to an integer number of samples during the pwm_sync cycle.
+
+### ADC7352 Interface
+
+The voltage and current for DC Link and Motor Phase A, B, and C, are captured by the ADC7352 Interface IP. The IP can be configured for up to 16 channels, each with its own bit resolution. Each channel can control one ADC7352, with its own Chip Select (CS). The KD240 Motor Control Kit uses eight channels at 12 bits resolution. DC Link ADC uses one chip select, and the Phase A/B/C Motor ADCs share another chip select for simultaneous data collection.
+
+### ADC Encoding Conversions
+
+The KD240 Motor Control Kit makes use of the AD7352 which is a unipolar ADC using USB encoding. The DC link and stator voltages are measured and encoded without any analog offsets while the current measurements require direction. For current measurements, an instrumentation amplifier with an analog offset output is used to be able to make use of the unipolar ADC to encode both positive and negative measured currents. The following table outlines the expected mapping.
+
+| KD240 Measurement | -FS Input | -FS Code | Midpoint | Midpt Code | +FS Input | +FS Code |
+| --------------------- |:---------:|:--------:|:---------:|:----------:|:---------:|:---------:|
+| DC Link Voltage | 0V | b0000 | +18.432V | b1000 | +36.864V | b1111 |
+| Motor Stator Voltages | 0V | b0000 | +18.432V | b1000 | +36.864V | b1111 |
+| DC Link Current | 0A | b0000 | +10.24A | b1000 | +20.48A | b1111 |
+| Motor Stator Current | -10.24A | b0000 | 0A | b1000 | +10.24A | b1111 |
+
+For DC Link voltage and current and for motor voltages, the conversion is done in USB to BTC IP.
+
+For motor currents, the conversion is done in BOB to BTC IP.
+
+## Data Processing System
+
+### ADC Hub
+
+This custom IP is the center of the processing for ADC data. It is parameterizable up to 16 channels, and each channel can be a different width. Each channel can also be treated as BTC or USB individually and can be customized to use DSP blocks or logic to implement the multipliers used for scaling the ADC data. There is also a choice for whether the channel is a Current or Voltage channel. This information is only to help the software understand what units to use for the data it reads from the ADC Hub. The KD240 Motor Control Kit uses eight channels, 12-bits, BTC encoding, and all channels are using the DSP for multipliers.
+
+Inside the ADC Hub are several functions, which are described in the next few sections.
+
+#### Simple Moving Average
+
+The data from the ADCs comes into the ADC Hub and goes into the Simple Moving Average (SMA) block. If there is an offset programmed by the software, first the offset is subtracted from the raw data coming in from the ADC. The offset can be positive or negative, which will result in either a smaller or larger value, respectively.
+
+After the offset is applied, then the data is entered into a FIFO, implemented in a block RAM. Software can program the number of taps to use for the SMA, from 1 to 128 in powers of two. The SMA function adds each new data to the sum of the previous data until the number of samples reaches the number of taps programmed by the software. At that time, the newest sample is added to the sum, and the oldest sample is read out of the block RAM and subtracted from the sum. The new sum is then shifted by the log2 of the tap count and becomes the output of the SMA module.
+
+There is no output from the SMA until the number of sammples has reached the number of taps. If the number of taps changes while the SMA is running, the whole datapath is reset, and the block RAM and adders are cleared. Once again, there will be no output until the new number of taps matches the number of samples received.
+
+#### Q-Scaler
+
+The ADC Hub scales the averaged data in the Q-Scaler module. Software programs the scaling factor, which is then multiplied with the averaged data. This multiplier can be implemented by a DSP or by logic in the configuration of the ADC Hub, on a per-channel basis. The scaled data is converted to Q-format, with 24 total bits. The integer portion is 7 bits, the fractional portion is 16 bits, and one sign bit. This scaled value is passed to the rest of the system as an AXI4-Stream interface, with no dependence on `tready` so that the data is always the most recent value.
+
+The scaling factors used in the KD240 Motor Control Kit are in the following table.
+
+| KD240 Measurement | ADC Scale Multiplier | ADC Scale (V/cnt) | Q-Format |
+| --------------------- |:--------------------:|:-----------------:|:-----------:|
+| DC Link Voltage | 1179.6480 | 0.018 | 0x00_049C |
+| Motor Stator Voltages | 1179.6480 | 0.018 | 0x00_049C |
+| DC Link Current | 655.3600 | 0.010 | 0x00_028F |
+| Motor Stator Current | 327.6800 | 0.005 | 0x00_0148 |
+
+#### Motor Fault Generation
+
+The averaged and scaled data is compared against limits set by the software to determine whether a fault has occurred. Software can program over-limits and under-limits per channel. If such limits are enabled, and the scaled data exceeds these limits, then a fault will be generated. There are over-faults and under-faults, and if enabled and triggered will result in an error being generated.
+
+Errors can only be cleared by writing a specific value to the associated clear register (one for over-fault and one for under-fault). These faults are used to generate interrupts for the ADC Hub, if interrupts are enabled. They are also used by the Motor Control module to generate the gate drive enable signal to the Gate Driver.
+
+#### Register Map
+
+The AXI Interface in the ADC Hub allows the software to control and monitor the hardware. The register map is as follows:
+
+Address Decode
+
+| 31:12 | 11:08 | 07:00 |
+| ------|:---------:|:---------------:|
+| n/a | Channel | Register Offset |
+
+Channel: Up to 16 Channels supported
+
+Register: Up to 64 channels supported
+
+| Offset | Register Name | Signed | R/W | Bits Used | Reset Value |
+| -------|:-------------------------------------:|:------:|:---:|:---------:|:-------------:|
+| 0x00 | Over Limit Value (Q8.16 Format) | Y | R/W | 23:0 | 0x0000_0000 |
+| 0x04 | Under Limit Value (Q8.16 Format) | Y | R/W | 23:0 | 0x0000_0000 |
+| 0x08 | Scaling Factor (Q8.16 Format) | Y | R/W | 23:0 | 0x0000_0320 |
+| 0x0C | Number of Taps for Averaging | N | R/W | 8:0 | 0x0000_0004 |
+| 0x10 | Raw ADC Value | Y | R | 15:0 | 0x0000_0000 |
+| 0x14 | Scaled ADC Value (Q8.16 Format) | Y | R | 1:0 | 0x0000_0000 |
+| 0x18 | Error Status | N | R | 15:0 | 0x0000_0000 |
+| 0x1C | Clear Over Limit Error (0x0BAD00FF) | N | R/W | 31:0 | 0x0000_0000 |
+| 0x20 | Clear Under Limit Error (0x0BAD00FF) | N | R/W | 31:0 | 0x0000_0000 |
+| 0x24 | Over Limit Error Enable | N | R/W | 0:0 | 0x0000_0000 |
+| 0x28 | Under Limit Error Enable | N | R/W | 0:0 | 0x0000_0000 |
+| 0x2C | Signed (1) or Unsigned (0) Data | N | R | 0:0 | HW Value |
+| 0x30 | Voltage (1) or Current (0) Channel | N | R | 0:0 | HW Value |
+| 0x34 | Total Number of Channels used in Hub | N | R | 3:0 | HW Value |
+| 0x38 | IRQ Disable | N | R/W | 0:0 | 0x0000_0000 |
+| 0x3C | ADC Offset | N | R/W | 31:0 | 0x0000_0000 |
+
+## TSN System
+
+ The following figure shows the blocks in the TSN System.
+
+
+
+### TSN IP
+
+The LogiCORE™ 100M/1G TSN Subsystem IP implements IEEE 802.1 Time Sensitive Networking (TSN) standards and provides a low latency bridged endpoint. The bridged endpoint solution consists of a 3-port switch, two ports connects to the network and one port connects to an internal endpoint. In this design, reduced gigabit media independent interface
+(RGMII) interfaces connect to a Marvel physical-side interface (PHY) supporting a maximum bandwidth of 1 Gbps. The TSN IP is configured to support:
+
+* Network Time Synchronization- 1588 Precision Time Protocol (PTP)
+* Scheduled and Best Effort traffic types
+* Time aware scheduling (IEEE 802.1 Qbv)
+* Frame replication and elimination (IEEE 802.1 CB)
+* Per Stream Filtering and Policing (IEEE 802.1 Qci)
+
+For more information on the IP, refer to the *100M/1G TSN Subsystem IP Product Guide* ([PG275](https://www.xilinx.com/content/dam/xilinx/member/1gtsn_doc/2020_1/pg275-tsn-endpoint-ethernet-mac.pdf)).
+
+>***NOTE:** You will need access to [1GTSN Documentation Lounge](https://www.xilinx.com/member/1gtsn_doc.html) to view the document.
+
+#### MCDMA
+
+The AXI MCDMA provides high-bandwidth direct memory access between memory (AXI Memory Mapped) and stream (AXI4-Stream) target peripherals. It supports both Memory Mapped to Stream (MM2S) and Stream to Memory Mapped (S2MM) transfers. The AXI MCDMA core provides a Scatter Gather (SG) interface with multiple channel support with independent configuration. In this design, the MCDMA is responsible to fetch Best Effort traffic for transmission by the TSN IP. It reads frames from the DDR memory and passes the data to the TSN IP on an AXI4-Stream interface. It is also responsible for writing the Schedule traffic and Best Effort traffic frames received from the TSN IP to the memory. The IP uses the S_AXI_HP0_FPD on the AMD Zynq™ UltraScale+™ MPSoC Processing System (PS) IP to read/write from/to DDR memory.
+
+For more information on the IP, refer to the *AXI MCDMA LogiCORE IP Product Guide* ([PG288](https://docs.xilinx.com/v/u/en-US/pg288-axi-mcdma)).
+
+#### TADMA
+
+TADMA is aware of QBV schedule cycles, stream time slots, and by using PTP
+generated time, it is capable of fetching frames for different streams/traffic classes from the system memory (DDR) at precisely required time, providing excellent time precision for TSN traffic. In this design, TADMA fetches scheduled traffic from memory, based on the Qbv programming and passed it to the TSN IP for transmission.
+
+For more information on the IP, refer to the *Time Aware DMA Product Guide* ([PG316](https://www.xilinx.com/content/dam/xilinx/member/1gtsn/2018_2/pg316-tadma.pdf)).
+
+>**NOTE:** You will need access to the [1GTSN Documentation Lounge](https://www.xilinx.com/member/1gtsn_doc.html) to view the above document.
+
+#### Test PMOD Controller
+
+The Test PMOD controller is a user IP that drives the [Digilent Test PMOD](https://digilent.com/shop/pmod-tph2-12-pin-test-point-header/) pins. The IP implements the following registers.
+
+| Register Offset | Register Name | Description |
+| :---- | :--- | :---- |
+|0x00 |slv_reg0| Bit0 is a MUX enable. If 1, then drive Qbv signals on PMOD. If 0, drive TSN publisher/subscriber 8-bit signatures|
+|0x04 |slv_reg1| 8-bit signature when publisher 1 transmits a TSN frame |
+|0x08 |slv_reg2| 8-bit signature when subscriber 1 receives a TSN frame |
+|0x0c |slv_reg3| 8-bit signature when publisher 2 transmits a TSN frame |
+|0x10 |slv_reg4| 8-bit signature when subscriber 2 receives a TSN frame |
+
+The TSN application can support multiple publishers and subscribers. When the publisher queues up a packet for transmission, it writes a unique 8-bit word to `slv_reg*`, which is then transmitted on the PMOD pins. Similarly when the subscriber receives a packet, it writes a unique 8-bit word to `slv_reg*` which is then transmitted on the PMOD pins. The PMOD pins of the publisher and subscriber are hooked up to a scope and are used to measure end to end application latency. The TSN pub sub application sets the MUX (`slv_reg0`) to 0 before writing the signature value. The following figure shows the mapping on the PMOD pins when MUX is set to 0 and 1.
+
+
+
+To view scheduled and best effort traffic, the MUX value is set to 1. If the Qbv schedule is set, for example, a time slot is programmed with 70% scheduled traffic and 30% best effort traffic, then viewing `tlast` signal of received scheduled traffic and `tlast` signal of received best effort traffic on a scope will confirm that Qbv is working as expected. `tlast` indicates the end of a packet. Transmit signals can also be monitored, but these signals are the on the outside of the TSN IP and the traffic is yet to be scheduled.
+
+The other signal which is monitored to see if the Transmitter and Receiver clocks are in sync is the PTP clock.
+
+For more information on how to use PMOD signals to check clock synchronization and to measure latency and confirm Qbv programming, refer to [application deployment page](./app_deployment.md).
+
+## Clocks, Resets, and Interrupts
+
+### Clocks
+
+The following table identifies the main clocks of the PL design, their source, their clock frequency, and their function.
+
+| Clock | Clock Source | Clock Frequency | Function |
+| :--- | :----: | :---: | :----- |
+| pl_clk0 | PS | 100 MHz | Clock source for clocking wizard (clk_wiz_0) |
+| clk_out_100M | clk_wiz_0 | 100 MHz | Clock for data on CIPS port M_AXI_HPM0_FPD and most of the system |
+| clk_out_48M | clk_wiz_0 | 48 MHz | Clock for SCLK to ADC and ADC7352 Interface Module |
+| CLK_IN_gem | External Pin | 25 MHz | Clock for TSN Subsystem clocking wizard (clk_wiz_0) generating clocks |
+| clk_out1 | TSN clk_wiz_0 | 200 MHz | TSN IP fifo clock, TADMA IP and MCDMA IP data transactions clock |
+| clk_out2 | TSN clk_wiz_0 | 125 MHz | TSN IP and TADMA IP Real Time clock (RTC) for internal timers for time sensitivity |
+| clk_out3 | TSN clk_wiz_0 | 300 MHz | reference clock for IDELAY control block for PHY operation on TSN IP |
+| clk_out4 | TSN clk_wiz_0 | 100 MHz | AXI4-Lite clock to configure TSN IP, MCDMA IP, and Register interface IP |
+
+### Resets
+
+The following table summarizes the resets used in this design.
+
+| Reset Source | Function |
+| :--- | :---- |
+| pl_resetn0 | PL reset for proc_sys_reset modules and TSN Subsystem |
+| proc_sys_reset_0 | Synchronous resets for clk_out_100M clock domain |
+| proc_sys_reset_1 | Synchronous resets for clk_out_48M clock domain |
+| TSN Phy_reset_n | Reset for External Phy (tied high) |
+| TSN rst_clk_wiz_0_100M | Synchronous Reset for clk_out100M clock domain |
+| TSN rst_clk_wiz_0_125M | Synchronous Reset for clk_out125M clock domain |
+| TSN rst_clk_wiz_0_200M | Synchronous Reset for clk_out200M clock domain |
+| TSN rst_clk_wiz_0_300M | Synchronous Reset for clk_out300M clock domain |
+
+### Interrupts
+
+The following table lists the PL-to-PS interrupts used in this design.
+
+| Interrupt ID | Instance |
+| :--- | :---- |
+|pl_ps_irq0[0]| ADC Hub IP |
+|pl_ps_irq0[1]| Motor Control IP |
+|pl_ps_irq0[2]| AXI Quad SPI 0 IP |
+|pl_ps_irq0[3]| HLS QEI IP |
+|pl_ps_irq0[4]| HLS FOC IP |
+|pl_ps_irq0[5]| HLS SVPWM Duty IP |
+|pl_ps_irq0[6]| HLS PWM Gen IP |
+|pl_ps_irq0[7]| TSN Subsystem |
+
+The TSN Subsystem interrupts are itemized in the following table.
+
+| Interrupt ID | Instance |
+| :--- | :---- |
+|intr[0-7]| TSN IP |
+|intr[8]| TADMA IP |
+|intr[9-14]| MCDMA IP |
+
+## Resource Utilization
+
+The resource utilization numbers on this platform post implementation is reported in the following table.
+
+| Resource | Utilization | Available | Utilization % |
+| :--- | :---- | :--- | :---- |
+| LUT | 57895 | 70560 | 82.05 |
+| LUTRAM | 4098 | 28800 | 14.23 |
+| FF | 84715 | 141120 | 60.03 |
+| BRAM | 116 | 216 | 53.70 |
+| DSP | 133 | 360 | 36.94 |
+| IO | 63 | 81 | 77.78 |
+| BUFG | 21 | 196 | 10.71 |
+| MMCM | 2 | 3 | 66.67 |
+| PLL | 0 | 6 | 0.00 |
+
+## Next Steps
+
+* [Software Archicture](./sw_arch.md)
+* Go back to the [KD240 FOC Motor Control Landing Page](../foc_motor_control_landing)
+
diff --git a/kd240/build/html/_sources/docs/foc-motor-ctrl/docs/introduction.md.txt b/kd240/build/html/_sources/docs/foc-motor-ctrl/docs/introduction.md.txt
new file mode 100644
index 00000000..5928e5f3
--- /dev/null
+++ b/kd240/build/html/_sources/docs/foc-motor-ctrl/docs/introduction.md.txt
@@ -0,0 +1,67 @@
+
+
+
Kria™ KD240 Drives Starter Kit FOC Motor Control Application Tutorial
+
+
+
+
+
Introduction
+
+
+
+
+
+# Introduction
+
+The KD240 Field Oriented Control (FOC) Motor Control Application is intended to capture general inverter and motor control examples using AMD-Xilinx standard IP/libraries. The IPs, libraries, and drivers serve as a design example demonstrating the K240 SOM capabilities in implementing applications that require precise control of the motor's speed and torque while minimizing energy losses and reducing system noise. The IPs, libraries, and drivers created are general in the sense they do not assume specific board level hardware for implementing the necessary cyber-physical boundaries around a given application.
+
+An overview of the motor field orientated control library functionality is summarized in the following three types of FOC based motor control that are to be implemented for supporting the KD240. Each focuses on either controlling the torque or speed of the motor.
+
+* Torque Control: Default FOC control is focused on maximizing the torque output of a motor by optimizing the quadrature (q) vector which represents the useful motor torque and minimizing the direct (d) vector component. In this mode of operation, the goal is to keep motor torque constant by adjusting motor speed.
+
+* Speed Control: Speed control is implemented through an additional PI control that adjusts the motor torque to the motor to maintain a constant speed.
+
+* Field Weakening Control: The field weakening control method trades off optimal torque to increase the speed of the motor. This is accomplished by adjusting the relationship of the q-vector and d-vector in FOC.
+
+## Design and Implementation
+
+The following provide more detailed definitions around the defined motor control modes of operation.
+
+### Torque Control
+
+Torque control implements a closed loop control focused on maintaining a specified torque value In this mode of operation, the q-vector provides the useful torque output of the motor, and the d-vector provides the force that is parallel to the rotor. The d-vector represents non-useful force, and thus any non-zero value is considered an error.
+
+
+
+### Speed Control
+
+Constant speed control is achieved through a PI controller that adjusts the motor torque to maintain a specified motor speed.
+
+
+
+## Sensored FOC Application
+
+The following block diagram shows the implementation of the Sensored FOC application.
+
+Motor Voltage and Current Feedbacks are provided by the ADC-HUB. The QEI Encoder provides the measured RPM from the BLDC motor as a feedback to the FOC control block. The generic PWM block is to provide a series of commands for each switch of a three leg inverter, with discrete on/off commands for each device. The Gate drive Pin control (GD Pin Control) and enable block is intended to implement the translation from the PWM functionality provided by the SVM PWM HLS IP to the KD240 specific gate drive circuit implementation. The gate drive enable signal is used to enable the power stage. This signal is shared across all three power bridge phases. The KD240 Motor Control block provides motor fault generation and system fault protection logic, which is used to check for gross failures in the system, such as shorted motor winding or failed phase leg.
+
+As seen by the block diagram in the kernel space, all the soft IPs are supported by kernel drivers using the industrial I/O framework. The drivers provide a number of features that make the hardware easier to configure and use these devices. It has support for buffers, common sysfs interface and integration with libiio framework in the user-space. A Motor Control application library is integrated with the device drivers to seamlessly operate different modes you set. You can control the various set points and gain parameters using the Dashboard GUI, as well as observe live plots of important metrics such as speed, feedback current/voltages, and torque. Instructions to test demo application are presented in the next section.
+
+
+
+## Next Steps
+
+* [Application Deployment](app_deployment.md)
+* Go back to the [KD240 FOC Motor Control Application Start Page](../foc_motor_control_landing)
+
+
+
+
diff --git a/kd240/build/html/_sources/docs/foc-motor-ctrl/docs/known_issues.md.txt b/kd240/build/html/_sources/docs/foc-motor-ctrl/docs/known_issues.md.txt
new file mode 100644
index 00000000..cadc1aff
--- /dev/null
+++ b/kd240/build/html/_sources/docs/foc-motor-ctrl/docs/known_issues.md.txt
@@ -0,0 +1,76 @@
+
+
+
Kria™ KD240 Drives Starter Kit FOC Motor Control Application Tutorial
+
+
+
+
Known Issues and Debug Help
+
+
+
+
+
+# Known Issues and Limitations
+
+* QEI reported speed is showing glitches. The QEI library computation of the speed has a known issue and will be addressed with a QEI library update.
+* Motor lower speed mode control capability is approximately 250 rpms.
+* Default motor tuning values are provided for the KD240 Motor Accessory Kit based the Anaheim motor with the plastic disk visual load. This load disk primarily acts as an inertial load and thus if you are connecting other loads to your motor, you should plan on conducting your own tuning process and defining custom tuning defaults based on your load testing.
+* Open-loop control mode is intended as a test mode and thus does not implement any software based ramp control. You will see fault protections triggered if immediately trying to set open-loop mode control with a Vq voltage > ~10V. If using an open-loop, you are responsible for incrementally stepping up the Vq command to your desired voltage setting. Typical use cases of open-loop mode have Vd set to 0V.
+* DC link current reading is limited to reading analog values > ~0.5A due to a limitation in the KD240 hardware. You should not assume the DC link current feedback is accurate until it is > ~0.5A.
+* If the bokeh server is stopped while the motor is running, the motor will not stop. The motor should be stopped through the GUI by switching to Off mode before stopping the bokeh server.
+
+# Debugging Motor Control Application
+
+If the motor control application is not functioning as intended, follow these debugging steps to diagnose and resolve issues.
+
+1. **Check Wire Connections**
+ * Ensure that wire connections matches the configuration shown in the application deployment page.
+ * Verify that the 24V DC supply is connected and the wall power is up.
+ * Check DS9 LED, which represents the DC link; it should be in a high state.
+ * Confirm that the Quadrature Encoder Interface (QEI) encoder from the motor is properly connected to the board.
+
+2. **Read DC Link Voltage**
+ * If the application repeatedly fails to start with system faults, measure the DC link voltage by reading data from the ADC interface (ADC-HUB voltage channel 6).
+ * Use the command `iio_attr -c xilinx_adc_hub voltage6` to check the voltage reading and should read around 24V.
+
+ ```bash
+ iio_attr -c xilinx_adc_hub voltage6
+ dev 'xilinx_adc_hub', channel 'voltage6' (input), attr 'input', value '25.116806030'
+ ```
+
+ A reading significantly lower or higher than the tolerance range of the power supply could indicate a hardware failure on the board.
+
+3. **Debug PL Interfaces**
+ * If unexpected behavior occurs, start probing different blocks of the programmable logic (PL) interfaces for debugging.
+ * Utilize the IIO utilities or the IIO driver sysfs for the specific hardware interface.
+ * For detailed information on debugging hardware interfaces, refer to the [Device and Channel Attributes](./sw_arch.md#device-and-channel-attributes) section.
+
+4. **Gate Drive Mode**
+ * Ensure that the software application is set to a valid mode that turns the Gate Drive ON, except for the off mode.
+ * Monitor DS10 LED: it should go high in modes other than off.
+
+5. **Observe Errors and Messages from the Application**
+ * Keep an eye on the serial console for error messages or other relevant information.
+ * Review the `dmesg` logs, which provide valuable information from the respective hardware drivers. These logs can be a helpful source of diagnostic information.
+
+6. **Network Connection**
+ * If the application does not respond to changes from the GUI, verify the network connection by pinging the host address.
+ * Sometimes, a web socket disconnection message may appear, indicating a communication issue. If you encounter such disconnection issues, try killing the Bokeh server and relaunching the server and the dashboard.
+
+ Sample Disconnection Message:
+
+ ```bash
+ 2023-09-13 18:47:32,361 WebSocket connection closed: code=None, reason=None
+ ``````
+
+
+
+
diff --git a/kd240/build/html/_sources/docs/foc-motor-ctrl/docs/sw_arch.md.txt b/kd240/build/html/_sources/docs/foc-motor-ctrl/docs/sw_arch.md.txt
new file mode 100644
index 00000000..56d7026b
--- /dev/null
+++ b/kd240/build/html/_sources/docs/foc-motor-ctrl/docs/sw_arch.md.txt
@@ -0,0 +1,358 @@
+
+
+
Kria™ KD240 Drive Starter Kit
+
+
+
+
Software Architecture
+
+
+
+
+
+# Software Architecture of the Platform
+
+## Introduction
+
+This section describes software components involved in the design and their relation with each other. The application requires a hardware platform as described in [Hardware Architecture of the Platform](./hw_description.md) for the stack explained in this section to work.
+
+The software stack here provides a comprehensive library that can be interfaced using various user interfaces and efficiently drive the motor through the Kria Drive SOM board.
+
+The following diagram illustrates the top-level architecture and arrangement of various software components:
+
+
+
+- Kernel: Ubuntu Linux kernel
+ - Drivers:
+ - `xilinx_adc_hub`: IIO driver for analog-to-digital converter (ADC) HUB
+ - `hls_qei_axi`: IIO driver for the QEI sensor
+ - `hsl_foc_periodic`: IIO driver for the sensor based field oriented controller
+ - `hls_pwm_gen`: IIO driver for PWM GEN
+ - `hsl_svpwm_duty`: IIO driver for SVPWM
+- Middleware
+ - IIO Framework and libiio library
+ - Generic UIO framework
+- Application and library
+ - Motor Control Library (includes UIO driver for the custom Motor Control IP)
+ - Bokeh dashboard
+
+## Kernel Drivers
+
+All the kernel drivers developed for the platform hardware are Industial I/O (IIO) based and adhere to the IIO kernel framework. The IIO subsystem covers many sensor and ADC devices in the industry. It provides the following features to fetch and control various parameters:
+
+- Divide the stream and type of data into logical channels.
+- Each channel can have specific attributes along with device attributes to fine-tune the behavior.
+- Efficient data collection using buffers to get deterministic data with timestamps and sync with other channels.
+- Interrupt handling to provide user side event handling.
+
+The following drivers are added to support this app:
+
+- ADC Hub (`xilinx_adc_hub`): Provides an interface to monitor current, voltage, and related faults that occur during the operation of the motor.
+- QEI Encoder (`hls_qei_axi`): External encoder to monitor the real-time speed and position of the motor.
+- FOC (`hsl_foc_periodic`): Field oriented controller driver to support various operational modes and state of the motor.
+- PWM_GEN (`hls_pwm_gen`): PWM_GEN provides PWM signal generation for motor control.
+- SVPWM_GEN (`hsl_svpwm_duty`): SVPWM provides space vector PWM to calcualte phase ratio for the motor.
+
+There is also custom Motor control IP, which is responsible for the design specific glue logic and driving the motor's Gate Driver. The driver for this IP is a UIO based and the device will instantiate the UIO device for this IP. The userspace driver for this is implemented inside the motor control library in the control block.
+
+### Device and Channel Attributes
+
+As explained in the [next section](#userspace-access-to-iio-drivers), the attributes exposed by each drivers can be accessed through sysfs interface or through libraries like libIIO.
+
+Most of the attribute names are self-explanatory. If a channel attribute is named `input`, it indicates that the device requires raw data for processing, and the final processed data can be read from the `input` channel attribute. If the `input` channel attribute is not present, the raw data itself represents the final value from the device.
+
+A couple of common device attributes accross IIO drivers in this application are:
+
+- `sample_interval_us`: This parameter represents the time period in microseconds. It determines the rate at which data is sampled and stored into the buffer. Only channel data is captured within the buffer.
+- `ap_ctrl`: This attribute conforms to the standard AMD HLS interface for IP, enabling the initiation of its operation.
+
+The device attributes applies to entire device for all the channels. The channel attributes are per channel configurations or data. Here are some of the attributes exposed by above drivers:
+
+#### Xilinx ADC Hub Channels
+
+List of available channels for the device `xilinx_adc_hub`.
+
+```bash
+ubuntu@kria:# iio_attr -c xilinx_adc_hub
+dev 'xilinx_adc_hub', channel 'voltage0' (input, index: 0, format: le:S32/32>>0), found 9 channel-specific attributes
+dev 'xilinx_adc_hub', channel 'current1' (input, index: 1, format: le:S32/32>>0), found 9 channel-specific attributes
+dev 'xilinx_adc_hub', channel 'voltage2' (input, index: 2, format: le:S32/32>>0), found 9 channel-specific attributes
+dev 'xilinx_adc_hub', channel 'current3' (input, index: 3, format: le:S32/32>>0), found 9 channel-specific attributes
+dev 'xilinx_adc_hub', channel 'voltage4' (input, index: 4, format: le:S32/32>>0), found 9 channel-specific attributes
+dev 'xilinx_adc_hub', channel 'current5' (input, index: 5, format: le:S32/32>>0), found 9 channel-specific attributes
+dev 'xilinx_adc_hub', channel 'voltage6' (input, index: 6, format: le:U32/32>>0), found 9 channel-specific attributes
+dev 'xilinx_adc_hub', channel 'current7' (input, index: 7, format: le:U32/32>>0), found 9 channel-specific attributes
+dev 'xilinx_adc_hub', channel 'timestamp' (input, index: 16, format: le:S64/64>>0), found 0 channel-specific attributes
+```
+
+Individual Channel Properties for Voltage0 in `xilinx_adc_hub`:
+
+```bash
+ubuntu@kria:# iio_attr -c xilinx_adc_hub voltage0
+dev 'xilinx_adc_hub', channel 'voltage0' (input), attr 'calibrate',
+dev 'xilinx_adc_hub', channel 'voltage0' (input), attr 'fault_clear',
+dev 'xilinx_adc_hub', channel 'voltage0' (input), attr 'input', value '0.865447998'
+dev 'xilinx_adc_hub', channel 'voltage0' (input), attr 'offset', value '0.000000000'
+dev 'xilinx_adc_hub', channel 'voltage0' (input), attr 'over_range_fault_status', value '0'
+dev 'xilinx_adc_hub', channel 'voltage0' (input), attr 'raw', value '47'
+dev 'xilinx_adc_hub', channel 'voltage0' (input), attr 'scale', value '0.018814086'
+dev 'xilinx_adc_hub', channel 'voltage0' (input), attr 'set_filter_tap', value '4'
+dev 'xilinx_adc_hub', channel 'voltage0' (input), attr 'under_range_fault_status', value '0'
+```
+
+- `calibrate`: One-time calibration at the very start to offset any residual value in the system.
+- `fault_clear`: Clears all faults on the channel.
+- `input`: Final voltage value read by the ADC in volts (raw * scale factor).
+- `offset`: Automatically populated after calibration.
+- `over_range_fault_status`: Status indicating if an over-range fault occurred (0 - for no fault).
+- `raw`: The ADC raw value.
+- `scale`: The scaling factor.
+- `set_filter_tap`: Number of filter taps.
+- `under_range_fault_status`: Status indicating if an under-range fault occurred (0 for no fault).
+
+The attributes for the currentX channel would be similar to `voltage0`, but the readings are in amperes (amps).
+
+#### HLS PWM Generator Channels
+
+List of available channels for the device `hls_pwm_gen`.
+
+```bash
+ubuntu@kria:# iio_attr -c hls_pwm_gen
+dev 'hls_pwm_gen', channel 'voltage0', id 'Va_duty_ratio' (input, index: 0, format: le:U32/32>>0), found 3 channel-specific attributes
+dev 'hls_pwm_gen', channel 'voltage1', id 'Vb_duty_ratio' (input, index: 1, format: le:U32/32>>0), found 3 channel-specific attributes
+dev 'hls_pwm_gen', channel 'voltage2', id 'Vc_duty_ratio' (input, index: 2, format: le:U32/32>>0), found 3 channel-specific attributes
+dev 'hls_pwm_gen', channel 'timestamp' (input, index: 3, format: le:S64/64>>0), found 0 channel-specific attributes
+```
+
+Individual Channel Properties for Va_duty_ratio in the HLS PWM Generator:
+
+```bash
+ubuntu@kria:# iio_attr -c hls_pwm_gen voltage0
+dev 'hls_pwm_gen', channel 'voltage0' (input), id 'Va_duty_ratio', attr 'label', value 'Va_duty_ratio'
+dev 'hls_pwm_gen', channel 'voltage0' (input), id 'Va_duty_ratio', attr 'raw', value '0.000000000'
+dev 'hls_pwm_gen', channel 'voltage0' (input), id 'Va_duty_ratio', attr 'scale', value '1'
+```
+
+- `label`: The label of the channel is 'Va_duty_ratio'.
+- `raw`: The raw value for this channel is '0.000000000', and in this case, it represents the final reading for the channel.
+- `scale`: The scaling factor for this channel is '1'.
+
+The attributes are similar to the other channels from the PWM-GEN driver.
+
+#### HLS SVPWM Duty Channels
+
+List of available channels for the device `hls_svpwm_duty`.
+
+```bash
+ubuntu@kria:# iio_attr -c hls_svpwm_duty
+dev 'hls_svpwm_duty', channel 'voltage0', id 'Va_cmd' (input, index: 0, format: le:U32/32>>0), found 3 channel-specific attributes
+dev 'hls_svpwm_duty', channel 'voltage1', id 'Vb_cmd' (input, index: 1, format: le:U32/32>>0), found 3 channel-specific attributes
+dev 'hls_svpwm_duty', channel 'voltage2', id 'Vc_cmd' (input, index: 2, format: le:U32/32>>0), found 3 channel-specific attributes
+dev 'hls_svpwm_duty', channel 'timestamp' (input, index: 3, format: le:S64/64>>0), found 0 channel-specific attributes
+```
+
+Individual Channel Properties for `Va_cmd` in HLS SVPWM Duty:
+
+```bash
+ubuntu@kria:# iio_attr -c hls_svpwm_duty voltage0
+dev 'hls_svpwm_duty', channel 'voltage0' (input), id 'Va_cmd', attr 'label', value 'Va_cmd'
+dev 'hls_svpwm_duty', channel 'voltage0' (input), id 'Va_cmd', attr 'raw', value '0.000000000'
+dev 'hls_svpwm_duty', channel 'voltage0' (input), id 'Va_cmd', attr 'scale', value '1'
+```
+
+- `label`: The label of the channel is `Va_cmd`.
+- `raw`: The raw value for this channel is `0.000000000`, and in this case, it represents the final reading for the channel.
+- `scale`: The scaling factor for this channel is `1`.
+
+The attributes are similar to the other channels from the SVPWM driver.
+
+#### QEI Channels
+
+List of available channels for the device `hls_qei_axi`.
+
+```bash
+ubuntu@kria:# iio_attr -c hls_qei_axi
+dev 'hls_qei_axi', channel 'rot0', id 'rpm' (input, index: 0, format: le:U32/32>>0), found 3 channel-specific attributes
+dev 'hls_qei_axi', channel 'rot1', id 'theta_degree' (input, index: 1, format: le:U32/32>>0), found 3 channel-specific attributes
+dev 'hls_qei_axi', channel 'timestamp' (input, index: 2, format: le:S64/64>>0), found 0 channel-specific attributes
+```
+
+Individual Channel Properties for RPM in QEI:
+
+```bash
+ubuntu@kria:# iio_attr -c hls_qei_axi rot0
+dev 'hls_qei_axi', channel 'rot0' (input), id 'rpm', attr 'label', value 'rpm'
+dev 'hls_qei_axi', channel 'rot0' (input), id 'rpm', attr 'raw', value '0'
+dev 'hls_qei_axi', channel 'rot0' (input), id 'rpm', attr 'scale', value '1'
+```
+
+- `label`: The label of the channel is 'rpm'.
+- `raw`: The raw value for this channel is '0', and in this case, it represents the final reading for the channel.
+- `scale`: The scaling factor for this channel is '1'.
+
+The attributes are similar to the other channels from the QEI driver.
+
+#### FOC Channels
+
+List of available channels for the device `hls_foc_periodic`.
+
+```bash
+ubuntu@kria:# iio_attr -c hls_foc_periodic
+dev 'hls_foc_periodic', channel 'current0', id 'Id' (input, index: 0, format: le:U32/32>>0), found 3 channel-specific attributes
+dev 'hls_foc_periodic', channel 'current1', id 'Iq' (input, index: 1, format: le:U32/32>>0), found 3 channel-specific attributes
+dev 'hls_foc_periodic', channel 'current2', id 'I_alpha' (input, index: 2, format: le:U32/32>>0), found 3 channel-specific attributes
+dev 'hls_foc_periodic', channel 'current3', id 'I_beta' (input, index: 3, format: le:U32/32>>0), found 3 channel-specific attributes
+dev 'hls_foc_periodic', channel 'current4', id 'I_homopolar' (input, index: 4, format: le:U32/32>>0), found 3 channel-specific attributes
+dev 'hls_foc_periodic', channel 'rot5', id 'speed_pi_out' (input, index: 5, format: le:U32/32>>0), found 3 channel-specific attributes
+dev 'hls_foc_periodic', channel 'rot6', id 'torque_pi_out' (input, index: 6, format: le:U32/32>>0), found 3 channel-specific attributes
+dev 'hls_foc_periodic', channel 'intensity7', id 'flux' (input, index: 7, format: le:U32/32>>0), found 3 channel-specific attributes
+dev 'hls_foc_periodic', channel 'rot8', id 'speed' (input, index: 8, format: le:U32/32>>0), found 3 channel-specific attributes
+dev 'hls_foc_periodic', channel 'angl9' (input, index: 9, format: le:U32/32>>0), found 2 channel-specific attributes
+dev 'hls_foc_periodic', channel 'timestamp' (input, index: 10, format: le:S64/64>>0), found 0 channel-specific attributes
+```
+
+Individual Channel Properties for current0 in FOC:
+
+```bash
+ubuntu@kria:~$ iio_attr -c hls_foc_periodic current0
+dev 'hls_foc_periodic', channel 'current0' (input), id 'Id', attr 'label', value 'Id'
+dev 'hls_foc_periodic', channel 'current0' (input), id 'Id', attr 'raw', value '0.000000000'
+dev 'hls_foc_periodic', channel 'current0' (input), id 'Id', attr 'scale', value '1'
+```
+
+- `label`: The label of the channel is 'Id'.
+- `raw`: The raw value for this channel is '0.000000000', and in this case, it represents the final reading for the channel.
+- `scale`: The scaling factor for this channel is '1'.
+
+The attributes are similar to the other channels from the FOC driver.
+
+For detailed information on other device attributes, consult the [hardware documentation](./hw_description.md).
+
+For more details of IIO subsystem, refer to [Analog Devices Wiki](https://wiki.analog.com/software/linux/docs/iio/iio).
+
+For more details on kernel drivers for IIO, refer to [Kernel Documentation](https://static.lwn.net/kerneldoc/driver-api/iio/core.html).
+
+## Middleware
+
+### Userspace Access to IIO Drivers
+
+The driver exposes the IIO devices through the sysfs interface. The drivers can be accessed from the path `/sys/bus/iio/devices/iio\:deviceX`, where `X` is the numeric enumeration of the IIO device.
+
+libIIO is the userspace library to easily access the kernel IIO subsystem. It also provides various methods and command line interfaces, packaged in libiio-utils, to access the IIO devices. There are other Python wrappers around this library, but the motor control library uses a native C/C++ library.
+
+For example, to list all the available IIO devices:
+
+```
+ubuntu@kria:~$ iio_attr -c
+IIO context has 7 devices:
+ iio:device0, ams: found 30 channels
+ iio:device1, ina260-u14: found 6 channels
+ iio:device2, hls_foc_periodic: found 11 channels
+ iio:device3, hls_qei_axi: found 3 channels
+ iio:device4, xilinx_adc_hub: found 9 channels
+ iio:device5, hls_svpwm_duty: found 4 channels
+ iio:device6, hls_pwm_gen: found 4 channels
+```
+
+For more details, refer to the [libIIO Documentation](https://analogdevicesinc.github.io/libiio/v0.23/index.html).
+
+### Userspace Access to UIO
+
+The custom motor control IP is accessed from the motor control library using the UIO interface. A device tree node with compatible string as `generic-uio` is added to connect this hardware to the UIO subsystem.
+
+The device is now accessible in the userspace through the `/dev/uioX` device. Information about the device is obtained by scanning `/sys/class/uio/uioX`, where `X` is the UIO device id automatically assigned by the kernel.
+
+For more information on the UIO interface, refer to the kernel [documentation](https://www.kernel.org/doc/html/v4.18/driver-api/uio-howto.html).
+
+## Application and Library
+
+The motor control library is a C++ library that provides APIs for the front end application to control and fetch motor parameters. It also has a pybind11 wrapper to support the library APIs through python front end. The front end GUI included with this application is based on a python bokeh server, which can be accessed in a web browser in the network.
+
+### Motor Control Library
+
+The library can be divided into four blocks:
+
+- Communication
+- State Management and Coordination
+- Event/Fault Management
+- Control
+
+
+
+#### Communication
+
+The external user interfacing exposes the supported APIs through the C++ shared library and Python module.
+
+The library allows the user application to fetch following values:
+
+- Speed
+- Position
+- Current (Phase A, Phase B, Phase C, DC Link)
+- Voltage (Phase A, Phase B, Phase C, DC Link)
+- Fault status
+ - Over current for A, B, C, DC
+ - Over and under voltage for DCLink
+ - RMS power fault
+ - Phase imbalance fault
+- Intermediate FOC calculations (example: iq, id, i_alpha, etc)
+
+The library allows the user application to set following motor controls:
+
+- Clear faults
+- Speed
+- Torque
+- Open loop parameters (vq and vd)
+- Gain P/I gains (for current, speed and flux controller)
+
+For details list of APIs, refer to the [motor-control.hpp](https://github.com/xilinx/foc-motor-ctrl/blob/main/lib/include/motor-control/motor-control.hpp) file.
+
+Python binding for the application is provided using the pybind11 library.
+
+#### State Management and Coordination
+
+This is the central part of the library, which receives and processes all the request from the communication block and is responsible for:
+
+- Executing the initialization sequence for the motor.
+- Maintaining the current state of the platform and handling the state transitions.
+- Splitting, merging, and coordinating the request with various handlers in the control block.
+
+#### Event/Fault Management
+
+The Event Manager is responsible for configuring and monitoring events/faults from various hardware blocks. This block is aware of event capabilities of various control blocks and configures the events accordingly.
+
+It caches the event status in realtime and returns that to user when requested. The event is monitored in a separate thread which waits on epoll events for the registered events. Optionally, it also provides callback function registration in case additional action is expected when a realtime event occurs.
+
+#### Control
+
+This block is responsible for hardware access. There are interface classes which implement common interfaces for all the IIO based control handlers and all the UIO based control handlers. It also provides abstraction for the sensor interface to support more than one sensor (only one used at a given time).
+
+The following various handlers are for controlling the respective hardware:
+
+- FOC: For controlling and fetching data from the FOC hardware through the libiio framework.
+- ADCHub: For controlling and fetching data from the ADCHub hardware through the libiio framework.
+- Sensor: Abstraction for controlling and fetching data from the sensor hardware through the libiio framework (QEI in this case).
+- PWM_Gen: For controlling the PWM_GEN hardware through the libiio framework.
+- SVPWM: For controlling the SVPWM hardware through the libiio framework.
+- MC_UIO: For controlling custom Motor Control IP hardware through the UIO framework.
+- SW_AvgPower: Software based average power calculator to generate fault and control gate driver through MC_UIO.
+
+#### Additional Threads
+
+The following additional threads are implemented in the library:
+
+- Speed Ramp: When a new *speed* set point is set, the speed is ramped up or down in the FOC control handler using the constant ramp rate defined in `default_config.h`.
+- Torque Ramp: When new *torque* set point is set, the speed is ramped up or down in the FOC control handler using the constant ramp rate defined in `default_config.h`.
+- Event Monitor: The event manager waits on any event using epoll_wait in its own thread.
+
+### Bokeh Server (GUI)
+
+A python based bokeh server is implemented to provide a GUI interface to the application. It imports the motor control python library. The plot updates are handled by an update function which is called at the interval specified in the Refresh Interval text box. For each update, the function requests the number of samples specified in the Sample Size text box and update the plots with new data.
+
+For more details on the GUI usage, refer the [Application Deployment](./app_deployment.md) page for the details on the components and its usage.
+
+## Next Steps
+
+- [Application Deployment](./app_deployment.md)
+- Go back to the [KD240 FOC Motor Control Landing Page](../foc_motor_control_landing)
+
+
diff --git a/kd240/build/html/_sources/docs/foc-motor-ctrl/foc_motor_control_landing.rst.txt b/kd240/build/html/_sources/docs/foc-motor-ctrl/foc_motor_control_landing.rst.txt
index 7088fe1c..11eb54e0 100644
--- a/kd240/build/html/_sources/docs/foc-motor-ctrl/foc_motor_control_landing.rst.txt
+++ b/kd240/build/html/_sources/docs/foc-motor-ctrl/foc_motor_control_landing.rst.txt
@@ -9,7 +9,7 @@ Overview
.. toctree::
:maxdepth: 1
- Introduction
+ Introduction
Features
================================
@@ -33,7 +33,7 @@ Quick Start
.. toctree::
:maxdepth: 1
- Setting Up the Board and Application deployment
+ Setting Up the Board and Application deployment
***************************
Tutorials
@@ -54,8 +54,8 @@ Architecture
.. toctree::
:maxdepth: 1
- Hardware Architecture
- Software Architecture
+ Hardware Architecture
+ Software Architecture
*******************************
Repository
@@ -73,7 +73,7 @@ Other
.. toctree::
:maxdepth: 1
- Known Issues
+ Known Issues
..
License
diff --git a/kd240/build/html/_sources/docs/foc-motor-ctrl/src/app_deployment.md.txt b/kd240/build/html/_sources/docs/foc-motor-ctrl/src/app_deployment.md.txt
index 0dd0ce67..3b4470fe 100644
--- a/kd240/build/html/_sources/docs/foc-motor-ctrl/src/app_deployment.md.txt
+++ b/kd240/build/html/_sources/docs/foc-motor-ctrl/src/app_deployment.md.txt
@@ -87,8 +87,8 @@ Testing was performed with the following artifacts:
| Component | Version |
|--------------------------------|----------------------------|
| Boot Firmware | K24-BootFW-01.01 |
-| Linux Kernel | 5.15.0-1030-xilinx-zynqmp |
-| xlnx-firmware-kd240-motor-ctrl | 0.12-0xlnx2 |
+| Linux Kernel | 5.15.0-1027-xilinx-zynqmp |
+| xlnx-firmware-kd240-motor-ctrl | 0.10.1-0xlnx1 |
To obtain the latest Linux image and boot firmware, refer to the [Kria Wiki](https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/1641152513/Kria+K26+SOM#Boot-Firmware-Updates).
@@ -96,7 +96,7 @@ To obtain the latest Linux image and boot firmware, refer to the [Kria Wiki](htt
| Package | Version |
|--------------------------------|--------------|
-| xlnx-app-kd240-foc-motor-ctrl | 0.4-0xlnx1 |
+| xlnx-app-kd240-foc-motor-ctrl | 0.3.1-0xlnx5 |
### Initial Setup
@@ -126,10 +126,6 @@ To obtain the latest Linux image and boot firmware, refer to the [Kria Wiki](htt
* Install the motor control application.
```bash
- # Add lely PPA for lely-core libraries
- sudo add-apt-repository ppa:lely/ppa
- sudo apt-get update
-
sudo apt install xlnx-app-kd240-foc-motor-ctrl
```
@@ -266,7 +262,7 @@ The following images show what the dashboard looks like when a larger load is ap
to enable to PMOD-CAN interface on KR260.
```bash
- sudo apt install xlnx-firmware-kr260-tsn-rs485pmod
+ sudo apt install kr260-tsn-rs485pmod
sudo xmutil unloadapp
sudo xmutil loadapp kr260-tsn-rs485pmod
```
@@ -274,17 +270,11 @@ The following images show what the dashboard looks like when a larger load is ap
* Set up the CAN interface on both the KR260 and KD240.
```bash
- sudo ip link set can0 up type can bitrate 100000
- sudo ip link set can0 txqueuelen 10000
+ sudo ip link set can0 up type can bitrate 1000000
+ sudo ip link set can0 txqueuelen 1000
sudo ip link set can0 up
```
-* Verify the CAN interface state
-
- ```bash
- ip -d -s link show can0
- ```
-
* Install can-utils on both the KR260 and KD240.
```bash
@@ -313,14 +303,6 @@ The following images show what the dashboard looks like when a larger load is ap
start_motor_server
```
-* To terminate the server
-
- If it is required to kill the server kill fmc_canopen application
-
- ```bash
- sudo killall fmc_canopen
- ```
-
### On the KR260 (master)
* Download the docker image on the KR260.
@@ -344,37 +326,41 @@ The following images show what the dashboard looks like when a larger load is ap
--net=host \
--privileged \
--volume=/home/ubuntu/.Xauthority:/root/.Xauthority:rw \
- --name=motor_control \
- --rm \
-v /tmp:/tmp \
-v /dev:/dev \
-v /sys:/sys \
-v /etc/vart.conf:/etc/vart.conf \
-v /lib/firmware/xilinx:/lib/firmware/xilinx \
-v /run:/run \
- -it xilinx/foc-motor-ctrl-ros2-canopen-host:latest bash
+ -it foc-motor-ctrl-ros2-canopen-host:latest bash
```
-* Inside the container, run canopen host tests using the launch file described in the following
- subsections. There are 2 tests:
+* Make sure you are inside the docker container and source the ROS setup files.
- * *Simple CiA402 system*: where host accesses motor directly using ros2_canopen 402 driver.
- * *ROS2 Control example*: where host accesses motor over ros2_control interface.
+ ```bash
+ source /opt/ros/humble/setup.bash
+ source /root/ros_ws/install/setup.bash
+ ```
- > **Note**: Do not run both the launch files together as they will interfere in the operations. Only one test can be running at a given time.
+* Start the launch file.
-#### Run a simple CiA402 system host
+ ```bash
+ ros2 launch foc_motor kd240.launch.py
+ ```
-* In the docker run terminal start the canopen 402 host ros container using the launch file
+* Open a new terminal, find the docker container id, and launch another
+ session connected to the same container.
```bash
- ros2 launch kria_motor_control kd240.system.launch.py
+ docker ps # Copy container_id from output of this command
+ docker exec -it bash
```
-* Open a new terminal, start another session of the the same container.
+* In the new docker session, source the ROS setup files.
```bash
- docker exec -it motor_control bash
+ source /opt/ros/humble/setup.bash
+ source /root/ros_ws/install/setup.bash
```
* Check the available services and their types.
@@ -384,7 +370,6 @@ The following images show what the dashboard looks like when a larger load is ap
```
The output should look similar to this:
-
```bash
ubuntu@KR260:~$ ros2 service list -t
/device_container_node/change_state [lifecycle_msgs/srv/ChangeState]
@@ -432,7 +417,6 @@ The following images show what the dashboard looks like when a larger load is ap
```
* To view an interface definition, use:
-
```bash
ros2 interface show
```
@@ -440,7 +424,6 @@ The following images show what the dashboard looks like when a larger load is ap
For example, to view the interface definition for the canopen_interfaces/srv/COTargetDouble
type which is used for the /kd240/target service, run the command below.
This will print the input (target) and output (success).
-
```bash
ubuntu@KR260:~$ ros2 interface show canopen_interfaces/srv/COTargetDouble
float64 target
@@ -454,121 +437,43 @@ The following images show what the dashboard looks like when a larger load is ap
[Cia402 Driver documentation](https://ros-industrial.github.io/ros2_canopen/manual/humble/user-guide/cia402-driver.html).
Reset:
-
```bash
ros2 service call /kd240/nmt_reset_node std_srvs/srv/Trigger
```
Init:
-
```bash
ros2 service call /kd240/init std_srvs/srv/Trigger
```
Change to velocity mode:
-
```bash
ros2 service call /kd240/velocity_mode std_srvs/srv/Trigger
```
Change target speed:
-
- ```bash
- ros2 service call /kd240/target canopen_interfaces/srv/COTargetDouble "target: 3000"
- ```
-
- > **Note**: For the Anaheim motor kit, the speed range is 250 to 10000 rpm in
- both directions. If the motor does not spin at 250 rpm, try a faster speed.
- The minimum speed can vary by motor.
-
-#### Run a ROS2 Control based example
-
-* In the docker run terminal start the canopen 402 control system host using the launch file
-
- ```bash
- ros2 launch kria_motor_control kd240.ros2_control.launch.py
- ```
-
-* Open a new terminal, start another session of the the same container.
-
```bash
- docker exec -it motor_control bash
+ ros2 service call /kd240/target canopen_interfaces/srv/COTargetDouble "target: 800"
```
-* List the available controllers using ros2 control cli utility
-
+ Halt:
```bash
- ros2 control list_controllers
+ ros2 service call /kd240/halt std_srvs/srv/Trigger
```
- The output should look similar to this:
-
- ```bash
- ubuntu@KR260:~$ ros2 control list_controllers
- forward_velocity_controller[velocity_controllers/JointGroupVelocityController] active
- joint_state_broadcaster[joint_state_broadcaster/JointStateBroadcaster] active
- ```
-
-* To view the available hardware interfaces, use:
-
- ```bash
- ros2 control list_hardware_interfaces
- ```
-
- The output should look similar to this:
- ```bash
- ubuntu@KR260:~$ ros2 control list_hardware_interfaces
- command interfaces
- wheel_joint/velocity [available] [claimed]
- state interfaces
- wheel_joint/position
- wheel_joint/velocity
- ```
-
-* List the Ros2 Topics
-
- ```bash
- ubuntu@KR260:~$ ros2 topic list
- /dynamic_joint_states
- /forward_velocity_controller/commands
- /forward_velocity_controller/transition_event
- /joint_state_broadcaster/transition_event
- /joint_states
- /kd240_wheel/joint_states
- /kd240_wheel/nmt_state
- /kd240_wheel/rpdo
- /kd240_wheel/tpdo
- /parameter_events
- /robot_description
- /rosout
- /tf
- /tf_static
- ```
-
-* Observe the live state of the system using dynamic_joint_states
-
- ```bash
- ros2 topic echo /dynamic_joint_states
- ```
-
- This continuously updates the current state of the system and shows the position and speed of the motor.
-
-
-* Open a new terminal, start another session of the the same container.
-
- ```bash
- docker exec -it motor_control bash
- ```
+## Run One Wire Temperature Sensor Demo
-* Update the speed of the motor using velocity controller in a new terminal
+### Tested Artifacts
- ```bash
- ros2 topic pub --once /forward_velocity_controller/commands std_msgs/msg/Float64MultiArray "data: [5000]"
- ```
+Testing was performed with the following artifacts:
-
+#### KD240 platform Artifacts
-## Run One Wire Temperature Sensor Demo
+| Component | Version |
+|--------------------------------|----------------------|
+| Boot Firmware | K24-BootFW-01.00.bin |
+| Linux Kernel | 5.15.0-1030 |
+| xlnx-firmware-kd240-motor-ctrl | 0.12-0xlnx1 |
* In this demo, the lm-sensors utility probes the One Wire Temperature sensor, reads and displays the captured temperature value on the serial terminal.
diff --git a/kd240/build/html/_sources/docs/foc-motor-ctrl/src/known_issues.md.txt b/kd240/build/html/_sources/docs/foc-motor-ctrl/src/known_issues.md.txt
index 660dfd7e..cadc1aff 100644
--- a/kd240/build/html/_sources/docs/foc-motor-ctrl/src/known_issues.md.txt
+++ b/kd240/build/html/_sources/docs/foc-motor-ctrl/src/known_issues.md.txt
@@ -58,23 +58,11 @@ If the motor control application is not functioning as intended, follow these de
* Sometimes, a web socket disconnection message may appear, indicating a communication issue. If you encounter such disconnection issues, try killing the Bokeh server and relaunching the server and the dashboard.
Sample Disconnection Message:
-
+
```bash
2023-09-13 18:47:32,361 WebSocket connection closed: code=None, reason=None
``````
-# CAN bus issue
-
-Sometime, if the CANopen setup is left running for long time, them TX queue of the CAN interface can fillup resulting in the interface hang, especially on KR260.
-There is no indication for this situation except KR260 and KD240 do not receive can message. To fix this just bring the can interface down and up again.
-
-```bash
-sudo ip link set can0 down
-sudo ip link set can0 up
-```
-
-If this is frequent enough then consider increasing the tx queue length on KR260 with `sudo ip link set can0 txqueuelen 10000`
-
@@ -27,9 +26,11 @@
-
-
-
+
+
+
+
+
@@ -47,6 +48,7 @@
The Built-In Self Test (BIST) application tests the interfaces on AMD Kria™ starter kits to verify functionality and/or performance. If a custom design is not working as expected, this application can be used to differentiate hardware issues from design issues.
The BIST application is based on the pytest framework and designed to be modular and configurable so that it can be used across different starter kits. The tests are grouped into modules based on the interface which allows testing individual interfaces if needed. Some tests are self-validating tests, while others require user input based on observation. Each individual test either verifies the functionality or performance of an interface.
RS485 over PS uart on KD240 does not function in Ubuntu 22.04 kd05 release as the driver is in the process of being upstreamed. Thus, TTY test is expected to fail in Ubuntu 22.04 kd05 image on KD240. (It expect to pass in the Ubuntu 22.04 kd03 version on KD240, and does not impact RS485 over AXI lite uart on KR260)
Currently, the AR1335 module does not auto-load after loading kv260-bist firmware
@@ -134,101 +136,101 @@
The module contains self-validating functional test. It uses python3-can package for
transmitting and receiving CAN messages through the CAN port (CAN_L, CAN_H and GND pins).
The verification is done by performing transactions between MCP25625 PMOD CAN controller
@@ -177,41 +179,41 @@
Tests¶
read_can_message() functions via can_bus.send() and can_bus.recv() instances provided by
python3-can module. After the comparison of sent and received messages, the can nodes are
shutdown using can_node_shutdown().
-
-
-
pytest-3 --board kd240 -m can // Run all tests in this module
+pytest-3 --board kd240 -k can_bus_send // Run CAN message transmitter functional test
+pytest-3 --board kd240 -k can_bus_receive // Run CAN message receiver functional test
The CAN functional test prints the CAN node enumeration of the form canX for transmitter
and receiver nodes along with the message transmitted and received. The test is passed based
on message match between the sent and received CAN messages.
Verify the hardware connection between CAN port on the starter kit and PMOD CAN device
(Connected externally to the starter kit) before performing the CAN transactions.
The module contains self validating performance test. It uses “dd” command-line
utility to check the performance of USB and SD disk interfaces and verifies
if the measured read/write speeds are greater than the specified threshold speeds.
@@ -223,32 +225,32 @@
pytest-3 --board kv260 -m disk // Run all tests in this module
+pytest-3 --board kv260 -k usb1_read_performance // Run read performance testfor USB1 port
+pytest-3 --board kv260 -k usb1_write_performance // Run write performance testfor USB1 port
+pytest-3 --board kv260 -k sd_read_performance // Run read performance testfor SD port
+pytest-3 --board kv260 -k sd_write_performance // Run write performance testfor SD port
For each interface, the test prints out the device path, speed standard of the device
connected, along with minimum expected read/write speed and measured speed. The log indicates
whether the performance test is pass or fail based on the measured and threshold speed
comparison.
There are two tests for each board. One of them is a self-validating functional
test and the other is a user-validating functional test. The tests use the
libdrm-tests(modetest command) to test this module.
pytest-3 --board kv260 -m display // Run all tests in this module
+pytest-3 --board kv260 -k display_modetest // Run display_modetest test
Each test prints out the log messages that include the readings or a question
and User Input(for User Validating test) and the final test result. The
display_connectivity also logs debug level messages with additional info,
which can be found in the automatically generated log file.
On KV260, EDID is read from the DP splitter on the SOM and not from Monitor.
In this case, the connectivity test is still a Pass if the DP/HDMI cable is
disconnected for subsequent display_connectivity test runs.
There are two tests for each board, one for the SOM and the other for the carrier
card. Both tests are self-validating functional tests. The tests use the
ipmi-fru utility to read FRU data from a given file and print it to the
@@ -168,27 +170,27 @@
pytest-3 --board kv260 -m eeprom // Run all tests in this module
+pytest-3 --board kv260 -k som_eeprom // Run som_eeprom test
+pytest-3 --board kv260 -k carrier_card_eeprom // Run carrier_card_eeprom test
These tests print out all the FRU Data and each test is pass if the
“FRU Board Product Name” contains the value in the test config.
There are two types of tests in this module: a self-validating functional test,
which uses the ping3 python package, and a self-validating performance test,
which uses the iperf3 utility.
pytest-3 --board kr260 -m eth // Run all tests in this module
+pytest-3 --board kr260 -k ethernet1_ping // Run ethernet1_ping test
+pytest-3 --board kr260 -k ping // Run all ping tests
+pytest-3 --board kr260 -k perf // Run all perf tests
For each interface, the ping test prints out the delay and the test is a
pass if the ping is successful. The perf test prints out the measured
bitrate and the test is a pass if it is above the threshold. The default
threshold is 80% of the max speed for the ethernet ports.
The GPIO module contains one self-validating functional test. This test uses the
python3-periphery package. The package sets pins as input/output, writes values
on input pins, and reads the same value back on output pins. The total width of
@@ -168,12 +170,12 @@
The module contains self-validating functional test. It uses “i2cdetect” command-line
utility to check for the i2c bus number based on the controller and mux channel
information. The test then performs i2c read operation on the devices expected to be present
@@ -167,41 +169,41 @@
pytest-3 --board kv260 -m i2c // Run all tests in this module
+pytest-3 --board kv260 -k ps_i2c_bus_main // Run i2c device detect testfor PS I2C main bus
+pytest-3 --board kv260 -k axi_i2c_bus_main // Run i2c device detect testfor AXI I2C main bus
+pytest-3 --board kv260 -k axi_i2c_bus_ch0 // Run i2c device detect testfor AXI I2C bus mux channel 0
For each bus passed as label, the test prints out message indicating all i2c devices are detected
on the bus in case of pass. Otherwise, it prints out the information about the missing devices name and
addresses along with detected devices.
The IIO module contains a single self-validating functional test. This test
uses the libiio python bindings to read a value from a specified IIO device and
verify that it is within the range specified in the config.
The module contains seven self-validating functional tests. It uses py_foc_motor_ctrl
library to create the motor control instance for calling member functions, such as getSpeed(),
setOperationMode(), and so on.
Some of the above tests include dependency tests that are run prior to the main test.
The test dependencies are summarized in the following table. The dependency tests must
pass before the main test is run to ensure the results from the main test are accurate.
@@ -259,45 +261,45 @@
pytest-3 --board kd240 -m motor // Run all tests in this module
+pytest-3 --board kd240 -k qei_gate_drive_test // Run QEI interface testin'Speed' mode
+pytest-3 --board kd240 -k volt_adc_fb_modeoff_test // Run motor voltage ADC feedback testin'Off' mode
+pytest-3 --board kd240 -k volt_adc_fb_modeopenloop_test // Run motor voltage ADC feedback testin'Open Loop' mode
+pytest-3 --board kd240 -k curr_adc_fb_modeoff_test // Run motor current ADC feedback testin'Off' mode
+pytest-3 --board kd240 -k curr_adc_fb_modeopenloop_test // Run motor current ADC feedback testin'Open Loop' mode
+pytest-3 --board kd240 -k dc_link_volt_adc_fb_test // Run DC link voltage ADC feedback testin'Off' mode
+pytest-3 --board kd240 -k dc_link_curr_adc_fb_test // Run DC link current ADC feedback testin'Off' mode
The test prints out the messages indicating the motor mode and readings of the motor object for each test.
The motor test is limited to verifying the functionalities specified in the configuration file on loading
the BIST firmware only.
The established threshold values or ranges are based on the outputs observed during experimentation.
The values might differ slightly from board to board.
The MTD test module verifies read and write functionality of the QSPI MTD User
partition along with the performance measure on the AMD Kria™ starter kits.
The module contains self-validating funcational and performance tests. For the
functional test, it uses mtd-utils package to write random data to MTD User partition
and reads it back to ensure that the data is same. For the performance test, it uses
@@ -183,14 +185,14 @@
Tests¶
is greater than 1MiB. Depending on the mode of the test, read or write performance of the
interfaces are verified using dd command-line utility by get_qspi_write_performance() or
get_qspi_read_performance() functions and the result is logged by log_disk_performance().
-
-
-
pytest-3 --board kv260 -m mtd // Run all tests in this module
+pytest-3 --board kv260 -k qspi_read_write // Run QSPI read and write functional test
+pytest-3 --board kv260 -k qspi_read_performance // Run QSPI read performance test
+pytest-3 --board kv260 -k qspi_write_performance // Run QSPI write performance test
The QSPI read and write functional test prints the MTD User partition and its size along
@@ -199,16 +201,16 @@
The PWM module contains a single functional test, which requires user input.
This test prompts you to reduce the fan speed. It then reduces the fan
speed by writing a small value to the pwm device to which the fan is connected.
@@ -162,36 +164,36 @@
Tests¶
it is, the fan is set back to the max speed by writing a value of 255 to the
pwm device. You are then asked to verify that the fan is spinning at full
speed and if you confirm, the test passes. If at any point in this flow, you indicate that the fan is not behaving as expected, the test fails.
-
-
-
The module contains self-validating functional tests. The Torque sensor detection is
done with the help of two separate tests by dynamic SPI device path lookup. The
run_torque_sensor_id_test() verifies the Torque sensor AD7797 ID and run_torque_sensor_temp_test()
@@ -174,13 +176,13 @@
Tests¶
The Torque sensor ID read command is sent with the help of spi_transfer_command() function and the response
is analyzed. Similarly, for run_torque_sensor_temp_test(), once the device is initialized, the SPI command
sequence for reading the inbuilt temperature raw value is sent to the SPI device and the response is analyzed.
-
-
-
pytest-3 --board kd240 -m spi // Run all tests in this module
+pytest-3 --board kd240 -k ad7797_torque_sensor_id_read // Run Torque sensor ID readtest
+pytest-3 --board kd240 -k ad7797_torque_sensor_temperature_read // Run Torque sensor temperature readtest
For run_torque_sensor_id_test() functional test, the test is passed if the ID read from the SPI device response
@@ -189,26 +191,26 @@
The tests in this module use tpm2-tools to verify the output of various
functions. All tests are self-validating functional tests. Each entry in the
config contains the name of the command that is used for the test, and each
@@ -173,41 +175,41 @@
pytest-3 --board kv260 -m tpm // Run all tests in this module
+pytest-3 --board kv260 -k tpm2_getcap // Run tpm2_getcap test
+pytest-3 --board kv260 -k tpm2_hash // Run tpm2_hash test
Each test prints out the log messages that include the command that is run by
the test function and the final test result. Some tests also log debug
level messages with additional information, which can be found in the automatically
generated log file.
This module tests the tty interface(s) on the AMD Kria™ starter kits.
Note that this test is expected to fail in on KD240 with Ubuntu classic-22.04-kd05 version as the RS485 driver is in the process of being upstreamed for certified Ubuntu image. This test will still pass with Ubuntu 22.04-kd03 image on KD240, and it will also pass for KR260’s RS485 over AXI lite interface.
The Tty module contains one self-validating test. This test uses the pymodbus
python package. The package establishes a client connection with the connected
RS485 temperature sensor’s tty terminal and reads the holding registers
@@ -165,12 +167,12 @@
Occasionally, erroneous values (for example 3276.8) are reported for
temperature/humidity sensor data and this is due to error in the sensor itself,
@@ -196,14 +198,14 @@
pytest-3 --board kv260 -m video // Run all tests in this module
+pytest-3 --board kv260 -k imx219_perf // Run imx219_perf test
+pytest-3 --board kv260 -k imx219_filesink // Run imx219_filesink test
+pytest-3 --board kv260 -k ar1335_ap1302_ximagesink // Run ar1335_ap1302_ximagesink test
+pytest-3 --board kv260 -k perf -m video // Run all performance tests in this module
+pytest-3 --board kv260 -k filesink -m video // Run all filesink tests in this module
+pytest-3 --board kv260 -k ximagesink -m video // Run all ximagesink tests in this module
For the perf tests, the logs should have a comparison between actual_fps and
@@ -227,9 +229,9 @@
Test pattern at the sensor(ar1335_tpg_ximagesink) does not produce expected
result with a single write to the register. When the pipeline is running, the second
@@ -251,14 +253,14 @@
The Built-In Self Test (BIST) application tests the interfaces on the AMD Kria™ starter kits to verify functionality and/or performance. If a custom design is not working as expected, this application can be used to differentiate hardware issues from design issues.
The BIST application is based on the pytest framework and designed to be modular and configurable so that it can be used across different starter kits. The tests are grouped into modules based on the interface which allows testing individual interfaces if needed. Some tests are self-validating, while others require user input based on observation. Each individual test either verifies the functionality or performance of an interface.
The Built-In Self Test (BIST) application is based on the pytest framework. Pytest allows parametrizing the test functions so that they can be reused across different boards and interfaces. The tests are enumerated based on the target board and you can choose to run all tests for the target board, selected test modules, or selected individual tests. The file structure is described in the next section.
The source code for the BIST application can be found in the kria-bist repository. The tests directory contains
a module directory for each interface, along with a top level conftest.py and
pytest.ini.
NOTE: Setting up an SSH connection is only required to test the ximagesink
tests of the video module on KV260 board. If this is skipped, those tests will
fail
The storage volume on the SD card can be limited with multiple docker
images inbstalled. If there are space issues, use the following command
to remove existing docker images.
-
dockerrmi--force<image>
+
docker rmi --force <image>
You can find the images installed with the following command:
-
dockerimages
+
docker images
Launch the docker container using the following command:
pytest-3 --board kv260 -m video
-=============================testsessionstarts==============================
-platformlinux--Python3.10.6,pytest-6.2.5,py-1.10.0,pluggy-0.13.0
-rootdir:/opt/xilinx/kria-bist/tests,configfile:pytest.ini
-plugins:anyio-3.6.1
-collected34items/26deselected/8selected
+=============================test session starts==============================
+platform linux -- Python 3.10.6, pytest-6.2.5, py-1.10.0, pluggy-0.13.0
+rootdir: /opt/xilinx/kria-bist/tests, configfile: pytest.ini
+plugins: anyio-3.6.1
+collected 34 items / 26 deselected / 8 selected
video/test_bist_video.py::test_video[ar1335_ap1302_ximagesink]
---------------------------------livelogcall---------------------------------
+-------------------------------- live log call ---------------------------------
------------------------------------------
-Startoftest
-Pleaseobservethepop-upwindow
-Doyouseecolorbartestpatterninthewindow[Y/N]?
+Start of test
+Please observe the pop-up window
+Do you see color bar test pattern in the window [Y/N]?
y
-Userreportsthatpatternwasobservedinthewindow
-Testpassed
-Endoftest
+User reports that pattern was observed in the window
+Test passed
+End of test
PASSED
video/test_bist_video.py::test_video[ar1335_ap1302_perf]
---------------------------------livelogcall---------------------------------
+-------------------------------- live log call ---------------------------------
------------------------------------------
-Startoftest
-Actualfps:30.0,Targetfps:30-Actualfpswithinacceptedrange
-Testpassed
-Endoftest
+Start of test
+Actual fps: 30.0, Target fps:30 - Actual fps within accepted range
+Test passed
+End of test
PASSED
video/test_bist_video.py::test_video[tpg_ap1302_ximagesink]
---------------------------------livelogcall---------------------------------
+-------------------------------- live log call ---------------------------------
------------------------------------------
-Startoftest
-Pleaseobservethepop-upwindow
-Doyouseecolorbartestpatterninthewindow[Y/N]?
+Start of test
+Please observe the pop-up window
+Do you see color bar test pattern in the window [Y/N]?
y
-Userreportsthatpatternwasobservedinthewindow
-Testpassed
-Endoftest
+User reports that pattern was observed in the window
+Test passed
+End of test
PASSED
video/test_bist_video.py::test_video[tpg_ap1302_perf]
---------------------------------livelogcall---------------------------------
+-------------------------------- live log call ---------------------------------
------------------------------------------
-Startoftest
-Actualfps:30.003,Targetfps:30-Actualfpswithinacceptedrange
-Testpassed
-Endoftest
+Start of test
+Actual fps: 30.003, Target fps:30 - Actual fps within accepted range
+Test passed
+End of test
PASSED
video/test_bist_video.py::test_video[imx219_filesink]
---------------------------------livelogcall---------------------------------
+-------------------------------- live log call ---------------------------------
------------------------------------------
-Startoftest
+Start of test
-(gst-launch-1.0:89):GStreamer-CRITICAL**:21:29:17.009:gst_structure_fixate_field_nearest_int:assertion'IS_MUTABLE (structure)'failed
+(gst-launch-1.0:89): GStreamer-CRITICAL **: 21:29:17.009: gst_structure_fixate_field_nearest_int: assertion 'IS_MUTABLE (structure)' failed
-(gst-launch-1.0:89):GStreamer-CRITICAL**:21:29:17.009:gst_structure_fixate_field_nearest_int:assertion'IS_MUTABLE (structure)'failed
+(gst-launch-1.0:89): GStreamer-CRITICAL **: 21:29:17.009: gst_structure_fixate_field_nearest_int: assertion 'IS_MUTABLE (structure)' failed
-(gst-launch-1.0:89):GStreamer-CRITICAL**:21:29:17.010:gst_structure_fixate_field_nearest_fraction:assertion'IS_MUTABLE (structure)'failed
-TestImageandGoldenImagematch
-Testpassed
-Endoftest
+(gst-launch-1.0:89): GStreamer-CRITICAL **: 21:29:17.010: gst_structure_fixate_field_nearest_fraction: assertion 'IS_MUTABLE (structure)' failed
+Test Image and Golden Image match
+Test passed
+End of test
PASSED
video/test_bist_video.py::test_video[imx219_perf]
---------------------------------livelogcall---------------------------------
+-------------------------------- live log call ---------------------------------
------------------------------------------
-Startoftest
-Actualfps:30.004,Targetfps:30-Actualfpswithinacceptedrange
-Testpassed
-Endoftest
+Start of test
+Actual fps: 30.004, Target fps:30 - Actual fps within accepted range
+Test passed
+End of test
PASSED
video/test_bist_video.py::test_video[ar1335_filesink]
---------------------------------livelogcall---------------------------------
+-------------------------------- live log call ---------------------------------
------------------------------------------
-Startoftest
-(gst-launch-1.0:89):GStreamer-CRITICAL**:21:29:17.009:gst_structure_fixate_field_nearest_int:assertion'IS_MUTABLE (structure)'failed
+Start of test
+(gst-launch-1.0:89): GStreamer-CRITICAL **: 21:29:17.009: gst_structure_fixate_field_nearest_int: assertion 'IS_MUTABLE (structure)' failed
-(gst-launch-1.0:89):GStreamer-CRITICAL**:21:29:17.009:gst_structure_fixate_field_nearest_int:assertion'IS_MUTABLE (structure)'failed
+(gst-launch-1.0:89): GStreamer-CRITICAL **: 21:29:17.009: gst_structure_fixate_field_nearest_int: assertion 'IS_MUTABLE (structure)' failed
-(gst-launch-1.0:89):GStreamer-CRITICAL**:21:29:17.010:gst_structure_fixate_field_nearest_fraction:assertion'IS_MUTABLE (structure)'failed
-TestImageandGoldenImagematch
-Testpassed
-Endoftest
+(gst-launch-1.0:89): GStreamer-CRITICAL **: 21:29:17.010: gst_structure_fixate_field_nearest_fraction: assertion 'IS_MUTABLE (structure)' failed
+Test Image and Golden Image match
+Test passed
+End of test
PASSED
video/test_bist_video.py::test_video[ar1335_perf]
---------------------------------livelogcall---------------------------------
+-------------------------------- live log call ---------------------------------
------------------------------------------
-Startoftest
-Actualfps:30.004,Targetfps:30-Actualfpswithinacceptedrange
-Testpassed
-Endoftest
-PASSED[100%]
+Start of test
+Actual fps: 30.004, Target fps:30 - Actual fps within accepted range
+Test passed
+End of test
+PASSED [100%]
-====================8passed,26deselectedin42.11s=======================
+====================8 passed, 26 deselected in42.11s =======================
AMD Vivado™ platform design: The Vivado design is augmented with platform parameters that describe the metadata and physical interfaces available to the AMD Vitis™ compiler for stitching in programmable logic (PL) kernels.
Show the list and status of available application firmware.
+
After installing the firmware, execute xmutil listapps to verify that it is captured under the listapps function and to have dfx-mgrd rescan and register all accelerators in the firmware directory tree.
# Run the application to launch bokeh server for the dashboard
+exportPATH=${PATH}:/opt/xilinx/xlnx-app-kd240-foc-motor-ctrl/bin
+start_motor_dashboard
+# Enter the sudo password if required and note the ip address of the board
+
+
+
Sample screenshot of the terminal on launching the motor dashboard.
NOTE: Once the server is running, it retains its settings no matter how many times the browser is closed, opened, or refreshed.
+
+
+
The system is set to OFF mode/state on starting the dashboard, observe the blue LED DS10 is off.
+
If the unit is plugged into a network with DHCP, an IP will be assigned automatically. If not on a network, then configure a static IP. For help on setting up static IP, see Setting up a private network.
+
+
+
NOTE: The open-loop mode of motor operation is a test mode intended for users with motor control knowledge and experience. Incorrect configurations of values of Vd and Vq can cause the motor to spin at speeds higher than its rating and potentially cause excessive motor heating. Use caution when using the open-loop mode.
The Mode drop-down is used to select the control system mode of operation.
+
The Sample Size text box is used to indicate how many samples are collected and plotted on the graphs for each type of data. The samples are collected at 100 microsecond intervals. The maximum number of samples is limited to 3000 due to dashboard performance limitations. For a large number of samples, there might be a small delay before a dashboard command takes effect.
+
The Refresh Interval text box is used to indicate how often the dashboard plots will refresh. A minimum refresh interval will be enforced based on the current sample size (a larger sample size requires a larger refresh interval).
+
The gain text boxes are used to adjust the proportional and integral gains of the corresponding control loop.
+
The Speed Setpoint text box is used to set the speed setpoint when running the motor in speed mode. The valid range of speed setpoints is -10000 to 10000 rpm.
+
The Torque Setpoint text box is used to set the torque setpoint when running the motor in torque mode. The valid range of torque setpoints is -2.5 to 2.5 amps.
+
The Open Loop - Vd text box is used to set the direct voltage (Vd). The valid range for Vd is -24 to 24 volts.
+
+
NOTE: Normally this should be set to ~0V.
+
+
+
The Open Loop - Vq text box is used to set the quadrature voltage (Vq). The valid range for Vq is -24 to 24 volts.
+
The Fault Status indicators show if any faults have occured. When a critical fault occurs, the corresponding indicator will turn red. For a warning level faults, the corresponding indicator will turn yellow.
+
The Clear Faults button is used to clear all faults and put the system into Off mode.
+
The Electrical Data plot shows the currents and voltages for Phase A, B, and C. The voltage lines are hidden by default. The visibility of each current and voltage line can be toggled by clicking the legend labels. The current axis is shown on the left if any current lines are visible, and the voltage axis is shown on the right is any voltage lines are visible.
+
The Mechanical Data plot shows the speed and position of the motor. The visibility of each line can be toggled by clicking on the legend labels. The speed axis is shown on the left is speed is visible and the position axis is shown on the right if position is visible.
+
The Live Analysis plot shows the data that is selected for each axis using the buttons on the right.
+
+
When the dashboard is first launched, the system will be in Off mode, and the dashboard will look similar to the following image. Observe that the electrical readings are near zero.
+
+
To run the application in Speed mode, select Speed from the Mode drop-down, and use the Speed Setpoint text box to enter a speed setpoint. The following image shows the motor running in speed mode with a speed setpoint of 2000 rpm and the load disk that is included in the Motor Accessory Kit.
+
+
To run the application in Torque mode, select Torque from the Mode drop-down and use the Torque Setpoint text box to enter a torque setpoint. The following image shows the motor running in torque mode with a torque setpoint of 1 amp and the load disk that is included in the Motor Accessory Kit.
+
+
To run the application in Open Loop mode, select Open Loop from the Mode drop-down, and use the Vd/Vq text boxes to set Vd/Vq. The following image shows the motor running in open loop mode with Vd set to 0, Vq set to 4 volts, and the load disk that is included in the Motor Accessory Kit.
+
+
The following images show what the dashboard looks like when a larger load is applied to the motor. As the load on the motor increases, the currents will increase and the I_alpha/I_beta circle will expand.
This section describes the design implemented in the programmable logic (PL). The following figure shows the top-level hardware architecture of the reference design.
+
+
At a high-level, the design is comprised of a motor control system, a data monitoring system, a data processing system, and a communication system.
+
+
Motor Control System: These are the blocks that control the motor speed and direction. All but the Gate Driver are High-Level Synthesis (HLS) blocks from the AMD Vitis™ Motor Control Library.
+
+
Quadrature Encoder Interface (QEI)
+
Field-Orientated Control (FOC)
+
Space Vector Pulse Width Modulation (SVPWM)
+
Pulse Width Modulation Generation (PWM Gen)
+
Gate Driver
+
+
+
Data Monitoring System: These are the blocks that monitor data from the motor and DC power supply.
+
+
ADC Sample Control
+
Current and Voltage Analog to Digital Controller (ADC) Interface for Motor phases A, B, C, and DC Link
+
Unicode Straight Binary (USB) to Binary Two’s Complement (BTC) Conversion
+
Bipolar Offset Binary (BOB) to BTC Conversion
+
+
+
Data Processing System: This is the block that controls the ADC interface and decides when to sample the ADCs. It also does basic filtering, scales the data, and formats it in Q-Scale format.
+
+
ADC Hub
+
+
+
Time-Sensitive Networking (TSN) System: This system support transmission of Ethernet traffic based on traffic shaping protocols. The traffic can be control information to be passed between different nodes in a robotics system or between various Industrial Field devices. The requirement in these systems would be that the traffic is deterministic.
The FOC module from the Vitis Motor Control Library implements a sensor-based field-orientated control. The eight control modes it supports cover basic speed and torque control modes, as well as field-weakening control.
The SVPWM module from the Vitis Motor Control Library implements the front-end for Space Vector Pulse Width Modulation to calculate phase ratios for the motor.
The PWM Gen module from the Vitis Motor Control Library implements the back-end for Space Vector Pulse Width Modulation to generate output signals based on the ratios from SVPWM.
The motor control block collects all the fault information generated from ADC Hub and uses this information along with its own phase balance calculations on the Phase A, B, and C data to decide whether to allow the gate drivers to drive the motors.
This custom IP converts the motor pwm_sync pulse from the HLS module hls_pwm_gen to an update signal that initiates the ADC capture cycle at regular intervals. The ADC Sample Control module acts much like a phase-locked loop (PLL), in that it tries to align the ADC captures to the pwm_sync pulse and keep the ADC samples to an integer number of samples during the pwm_sync cycle.
The voltage and current for DC Link and Motor Phase A, B, and C, are captured by the ADC7352 Interface IP. The IP can be configured for up to 16 channels, each with its own bit resolution. Each channel can control one ADC7352, with its own Chip Select (CS). The KD240 Motor Control Kit uses eight channels at 12 bits resolution. DC Link ADC uses one chip select, and the Phase A/B/C Motor ADCs share another chip select for simultaneous data collection.
The KD240 Motor Control Kit makes use of the AD7352 which is a unipolar ADC using USB encoding. The DC link and stator voltages are measured and encoded without any analog offsets while the current measurements require direction. For current measurements, an instrumentation amplifier with an analog offset output is used to be able to make use of the unipolar ADC to encode both positive and negative measured currents. The following table outlines the expected mapping.
+
+
+
+
KD240 Measurement
+
-FS Input
+
-FS Code
+
Midpoint
+
Midpt Code
+
+FS Input
+
+FS Code
+
+
+
+
+
DC Link Voltage
+
0V
+
b0000
+
+18.432V
+
b1000
+
+36.864V
+
b1111
+
+
+
Motor Stator Voltages
+
0V
+
b0000
+
+18.432V
+
b1000
+
+36.864V
+
b1111
+
+
+
DC Link Current
+
0A
+
b0000
+
+10.24A
+
b1000
+
+20.48A
+
b1111
+
+
+
Motor Stator Current
+
-10.24A
+
b0000
+
0A
+
b1000
+
+10.24A
+
b1111
+
+
+
For DC Link voltage and current and for motor voltages, the conversion is done in USB to BTC IP.
+
For motor currents, the conversion is done in BOB to BTC IP.
This custom IP is the center of the processing for ADC data. It is parameterizable up to 16 channels, and each channel can be a different width. Each channel can also be treated as BTC or USB individually and can be customized to use DSP blocks or logic to implement the multipliers used for scaling the ADC data. There is also a choice for whether the channel is a Current or Voltage channel. This information is only to help the software understand what units to use for the data it reads from the ADC Hub. The KD240 Motor Control Kit uses eight channels, 12-bits, BTC encoding, and all channels are using the DSP for multipliers.
+
Inside the ADC Hub are several functions, which are described in the next few sections.
The data from the ADCs comes into the ADC Hub and goes into the Simple Moving Average (SMA) block. If there is an offset programmed by the software, first the offset is subtracted from the raw data coming in from the ADC. The offset can be positive or negative, which will result in either a smaller or larger value, respectively.
+
After the offset is applied, then the data is entered into a FIFO, implemented in a block RAM. Software can program the number of taps to use for the SMA, from 1 to 128 in powers of two. The SMA function adds each new data to the sum of the previous data until the number of samples reaches the number of taps programmed by the software. At that time, the newest sample is added to the sum, and the oldest sample is read out of the block RAM and subtracted from the sum. The new sum is then shifted by the log2 of the tap count and becomes the output of the SMA module.
+
There is no output from the SMA until the number of sammples has reached the number of taps. If the number of taps changes while the SMA is running, the whole datapath is reset, and the block RAM and adders are cleared. Once again, there will be no output until the new number of taps matches the number of samples received.
The ADC Hub scales the averaged data in the Q-Scaler module. Software programs the scaling factor, which is then multiplied with the averaged data. This multiplier can be implemented by a DSP or by logic in the configuration of the ADC Hub, on a per-channel basis. The scaled data is converted to Q-format, with 24 total bits. The integer portion is 7 bits, the fractional portion is 16 bits, and one sign bit. This scaled value is passed to the rest of the system as an AXI4-Stream interface, with no dependence on tready so that the data is always the most recent value.
+
The scaling factors used in the KD240 Motor Control Kit are in the following table.
The averaged and scaled data is compared against limits set by the software to determine whether a fault has occurred. Software can program over-limits and under-limits per channel. If such limits are enabled, and the scaled data exceeds these limits, then a fault will be generated. There are over-faults and under-faults, and if enabled and triggered will result in an error being generated.
+
Errors can only be cleared by writing a specific value to the associated clear register (one for over-fault and one for under-fault). These faults are used to generate interrupts for the ADC Hub, if interrupts are enabled. They are also used by the Motor Control module to generate the gate drive enable signal to the Gate Driver.
The LogiCORE™ 100M/1G TSN Subsystem IP implements IEEE 802.1 Time Sensitive Networking (TSN) standards and provides a low latency bridged endpoint. The bridged endpoint solution consists of a 3-port switch, two ports connects to the network and one port connects to an internal endpoint. In this design, reduced gigabit media independent interface
+(RGMII) interfaces connect to a Marvel physical-side interface (PHY) supporting a maximum bandwidth of 1 Gbps. The TSN IP is configured to support:
+
+
Network Time Synchronization- 1588 Precision Time Protocol (PTP)
+
Scheduled and Best Effort traffic types
+
Time aware scheduling (IEEE 802.1 Qbv)
+
Frame replication and elimination (IEEE 802.1 CB)
+
Per Stream Filtering and Policing (IEEE 802.1 Qci)
+
+
For more information on the IP, refer to the 100M/1G TSN Subsystem IP Product Guide (PG275).
The AXI MCDMA provides high-bandwidth direct memory access between memory (AXI Memory Mapped) and stream (AXI4-Stream) target peripherals. It supports both Memory Mapped to Stream (MM2S) and Stream to Memory Mapped (S2MM) transfers. The AXI MCDMA core provides a Scatter Gather (SG) interface with multiple channel support with independent configuration. In this design, the MCDMA is responsible to fetch Best Effort traffic for transmission by the TSN IP. It reads frames from the DDR memory and passes the data to the TSN IP on an AXI4-Stream interface. It is also responsible for writing the Schedule traffic and Best Effort traffic frames received from the TSN IP to the memory. The IP uses the S_AXI_HP0_FPD on the AMD Zynq™ UltraScale+™ MPSoC Processing System (PS) IP to read/write from/to DDR memory.
+
For more information on the IP, refer to the AXI MCDMA LogiCORE IP Product Guide (PG288).
TADMA is aware of QBV schedule cycles, stream time slots, and by using PTP
+generated time, it is capable of fetching frames for different streams/traffic classes from the system memory (DDR) at precisely required time, providing excellent time precision for TSN traffic. In this design, TADMA fetches scheduled traffic from memory, based on the Qbv programming and passed it to the TSN IP for transmission.
+
For more information on the IP, refer to the Time Aware DMA Product Guide (PG316).
The Test PMOD controller is a user IP that drives the Digilent Test PMOD pins. The IP implements the following registers.
+
+
+
+
Register Offset
+
Register Name
+
Description
+
+
+
+
+
0x00
+
slv_reg0
+
Bit0 is a MUX enable. If 1, then drive Qbv signals on PMOD. If 0, drive TSN publisher/subscriber 8-bit signatures
+
+
+
0x04
+
slv_reg1
+
8-bit signature when publisher 1 transmits a TSN frame
+
+
+
0x08
+
slv_reg2
+
8-bit signature when subscriber 1 receives a TSN frame
+
+
+
0x0c
+
slv_reg3
+
8-bit signature when publisher 2 transmits a TSN frame
+
+
+
0x10
+
slv_reg4
+
8-bit signature when subscriber 2 receives a TSN frame
+
+
+
The TSN application can support multiple publishers and subscribers. When the publisher queues up a packet for transmission, it writes a unique 8-bit word to slv_reg*, which is then transmitted on the PMOD pins. Similarly when the subscriber receives a packet, it writes a unique 8-bit word to slv_reg* which is then transmitted on the PMOD pins. The PMOD pins of the publisher and subscriber are hooked up to a scope and are used to measure end to end application latency. The TSN pub sub application sets the MUX (slv_reg0) to 0 before writing the signature value. The following figure shows the mapping on the PMOD pins when MUX is set to 0 and 1.
+
+
To view scheduled and best effort traffic, the MUX value is set to 1. If the Qbv schedule is set, for example, a time slot is programmed with 70% scheduled traffic and 30% best effort traffic, then viewing tlast signal of received scheduled traffic and tlast signal of received best effort traffic on a scope will confirm that Qbv is working as expected. tlast indicates the end of a packet. Transmit signals can also be monitored, but these signals are the on the outside of the TSN IP and the traffic is yet to be scheduled.
+
The other signal which is monitored to see if the Transmitter and Receiver clocks are in sync is the PTP clock.
+
For more information on how to use PMOD signals to check clock synchronization and to measure latency and confirm Qbv programming, refer to application deployment page.
The KD240 Field Oriented Control (FOC) Motor Control Application is intended to capture general inverter and motor control examples using AMD-Xilinx standard IP/libraries. The IPs, libraries, and drivers serve as a design example demonstrating the K240 SOM capabilities in implementing applications that require precise control of the motor’s speed and torque while minimizing energy losses and reducing system noise. The IPs, libraries, and drivers created are general in the sense they do not assume specific board level hardware for implementing the necessary cyber-physical boundaries around a given application.
+
An overview of the motor field orientated control library functionality is summarized in the following three types of FOC based motor control that are to be implemented for supporting the KD240. Each focuses on either controlling the torque or speed of the motor.
+
+
Torque Control: Default FOC control is focused on maximizing the torque output of a motor by optimizing the quadrature (q) vector which represents the useful motor torque and minimizing the direct (d) vector component. In this mode of operation, the goal is to keep motor torque constant by adjusting motor speed.
+
Speed Control: Speed control is implemented through an additional PI control that adjusts the motor torque to the motor to maintain a constant speed.
+
Field Weakening Control: The field weakening control method trades off optimal torque to increase the speed of the motor. This is accomplished by adjusting the relationship of the q-vector and d-vector in FOC.
Torque control implements a closed loop control focused on maintaining a specified torque value In this mode of operation, the q-vector provides the useful torque output of the motor, and the d-vector provides the force that is parallel to the rotor. The d-vector represents non-useful force, and thus any non-zero value is considered an error.
The following block diagram shows the implementation of the Sensored FOC application.
+
Motor Voltage and Current Feedbacks are provided by the ADC-HUB. The QEI Encoder provides the measured RPM from the BLDC motor as a feedback to the FOC control block. The generic PWM block is to provide a series of commands for each switch of a three leg inverter, with discrete on/off commands for each device. The Gate drive Pin control (GD Pin Control) and enable block is intended to implement the translation from the PWM functionality provided by the SVM PWM HLS IP to the KD240 specific gate drive circuit implementation. The gate drive enable signal is used to enable the power stage. This signal is shared across all three power bridge phases. The KD240 Motor Control block provides motor fault generation and system fault protection logic, which is used to check for gross failures in the system, such as shorted motor winding or failed phase leg.
+
As seen by the block diagram in the kernel space, all the soft IPs are supported by kernel drivers using the industrial I/O framework. The drivers provide a number of features that make the hardware easier to configure and use these devices. It has support for buffers, common sysfs interface and integration with libiio framework in the user-space. A Motor Control application library is integrated with the device drivers to seamlessly operate different modes you set. You can control the various set points and gain parameters using the Dashboard GUI, as well as observe live plots of important metrics such as speed, feedback current/voltages, and torque. Instructions to test demo application are presented in the next section.
QEI reported speed is showing glitches. The QEI library computation of the speed has a known issue and will be addressed with a QEI library update.
+
Motor lower speed mode control capability is approximately 250 rpms.
+
Default motor tuning values are provided for the KD240 Motor Accessory Kit based the Anaheim motor with the plastic disk visual load. This load disk primarily acts as an inertial load and thus if you are connecting other loads to your motor, you should plan on conducting your own tuning process and defining custom tuning defaults based on your load testing.
+
Open-loop control mode is intended as a test mode and thus does not implement any software based ramp control. You will see fault protections triggered if immediately trying to set open-loop mode control with a Vq voltage > ~10V. If using an open-loop, you are responsible for incrementally stepping up the Vq command to your desired voltage setting. Typical use cases of open-loop mode have Vd set to 0V.
+
DC link current reading is limited to reading analog values > ~0.5A due to a limitation in the KD240 hardware. You should not assume the DC link current feedback is accurate until it is > ~0.5A.
+
If the bokeh server is stopped while the motor is running, the motor will not stop. The motor should be stopped through the GUI by switching to Off mode before stopping the bokeh server.
If the motor control application is not functioning as intended, follow these debugging steps to diagnose and resolve issues.
+
+
Check Wire Connections
+
+
Ensure that wire connections matches the configuration shown in the application deployment page.
+
Verify that the 24V DC supply is connected and the wall power is up.
+
Check DS9 LED, which represents the DC link; it should be in a high state.
+
Confirm that the Quadrature Encoder Interface (QEI) encoder from the motor is properly connected to the board.
+
+
+
Read DC Link Voltage
+
+
If the application repeatedly fails to start with system faults, measure the DC link voltage by reading data from the ADC interface (ADC-HUB voltage channel 6).
+
Use the command iio_attr-cxilinx_adc_hubvoltage6 to check the voltage reading and should read around 24V.
Ensure that the software application is set to a valid mode that turns the Gate Drive ON, except for the off mode.
+
Monitor DS10 LED: it should go high in modes other than off.
+
+
+
Observe Errors and Messages from the Application
+
+
Keep an eye on the serial console for error messages or other relevant information.
+
Review the dmesg logs, which provide valuable information from the respective hardware drivers. These logs can be a helpful source of diagnostic information.
+
+
+
Network Connection
+
+
If the application does not respond to changes from the GUI, verify the network connection by pinging the host address.
+
Sometimes, a web socket disconnection message may appear, indicating a communication issue. If you encounter such disconnection issues, try killing the Bokeh server and relaunching the server and the dashboard.
This section describes software components involved in the design and their relation with each other. The application requires a hardware platform as described in Hardware Architecture of the Platform for the stack explained in this section to work.
+
The software stack here provides a comprehensive library that can be interfaced using various user interfaces and efficiently drive the motor through the Kria Drive SOM board.
+
The following diagram illustrates the top-level architecture and arrangement of various software components:
+
+
+
Kernel: Ubuntu Linux kernel
+
+
Drivers:
+
+
xilinx_adc_hub: IIO driver for analog-to-digital converter (ADC) HUB
+
hls_qei_axi: IIO driver for the QEI sensor
+
hsl_foc_periodic: IIO driver for the sensor based field oriented controller
+
hls_pwm_gen: IIO driver for PWM GEN
+
hsl_svpwm_duty: IIO driver for SVPWM
+
+
+
+
+
Middleware
+
+
IIO Framework and libiio library
+
Generic UIO framework
+
+
+
Application and library
+
+
Motor Control Library (includes UIO driver for the custom Motor Control IP)
All the kernel drivers developed for the platform hardware are Industial I/O (IIO) based and adhere to the IIO kernel framework. The IIO subsystem covers many sensor and ADC devices in the industry. It provides the following features to fetch and control various parameters:
+
+
Divide the stream and type of data into logical channels.
+
Each channel can have specific attributes along with device attributes to fine-tune the behavior.
+
Efficient data collection using buffers to get deterministic data with timestamps and sync with other channels.
+
Interrupt handling to provide user side event handling.
+
+
The following drivers are added to support this app:
+
+
ADC Hub (xilinx_adc_hub): Provides an interface to monitor current, voltage, and related faults that occur during the operation of the motor.
+
QEI Encoder (hls_qei_axi): External encoder to monitor the real-time speed and position of the motor.
+
FOC (hsl_foc_periodic): Field oriented controller driver to support various operational modes and state of the motor.
+
PWM_GEN (hls_pwm_gen): PWM_GEN provides PWM signal generation for motor control.
+
SVPWM_GEN (hsl_svpwm_duty): SVPWM provides space vector PWM to calcualte phase ratio for the motor.
+
+
There is also custom Motor control IP, which is responsible for the design specific glue logic and driving the motor’s Gate Driver. The driver for this IP is a UIO based and the device will instantiate the UIO device for this IP. The userspace driver for this is implemented inside the motor control library in the control block.
As explained in the next section, the attributes exposed by each drivers can be accessed through sysfs interface or through libraries like libIIO.
+
Most of the attribute names are self-explanatory. If a channel attribute is named input, it indicates that the device requires raw data for processing, and the final processed data can be read from the input channel attribute. If the input channel attribute is not present, the raw data itself represents the final value from the device.
+
A couple of common device attributes accross IIO drivers in this application are:
+
+
sample_interval_us: This parameter represents the time period in microseconds. It determines the rate at which data is sampled and stored into the buffer. Only channel data is captured within the buffer.
+
ap_ctrl: This attribute conforms to the standard AMD HLS interface for IP, enabling the initiation of its operation.
+
+
The device attributes applies to entire device for all the channels. The channel attributes are per channel configurations or data. Here are some of the attributes exposed by above drivers:
The driver exposes the IIO devices through the sysfs interface. The drivers can be accessed from the path /sys/bus/iio/devices/iio\:deviceX, where X is the numeric enumeration of the IIO device.
+
libIIO is the userspace library to easily access the kernel IIO subsystem. It also provides various methods and command line interfaces, packaged in libiio-utils, to access the IIO devices. There are other Python wrappers around this library, but the motor control library uses a native C/C++ library.
+
For example, to list all the available IIO devices:
+
ubuntu@kria:~$ iio_attr -c
+IIO context has 7 devices:
+ iio:device0, ams: found 30 channels
+ iio:device1, ina260-u14: found 6 channels
+ iio:device2, hls_foc_periodic: found 11 channels
+ iio:device3, hls_qei_axi: found 3 channels
+ iio:device4, xilinx_adc_hub: found 9 channels
+ iio:device5, hls_svpwm_duty: found 4 channels
+ iio:device6, hls_pwm_gen: found 4 channels
+
The custom motor control IP is accessed from the motor control library using the UIO interface. A device tree node with compatible string as generic-uio is added to connect this hardware to the UIO subsystem.
+
The device is now accessible in the userspace through the /dev/uioX device. Information about the device is obtained by scanning /sys/class/uio/uioX, where X is the UIO device id automatically assigned by the kernel.
+
For more information on the UIO interface, refer to the kernel documentation.
The motor control library is a C++ library that provides APIs for the front end application to control and fetch motor parameters. It also has a pybind11 wrapper to support the library APIs through python front end. The front end GUI included with this application is based on a python bokeh server, which can be accessed in a web browser in the network.
The Event Manager is responsible for configuring and monitoring events/faults from various hardware blocks. This block is aware of event capabilities of various control blocks and configures the events accordingly.
+
It caches the event status in realtime and returns that to user when requested. The event is monitored in a separate thread which waits on epoll events for the registered events. Optionally, it also provides callback function registration in case additional action is expected when a realtime event occurs.
This block is responsible for hardware access. There are interface classes which implement common interfaces for all the IIO based control handlers and all the UIO based control handlers. It also provides abstraction for the sensor interface to support more than one sensor (only one used at a given time).
+
The following various handlers are for controlling the respective hardware:
+
+
FOC: For controlling and fetching data from the FOC hardware through the libiio framework.
+
ADCHub: For controlling and fetching data from the ADCHub hardware through the libiio framework.
+
Sensor: Abstraction for controlling and fetching data from the sensor hardware through the libiio framework (QEI in this case).
+
PWM_Gen: For controlling the PWM_GEN hardware through the libiio framework.
+
SVPWM: For controlling the SVPWM hardware through the libiio framework.
+
MC_UIO: For controlling custom Motor Control IP hardware through the UIO framework.
+
SW_AvgPower: Software based average power calculator to generate fault and control gate driver through MC_UIO.
The following additional threads are implemented in the library:
+
+
Speed Ramp: When a new speed set point is set, the speed is ramped up or down in the FOC control handler using the constant ramp rate defined in default_config.h.
+
Torque Ramp: When new torque set point is set, the speed is ramped up or down in the FOC control handler using the constant ramp rate defined in default_config.h.
+
Event Monitor: The event manager waits on any event using epoll_wait in its own thread.
A python based bokeh server is implemented to provide a GUI interface to the application. It imports the motor control python library. The plot updates are handled by an update function which is called at the interval specified in the Refresh Interval text box. For each update, the function requests the number of samples specified in the Sample Size text box and update the plots with new data.
+
For more details on the GUI usage, refer the Application Deployment page for the details on the components and its usage.