summaryrefslogtreecommitdiff
path: root/usb
diff options
context:
space:
mode:
authorBarry Golden <[email protected]>2019-09-30 17:39:26 -0700
committerGitHub <[email protected]>2019-09-30 17:39:26 -0700
commit7462901d24795f20d14d01c9f871f9b0bc2d52f8 (patch)
tree8290cd4611323cf4092388f6f86e6785761be51f /usb
parent85e09b9be0b4359d46d3fdf196b4a39e74060920 (diff)
Update README.md (#428)886938869288691886908868988688
Diffstat (limited to 'usb')
-rw-r--r--usb/UcmCxUcsi/README.md23
-rw-r--r--usb/UcmTcpciCxClientSample/README.md105
-rw-r--r--usb/kmdf_enumswitches/README.md2
-rw-r--r--usb/kmdf_fx2/README.md213
-rw-r--r--usb/umdf_filter_kmdf/README.md2
-rw-r--r--usb/umdf_filter_umdf/README.md2
6 files changed, 182 insertions, 165 deletions
diff --git a/usb/UcmCxUcsi/README.md b/usb/UcmCxUcsi/README.md
index 65afdb6a..6204f630 100644
--- a/usb/UcmCxUcsi/README.md
+++ b/usb/UcmCxUcsi/README.md
@@ -15,17 +15,20 @@ This is a sample driver that shows how to create a Windows USB Type-C port contr
## Background reading - UcmCx documentation
-Start at the UcmCx documentation at [USB Type-C connector driver programming reference](https://msdn.microsoft.com/en-us/library/windows/hardware/mt188011(v=vs.85).aspx).
+Start at the UcmCx documentation at [USB Type-C connector driver programming reference](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/_usbref/#type-c-driver-reference).
## Note on UCSI
-Microsoft already provides an inbox UCSI driver, UcmUcsi.sys. This UcmCxUcsi sample driver is not identical to the inbox UCSI driver. Microsoft recommends that you use the inbox UcmUcsi.sys for your UCSI-compliant system rather than writing your own. This sample driver is meant for developers bringing up a UcmCx driver for their own non-UCSI platforms. For more information about the UCSI driver, reference [USB Type-C Connector System Software Interface (UCSI) driver](https://msdn.microsoft.com/en-us/library/windows/hardware/mt710944(v=vs.85).aspx).
+Microsoft already provides an inbox UCSI driver, UcmUcsi.sys. This UcmCxUcsi sample driver is not identical to the inbox UCSI driver. Microsoft recommends that you use the inbox UcmUcsi.sys for your UCSI-compliant system rather than writing your own. This sample driver is meant for developers bringing up a UcmCx driver for their own non-UCSI platforms. For more information about the UCSI driver, reference [USB Type-C Connector System Software Interface (UCSI) driver](https://docs.microsoft.com/windows-hardware/drivers/usbcon/ucsi).
This sample demonstrates the following:
- Registration with the USB Connector Manager (UCM) class extension driver.
+
- Initializing the port controller's Type-C and Power Delivery capabilities.
+
- Performing data and power role swaps requested by UCM
+
- Notifying UCM of Type-C and Power Delivery events on the connector.
## Customizing the sample for your port controller
@@ -41,10 +44,15 @@ In this sample, UCM-specific interactions are split apart from most of the UCSI-
The following files contain methods that interface with UcmCx.
- UcmCallbacks.cpp
- - Contains the implementations [EVT_UCM_CONNECTOR_SET_DATA_ROLE](https://msdn.microsoft.com/en-us/library/windows/hardware/mt187818(v=vs.85).aspx) and [EVT_UCM_CONNECTOR_SET_POWER_ROLE](https://msdn.microsoft.com/en-us/library/windows/hardware/mt187818(v=vs.85).aspx). These are callbacks from UCM which ask the client driver to perform role swaps.
+
+ - Contains the implementations [EVT_UCM_CONNECTOR_SET_DATA_ROLE](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/ucmmanager/nc-ucmmanager-evt_ucm_connector_set_data_role) and [EVT_UCM_CONNECTOR_SET_POWER_ROLE](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/ucmmanager/nc-ucmmanager-evt_ucm_connector_set_power_role). These are callbacks from UCM which ask the client driver to perform role swaps.
+
- UcmNotifications.cpp
- - Contains methods that communicate with UcmCx using the client driver support methods described in the [USB Type-C connector driver programming reference](https://msdn.microsoft.com/en-us/library/windows/hardware/mt188011(v=vs.85).aspx).
+
+ - Contains methods that communicate with UcmCx using the client driver support methods described in the [USB Type-C connector driver programming reference](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/_usbref/#type-c-driver-reference).
+
- Fdo.cpp
+
- FDO callbacks, functions, and types, most of which do not interface with UCM. However, the method `Fdo_EvtDeviceSelfManagedIoInit` contains the code segment which initializes the device with UCM.
### UCSI and WDF Interactions
@@ -52,12 +60,17 @@ The following files contain methods that interface with UcmCx.
The remainder of the files perform operations for UCSI and WDF, non-specific to UCM.
- Acpi.cpp
+
- ACPI method evaluation helper routines.
+
- Driver.cpp
+
- Entry point to the driver. Initializes the driver with WDF.
+
- Ppm.cpp
+
- Type-C Platform Policy Manager. Main interface to talk to the UCSI-compliant hardware.
## When to write a UcmCx client driver
-UcmCx is intended for system port controller drivers. If you are bringing up a USB Type-C peripheral, you do not need to write a USB Type-C specific driver; a regular USB client driver will suffice. Refer to [Developing Windows client drivers for USB devices](https://msdn.microsoft.com/en-us/library/windows/hardware/hh406260(v=vs.85).aspx) to determine what type of driver, if any, you need to write to make your USB device work with Windows. You may look at [Do I need to write a driver for my USB Type-C hardware?](https://blogs.msdn.microsoft.com/usbcoreblog/2016/06/20/do-i-need-to-write-a-driver-for-my-usb-type-c-hardware/) for a more detailed overview.
+UcmCx is intended for system port controller drivers. If you are bringing up a USB Type-C peripheral, you do not need to write a USB Type-C specific driver; a regular USB client driver will suffice. Refer to [Developing Windows client drivers for USB devices](https://docs.microsoft.com/windows-hardware/drivers/usbcon/usb-driver-development-guide) to determine what type of driver, if any, you need to write to make your USB device work with Windows. You may look at [Do I need to write a driver for my USB Type-C hardware?](https://techcommunity.microsoft.com/t5/Microsoft-USB-Blog/Do-I-need-to-write-a-driver-for-my-USB-Type-C-hardware/ba-p/270876) for a more detailed overview.
diff --git a/usb/UcmTcpciCxClientSample/README.md b/usb/UcmTcpciCxClientSample/README.md
index a9a2edba..a59bf2bb 100644
--- a/usb/UcmTcpciCxClientSample/README.md
+++ b/usb/UcmTcpciCxClientSample/README.md
@@ -10,18 +10,25 @@ products:
# UcmTcpciCx Port Controller Client Driver
-This is a skeleton sample driver that shows how to create a Windows USB Type-C port controller driver using the USB Connector Manager Type-C Port Controller Interface class extension driver (UcmTcpciCx). UcmTcpciCx is currently only availble using the Windows Insider program - documentation for UcmTcpciCx will be available at the next release of Windows.
+This is a skeleton sample driver that shows how to create a Windows USB Type-C port controller driver using the USB Connector Manager Type-C Port Controller Interface class extension driver (UcmTcpciCx). UcmTcpciCx is currently only available using the Windows Insider program - documentation for UcmTcpciCx will be available at the next release of Windows.
This sample demonstrates the following:
-- Registration with the UcmTcpci class extension driver (UcmTcpciCx).
-- Initializing the port controller's Type-C and Power Delivery capabilities.
-- Initializing the I2C communications channel to the port controller hardware.
-- Performing reads/writes over I2C.
-- Handling hardware requests from UcmTcpciCx.
-- Handling alerts from the port controller hardware and notifying UcmTcpciCx of the alert.
-- Power management.
-- Platform-level device reset in the case of an unresponsive I2C controller.
+- Registration with the UcmTcpci class extension driver (UcmTcpciCx)
+
+- Initializing the port controller's Type-C and Power Delivery capabilities
+
+- Initializing the I2C communications channel to the port controller hardware
+
+- Performing reads/writes over I2C
+
+- Handling hardware requests from UcmTcpciCx
+
+- Handling alerts from the port controller hardware and notifying UcmTcpciCx of the alert
+
+- Power management
+
+- Platform-level device reset in the case of an unresponsive I2C controller
## Customizing the sample for your port controller
@@ -29,7 +36,7 @@ The sample contains a number of comments prefaced with `// TODO` - review them a
## Note regarding Type-C port controller hardware
-This sample assumes a device that complies with the USB Type-C Port Controller Interface specification, Revision 1.0 (part of the [USB 3.1 specification download](http://usb.org/developers/docs)). Such a device uses a predefined register layout and an I2C communications channel.
+This sample assumes a device that complies with the USB Type-C Port Controller Interface specification, Revision 1.0 (part of the [USB 3.1 specification download](https://usb.org/documents)). Such a device uses a predefined register layout and an I2C communications channel.
If your port controller hardware is not exactly compliant with the specification, you will need to make additional modifications to the sample.
## Performing read/writes over I2C
@@ -39,7 +46,7 @@ If your port controller hardware is not compliant with the specification and doe
## When to write a UcmTcpciCx client driver
-UcmTcpciCx is intended for system port controller drivers. If you are bringing up a USB Type-C peripheral, you do not need to write a USB Type-C specific driver; a regular USB client driver will suffice. Refer to [Developing Windows client drivers for USB devices](https://msdn.microsoft.com/en-us/library/windows/hardware/hh406260(v=vs.85).aspx) to determine what type of driver, if any, you need to write to make your USB device work with Windows.
+UcmTcpciCx is intended for system port controller drivers. If you are bringing up a USB Type-C peripheral, you do not need to write a USB Type-C specific driver; a regular USB client driver will suffice. Refer to [Developing Windows client drivers for USB devices](https://docs.microsoft.com/windows-hardware/drivers/usbcon/usb-driver-development-guide) to determine what type of driver, if any, you need to write to make your USB device work with Windows.
## Testing Your Type-C Port Controller (TCPC) Implementation on Windows 10 with Raspberry Pi
@@ -53,43 +60,27 @@ You will also need the Windows 10 IoT Core Insider Preview builds, the IoT tool
#### Operating System
-Download the latest available Windows 10 IoT Core Insider Preview image here:
-
-<https://www.microsoft.com/en-us/software-download/windowsiot>
-
-Install on your Raspberry Pi 2 or 3 per the following instructions:
-
-<https://developer.microsoft.com/en-us/windows/iot/GetStarted>
+Download the latest available [Windows 10 IoT Core Insider Preview](https://www.microsoft.com/software-download/windowsiot) and install on your Raspberry Pi 2 or 3 per the instructions at [Windows for Internet of Things](https://developer.microsoft.com/windows/iot).
Note, you will only need to complete the first two steps, “1 Get the tools” and “2 Setup your device” to proceed with the TCPC validation described here.
#### PowerShell Connection
-Connect to your Raspberry Pi via a PowerShell remote session. You will use this connection to setup the debugger and install your TCPCI driver package.
-
-<https://developer.microsoft.com/en-us/windows/iot/docs/powershell>
+Connect to your Raspberry Pi via a [PowerShell](https://docs.microsoft.com/windows/iot-core/connect-your-device/powershell) remote session. You will use this connection to setup the debugger and install your TCPCI driver package.
#### Windows Device Portal
-Open a connection to the Raspberry Pi via the Windows Device Portal. The portal provides a Device Manager view in which you will be able to inspect your TCPC device, as well as remote shutdown and reboot controls.
-
-<https://developer.microsoft.com/en-us/windows/iot/docs/deviceportal>
+Open a connection to the Raspberry Pi via the Windows [Device Portal](https://docs.microsoft.com/windows/iot-core/manage-your-device/DevicePortal). The portal provides a Device Manager view in which you will be able to inspect your TCPC device, as well as remote shutdown and reboot controls.
#### Kernel Debugger
-Setup the kernel debugger for your Raspberry Pi according to the instructions at the following location:
-
-<https://developer.microsoft.com/en-us/windows/iot/docs/windbg>
+Setup the kernel debugger for your Raspberry Pi according to the instructions at the [Windows Debugger (WinDbg)](https://docs.microsoft.com/windows/iot-core/manage-your-device/windowsdebugger) for IoT.
#### Connect TCPC Hardware
The following assumes an I2C implementation of your TCPC; if your device uses a different transport, ignore the I2C specific references and connect the transport as appropriate.
-First, shutdown and remove power from both the Raspberry Pi and your TCPC hardware. Once both boards are powered down, connect the four pins outlined below. Please refer to the GPIO pinout specification for the version of the Raspberry Pi platform you are using for the specific locations. Pin numbers referenced below are for the Raspberry Pi 2 Model B v1.1.
-
-<img src="https://az835927.vo.msecnd.net/sites/iot/Resources/images/PinMappings/RP2_Pinout.png" width="447" height="305" />
-
-**Figure 1:** Raspberry Pi 2 Model B v1.1 Pinout
+First, shutdown and remove power from both the Raspberry Pi and your TCPC hardware. Once both boards are powered down, connect the four pins outlined below. Please refer to the GPIO pinout specification for the version of the Raspberry Pi platform you are using for the specific locations.
Connect the following pins between your TCPC and the Raspberry Pi:
@@ -115,9 +106,7 @@ Edit the INF to set the device path and strings to desired custom values. Build
#### Install Driver Package
-Follow the instructions at the link below to create a driver package in the form of a CAB file for your custom UcmTcpciCx client driver:
-
-<https://developer.microsoft.com/en-us/windows/iot/docs/installpackage>
+[Create a driver package for IoT](https://docs.microsoft.com/windows-hardware/manufacture/iot/create-install-package) in the form of a CAB file for your custom UcmTcpciCx client driver.
Once you have generated the CAB file, see step 3 for instructions on installing the driver package on your Raspberry Pi via the PowerShell connection established earlier. After the package has been installed and the system has rebooted, there is still one more step to getting your driver to load: updating the ACPI tables to describe the device to the platform.
@@ -133,11 +122,9 @@ Open sample.asl provided in the UcmTcpciCxClientSample driver sample and modify
On a PC with the Windows 10 WDK installed run the following command on your updated ASL file:
-asl.exe sample.asl
-
-This will produce output file ACPITABL.dat. Copy this file to *C:\\Windows\\System32* on your Raspberry Pi device, and reboot. See the “Verification” section in the following link for more information on merging ACPI updates into an IoT image without a full UEFI build:
+`asl.exe sample.asl`
-<https://msdn.microsoft.com/en-us/windows/uwp/devices-sensors/enable-usermode-access>
+This will produce output file ACPITABL.dat. Copy this file to *C:\\Windows\\System32* on your Raspberry Pi device, and reboot. See the [Verification](https://docs.microsoft.com/windows/uwp/devices-sensors/enable-usermode-access#verification) section in *Enable usermode access to GPIO, I2C, and SPI* for more information on merging ACPI updates into an IoT image without a full UEFI build.
Once the Raspberry Pi has rebooted, your driver will load on the newly enumerated ACPI device node.
@@ -145,13 +132,9 @@ Once the Raspberry Pi has rebooted, your driver will load on the newly enumerate
#### USB Type-C Connection Exerciser
-The USB Type-C Connection Exerciser is a tool designed by Microsoft and manufactured by MCCI available for purchase at the link below:
-
-<http://www.mcci.com/mcci-v5/devtools/exerciser-type-c.html>
-
-The tools and instructions for deploying testing with this device are available for download on MSDN:
+The [MCCI Model 3101 Type-C Connection Exerciser](http://www.mcci.com/mcci-v5/devtools/exerciser-type-c.html) is a tool designed by Microsoft and manufactured by MCCI.
-<https://msdn.microsoft.com/en-us/library/windows/hardware/dn376875(v=vs.85).aspx>
+The tools and instructions for deploying testing with this device are available at [Testing USB hardware, drivers, and apps in Windows](https://docs.microsoft.com/windows-hardware/drivers/usbcon/usb-driver-testing-guide).
Suggested testing with the Connection Exerciser device is randomized connect/disconnect for long periods of time.
@@ -159,9 +142,7 @@ Suggested testing with the Connection Exerciser device is randomized connect/dis
The sample driver includes standard WDF logging which can be extracted via the kernel debugger with the following debugger command:
-```cmd
-!wdfkd.wdflogdump <driver name> -d
-```
+`!wdfkd.wdflogdump <driver name> -d`
Other useful driver traces are available from *UcmTcpciCx* and *UcmCx*.
@@ -185,30 +166,14 @@ UcmTcpciCx: 8DEAEA72-4C63-49A4-9B8B-25DA24DAE056
### Resources
-USB Type-C Port Controller Interface Specification (TCPCI), download as part of USB 3.1 Specification:
-
-<http://www.usb.org/developers/docs/>
-
-Raspberry Pi
-
-<https://www.raspberrypi.org/>
-
-<https://developer.microsoft.com/en-us/windows/iot/Docs/PinMappingsRPi.htm>
-
-Windows 10 IoT
-
-<https://www.microsoft.com/en-us/software-download/windowsiot>
-
-<https://developer.microsoft.com/en-us/windows/iot/>
-
-Windows Insider Preview WDK
+[USB Type-C Port Controller Interface Specification (TCPCI)](https://www.usb.org/documents) (download as part of USB 3.1 Specification)
-<https://www.microsoft.com/en-us/software-download/windowsinsiderpreviewWDK>
+[Raspberry Pi](https://www.raspberrypi.org)
-Microsoft USB Test Tools
+[Windows 10 IoT Core Insider Preview](https://www.microsoft.com/software-download/windowsiot)
-<https://msdn.microsoft.com/en-us/library/windows/hardware/dn376873(v=vs.85).aspx>
+[Windows for Internet of Things](https://developer.microsoft.com/windows/iot)
-Tracelog Command Syntax
+[Windows Insider Preview WDK](https://www.microsoft.com/software-download/windowsinsiderpreviewWDK)
-<https://msdn.microsoft.com/en-us/library/windows/hardware/ff553012(v=vs.85).aspx>
+[Tracelog Command Syntax](https://docs.microsoft.com/windows-hardware/drivers/devtest/tracelog-command-syntax)
diff --git a/usb/kmdf_enumswitches/README.md b/usb/kmdf_enumswitches/README.md
index 2bfb8ac3..6425fca2 100644
--- a/usb/kmdf_enumswitches/README.md
+++ b/usb/kmdf_enumswitches/README.md
@@ -12,7 +12,7 @@ products:
The kmdf\_enumswitches sample demonstrates how to use Kernel-Mode Driver Framework (KMDF) as a bus driver using the OSR USB-FX2 device.
-This sample is written for the OSR USB-FX2 Learning Kit. The specification for the device is at <http://www.osronline.com/hardware/OSRFX2_32.pdf>.
+This sample is written for the [OSR USB-FX2 Learning Kit](http://www.osronline.com/hardware/OSRFX2_32.pdf).
## Testing the Device
diff --git a/usb/kmdf_fx2/README.md b/usb/kmdf_fx2/README.md
index ec709686..54f9815a 100644
--- a/usb/kmdf_fx2/README.md
+++ b/usb/kmdf_fx2/README.md
@@ -12,9 +12,9 @@ products:
The kmdf\_fx2 sample is a Kernel-Mode Driver Framework (KMDF) driver for the OSR USB-FX2 device. It includes a test app and sample device metadata.
-In the Windows Driver Kit (WDK), the osrusbfx2 sample demonstrated how to perform bulk and interrupt data transfers to an USB device. The sample was written for the OSR USB-FX2 Learning Kit.
+In the Windows Driver Kit (WDK), the osrusbfx2 sample demonstrates how to perform bulk and interrupt data transfers to an USB device. The sample was written for the [OSR USB-FX2 Learning Kit](http://www.osronline.com/hardware/OSRFX2_32.pdf).
-The specification for the device is at <http://www.osronline.com/hardware/OSRFX2_32.pdf>. The driver and sample device metadata also work with the [Custom driver access](http://go.microsoft.com/fwlink/p/?LinkID=248288) sample.
+The driver and sample device metadata also works with the [Custom driver access](https://code.msdn.microsoft.com/windowsapps/Custom-device-access-sample-43bde679) sample.
## Universal Windows Driver Compliant
@@ -24,81 +24,119 @@ This sample builds a Universal Windows Driver. It uses only APIs and DDIs that a
Here is the overview of the device:
-- The device is based on the development board supplied with the Cypress EZ-USB FX2 Development Kit (CY3681).
-- It contains 1 interface and 3 endpoints (Interrupt IN, Bulk Out, Bulk IN).
-- Firmware supports vendor commands to query or set LED Bar graph display and 7-segment LED display, and to query toggle switch states.
-- Interrupt endpoint:
- - Sends an 8-bit value that represents the state of the switches.
- - Sent on startup, resume from suspend, and whenever the switch pack setting changes.
- - Firmware does not de-bounce the switch pack.
- - One switch change can result in multiple bytes being sent.
- - Bits are in the reverse order of the labels on the pack (for example, bit 0x80 is labeled 1 on the pack).
-- Bulk endpoints are configured for loopback:
- - The device moves data from IN endpoint to OUT endpoint.
- - The device does not change the values of the data it receives nor does it internally create any data.
- - Endpoints are always double buffered.
- - Maximum packet size depends on speed (64 full speed, 512 high speed).
-- Event Tracing for Windows (ETW) events:
- - Included osrusbfx2.man, which describes events added.
- - Three events are targeted to the event log:
- - Failure during the add device routine.
- - Failure to start the OSR device on a USB 1.1 controller.
- - Invocation of the "re-enumerate device" IOCTL.
- - Read/write start/stop events can be used to measure the time taken.
- - For more information, see Unified Tracing later in this document.
+- The device is based on the development board supplied with the Cypress EZ-USB FX2 Development Kit (CY3681).
-Code tour
----------------
+- It contains 1 interface and 3 endpoints (Interrupt IN, Bulk Out, Bulk IN).
-**usb\\kmdf\_fx2\\driver**
+- Firmware supports vendor commands to query or set LED Bar graph display and 7-segment LED display, and to query toggle switch states.
+
+- Interrupt endpoint:
+
+ - Sends an 8-bit value that represents the state of the switches.
+
+ - Sent on startup, resume from suspend, and whenever the switch pack setting changes.
+
+ - Firmware does not de-bounce the switch pack.
+
+ - One switch change can result in multiple bytes being sent.
+
+ - Bits are in the reverse order of the labels on the pack (for example, bit 0x80 is labeled 1 on the pack).
+
+- Bulk endpoints are configured for loopback:
+
+ - The device moves data from IN endpoint to OUT endpoint.
+
+ - The device does not change the values of the data it receives nor does it internally create any data.
+
+ - Endpoints are always double buffered.
+
+ - Maximum packet size depends on speed (64 full speed, 512 high speed).
+
+- Event Tracing for Windows (ETW) events:
+
+ - Included osrusbfx2.man, which describes events added.
+
+ - Three events are targeted to the event log:
+
+ - Failure during the add device routine.
+
+ - Failure to start the OSR device on a USB 1.1 controller.
+
+ - Invocation of the "re-enumerate device" IOCTL.
+
+ - Read/write start/stop events can be used to measure the time taken.
+
+ - For more information, see Unified Tracing later in this document.
+
+## Code tour
+
+### usb\\kmdf\_fx2\\driver
This directory contains driver code that demonstrates the following functionality:
-- Loads the driver and responds to PnP and Power events. You can install, uninstall, disable, enable, suspend, and resume the system.
-- Creates a context with the WDFDEVICE object.
-- Initializes the USB device by registering a *EvtPrepareHardware* callback.
-- Marks the interface restricted so that it can be accessed by a privileged UWP device app.
-- Creates a default parallel queue to receive an IOCTL request to set bar graph display.
-- Retrieves memory handle from the requests and uses it to send a vendor command to the USB device.
-- Registers read and write events on the default queue.
-- Retrieves memory from read and write requests, formats the requests, and sends it to a USB target.
-- Creates two separate sequential queues and configures them to dispatch read and write requests directly. (*\*kmdf\_fx2 only*)
-- Enables wait-wake and selective suspend support. (*\*kmdf\_fx2 only*)
-- Configures a USB target continuous reader to read toggle switch states asynchronously from the interrupt endpoint. (*\*kmdf\_fx2 only*)
-- Supports additional IOCTLs to get and set the 7-segment display and toggle switches, and to reset and re-enumerate the device. (*\*kmdf\_fx2 only*)
-- Creates ETW provider to log two events to the event log, and read/write start stop events. (*\*kmdf\_fx2 only*)
-- WPP tracing.
+- Loads the driver and responds to PnP and Power events. You can install, uninstall, disable, enable, suspend, and resume the system.
+
+- Creates a context with the WDFDEVICE object.
+
+- Initializes the USB device by registering a *EvtPrepareHardware* callback.
-**usb\\kmdf\_fx2\\exe**
+- Marks the interface restricted so that it can be accessed by a privileged UWP device app.
+
+- Creates a default parallel queue to receive an IOCTL request to set bar graph display.
+
+- Retrieves memory handle from the requests and uses it to send a vendor command to the USB device.
+
+- Registers read and write events on the default queue.
+
+- Retrieves memory from read and write requests, formats the requests, and sends it to a USB target.
+
+- Creates two separate sequential queues and configures them to dispatch read and write requests directly. (*\*kmdf\_fx2 only*)
+
+- Enables wait-wake and selective suspend support. (*\*kmdf\_fx2 only*)
+
+- Configures a USB target continuous reader to read toggle switch states asynchronously from the interrupt endpoint. (*\*kmdf\_fx2 only*)
+
+- Supports additional IOCTLs to get and set the 7-segment display and toggle switches, and to reset and re-enumerate the device. (*\*kmdf\_fx2 only*)
+
+- Creates ETW provider to log two events to the event log, and read/write start stop events. (*\*kmdf\_fx2 only*)
+
+- WPP tracing
+
+### usb\\kmdf\_fx2\\exe
This directory contains a test application that can be used to drive the KMDF driver and FX2 device.
-**usb\\kmdf\_fx2\\deviceMetadata**
+### usb\\kmdf\_fx2\\deviceMetadata
-This directory contains the device metadata package for the sample. You must copy the device metadata to the system before installing the device. For information on how to update and deploy device metadata, see the [Custom driver access sample](http://go.microsoft.com/fwlink/p/?LinkID=248288).
+This directory contains the device metadata package for the sample. You must copy the device metadata to the system before installing the device. For information on how to update and deploy device metadata, see the [Custom driver access](https://code.msdn.microsoft.com/windowsapps/Custom-device-access-sample-43bde679) sample.
-Testing the driver
-------------------
+## Testing the driver
-You can use the [Custom driver access](http://go.microsoft.com/fwlink/p/?LinkID=248288) sample as a testing method.
+You can use the [Custom driver access](https://code.msdn.microsoft.com/windowsapps/Custom-device-access-sample-43bde679) sample as a testing method.
The sample also includes a test application, osrusbfx2.exe, that you can use to test the device. This console application enumerates the interface registered by the driver and opens the device to send read, write, or IOCTL requests based on the command line options.
Usage for Read/Write test:
-- -r [*n*], where *n* is number of bytes to read.
-- -w [*n*], where *n* is number of bytes to write.
-- -c [*n*], where *n* is number of iterations (default = 1).
-- -v, shows verbose read data.
-- -p, plays with Bar Display, Dip Switch, 7-Segment Display.
-- -a, performs asynchronous I/O operation.
-- -u, dumps USB configuration and pipe information.
+- -r [*n*], where *n* is number of bytes to read.
-**Playing with the 7 segment display, toggle switches, and bar graph display**
+- -w [*n*], where *n* is number of bytes to write.
+
+- -c [*n*], where *n* is number of iterations (default = 1).
+
+- -v, shows verbose read data.
+
+- -p, plays with Bar Display, Dip Switch, 7-Segment Display.
+
+- -a, performs asynchronous I/O operation.
+
+- -u, dumps USB configuration and pipe information.
+
+### Playing with the 7 segment display, toggle switches, and bar graph display
Use the command, **osrusbfx2.exe -p** options 1-9, to set and clear bar graph display, set and get 7 segment state, and read the toggle switch states. The following shows the function options:
-```
+```cmd
1. Light bar
2. Clear bar
3. Light entire bar graph
@@ -116,41 +154,41 @@ Use the command, **osrusbfx2.exe -p** options 1-9, to set and clear bar graph di
Selection:
```
-**Reset and re-enumerate the device**
+### Reset and re-enumerate the device
Use the command, osrusbfx2.exe -p with option 10 and 11, to either reset the device or re-enumerate the device.
-**Read and write to bulk endpoints**
+### Read and write to bulk endpoints
The following commands send read and write requests to the device's bulk endpoint.
-- `osrusbfx2.exe -r 64`
+- `osrusbfx2.exe -r 64`
The preceding command reads 64 bytes to the bulk IN endpoint.
-- `osrusbfx2.exe -w 64 `
+- `osrusbfx2.exe -w 64`
The preceding command writes 64 bytes to the bulk OUT endpoint.
-- `osrusbfx2.exe -r 64 -w 64 -c 100 -v`
+- `osrusbfx2.exe -r 64 -w 64 -c 100 -v`
The preceding command first writes 64 bytes of data to bulk OUT endpoint (Pipe 1), then reads 64 bytes from bulk IN endpoint (Pipe 2), and then compares the read buffer with write buffer to see if they match. If the buffer contents match, it repeats this operation 100 times.
-- `osrusbfx2.exe -a`
+- `osrusbfx2.exe -a`
The preceding command reads and writes to the device asynchronously in an infinite loop.
The bulk endpoints are double buffered. Depending on the operational speed (full or high), the buffer size is either 64 bytes or 512 bytes, respectively. A request to read data does not complete if the buffers are empty. If the buffers are full, a request to write data does not complete until the buffers are emptied. When you are doing a synchronous read, make sure the endpoint buffer has data (for example, when you send a 512 bytes write request to the device operating in full speed mode). Because the endpoints are double buffered, the total buffer capacity is 256 bytes. The first 256 bytes fills the buffer, and the write request waits in the USB stack until the buffers are emptied. If you run another instance of the application to read 512 bytes of data, both write and read requests complete successfully.
-**Displaying descriptors**
+### Displaying descriptors
The following command displays all the descriptors and endpoint information.
-**osrusbfx2.exe -u**
+`osrusbfx2.exe -u`
If the device is operating in high speed mode, you will get the following information:
-```
+```cmd
===================
USB_CONFIGURATION_DESCRIPTOR
@@ -221,9 +259,9 @@ bEndpointAddress= 0x6 ( OUTPUT )
bmAttributes= 0x2 ( USB_ENDPOINT_TYPE_BULK )
-wMaxPacketSize= 0x200,
+wMaxPacketSize= 0x200,
-decimal 512 bInterval = 0x0,
+decimal 512 bInterval = 0x0,
decimal 0
@@ -263,7 +301,7 @@ iConfiguration = 0x3, decimal 3
bmAttributes = 0xa0 ( USB_CONFIG_BUS_POWERED )
-MaxPower = 0x32, decimal 50
+MaxPower = 0x32, decimal 50
-----------------------------
@@ -334,8 +372,7 @@ wMaxPacketSize= 0x40, decimal 64
bInterval = 0x0, decimal 0
```
-Unified tracing
----------------
+## Unified tracing
To view events the provider manifest must be installed. As part of the installation, from an elevated prompt run the following: `wevtutil im osrusbfx2.man`
@@ -343,34 +380,36 @@ Registering the manifest sets up the appropriate paths where the system can find
To trace, you can use the in-box tools, logman and tracerpt, or download XPerf (Windows Performance Toolkit) from Microsoft.
-**Using in-box tools**
+### Using in-box tools
+
+#### To start/stop the trace by using logman
+
+1. Start tracing by using the following command:
-**To start/stop the trace by using logman:**
+ `logman start sample -o osrusbfx2.etl -ets -p OSRUSBFX2`
-1. Start tracing by using the following command:
+1. Generate activity through the osrusbfx2 test application, such as `osrusbfx2.exe -a`.
- `logman start sample -o osrusbfx2.etl -ets -p OSRUSBFX2`
+1. Stop tracing by using the following command:
-2. Generate activity through the osrusbfx2 test application, such as `osrusbfx2.exe -a`.
-3. Stop tracing by using the following command:
+ `Logman stop sample`
- `Logman stop sample`
+1. View the trace file using tracerpt:
-4. View the trace file using tracerpt:
+ `tracerpt -of csv OSRUSBFX2.etl`
- `tracerpt -of csv OSRUSBFX2.etl `
+#### To start/stop the trace by using Xperf (Windows Performance Toolkit)
-**To start/stop the trace by using Xperf (Windows Performance Toolkit):**
+1. Start tracing by using the following command:
-1. Start tracing by using the following command:
+ `xperf -start sample -f osrusbfx2.etl -on OSRUSBFX2`
- `xperf -start sample -f osrusbfx2.etl -on OSRUSBFX2`
+1. Generate activity through the osrusbfx2 test application, such as `osrusbfx2.exe -a`.
-2. Generate activity through the osrusbfx2 test application, such as `osrusbfx2.exe -a`.
-3. Stop tracing by using the following command:
+1. Stop tracing by using the following command:
- `xperf -stop sample`
+ `xperf -stop sample`
-4. View the trace file using Xperf:
+1. View the trace file using Xperf:
- `xperfview OSRUSBFX2.etl`
+ `xperfview OSRUSBFX2.etl`
diff --git a/usb/umdf_filter_kmdf/README.md b/usb/umdf_filter_kmdf/README.md
index 6b6ea8c8..83bd40dc 100644
--- a/usb/umdf_filter_kmdf/README.md
+++ b/usb/umdf_filter_kmdf/README.md
@@ -12,7 +12,7 @@ products:
The umdf\_filter\_kmdf sample demonstrates how to load a UMDF filter driver as an upper filter driver above the kmdf\_fx2 sample driver.
-The sample includes Event Tracing for Windows (ETW) tracing support, and is written for the OSR USB-FX2 Learning Kit. The specification for the device is at <http://www.osronline.com/hardware/OSRFX2_32.pdf>.
+The sample includes Event Tracing for Windows (ETW) tracing support, and is written for the [OSR USB-FX2 Learning Kit](http://www.osronline.com/hardware/OSRFX2_32.pdf0.
## Build the sample
diff --git a/usb/umdf_filter_umdf/README.md b/usb/umdf_filter_umdf/README.md
index 15c41483..2f77953e 100644
--- a/usb/umdf_filter_umdf/README.md
+++ b/usb/umdf_filter_umdf/README.md
@@ -12,7 +12,7 @@ products:
The umdf\_filter\_umdf sample demonstrates how to load a User-Mode Driver Framework (UMDF) filter driver as an upper filter driver above the umdf\_fx2 sample driver.
-This sample is written for the OSR USB-FX2 Learning Kit. The specification for the device is at <http://www.osronline.com/hardware/OSRFX2_32.pdf>.
+This sample is written for the [OSR USB-FX2 Learning Kit](http://www.osronline.com/hardware/OSRFX2_32.pdf).
## Overview