Functional Description
5.19.10 USB 2.0 Based Debug Port
The ICH10 supports the elimination of the legacy COM ports by providing the ability for
new debugger software to interact with devices on a USB 2.0 port.
High-level restrictions and features are:
• Operational before USB 2.0 drivers are loaded.
• Functions even when the port is disabled.
• Works even though non-configured port is default-routed to the UHCI. Note that
the Debug Port can not be used to debug an issue that requires a full-speed/low-
speed device on Port #0 using the UHCI drivers.
• Allows normal system USB 2.0 traffic in a system that may only have one USB port.
• Debug Port device (DPD) must be high-speed capable and connect directly to
Port #0 and Port #6 on ICH10 systems (e.g., the DPD cannot be connected to
Port #0/Port #6 through a hub).
• Debug Port FIFO always makes forward progress (a bad status on USB is simply
presented back to software).
• The Debug Port FIFO is only given one USB access per microframe.
The Debug port facilitates operating system and device driver debug. It allows the
software to communicate with an external console using a USB 2.0 connection.
Because the interface to this link does not go through the normal USB 2.0 stack, it
allows communication with the external console during cases where the operating
system is not loaded, the USB 2.0 software is broken, or where the USB 2.0 software is
being debugged. Specific features of this implementation of a debug port are:
• Only works with an external USB 2.0 debug device (console)
• Implemented for a specific port on the host controller
• Operational anytime the port is not suspended AND the host controller is in D0
power state.
• Capability is interrupted when port is driving USB RESET
5.19.10.1 Theory of Operation
There are two operational modes for the USB debug port:
1. Mode 1 is when the USB port is in a disabled state from the viewpoint of a standard
host controller driver. In Mode 1, the Debug Port controller is required to generate a
“keepalive” packets less than 2 ms apart to keep the attached debug device from
suspending. The keepalive packet should be a standalone 32-bit SYNC field.
2. Mode 2 is when the host controller is running (i.e., host controller’s Run/Stop# bit
is 1). In Mode 2, the normal transmission of SOF packets will keep the debug
device from suspending.
Behavioral Rules
1. In both modes 1 and 2, the Debug Port controller must check for software
requested debug transactions at least every 125 microseconds.
2. If the debug port is enabled by the debug driver, and the standard host controller
driver resets the USB port, USB debug transactions are held off for the duration of
the reset and until after the first SOF is sent.
3. If the standard host controller driver suspends the USB port, then USB debug
transactions are held off for the duration of the suspend/resume sequence and until
after the first SOF is sent.
4. The ENABLED_CNT bit in the debug register space is independent of the similar
port control bit in the associated Port Status and Control register.
Datasheet
209
INTEL [ INTEL ]
