FW82371EBSL37M Intel, FW82371EBSL37M Datasheet - Page 32

• Manufacturer Part Number: FW82371EBSL37M
• Description: Embedded Processor 352-Pin BGA
• Manufacturer: Intel

Specifications of FW82371EBSL37M

• Package: 352BGA

Intel
19.
Problem:
Implication: The host controller response to this is a non-acknowledge with a CRC/Timeout status
Workaround: There are two possible workarounds.
Status:
20.
Problem:
Implication: System hangs due to the “inaccuracy” of the timer when used by software for time critical events
Workaround: Read the register twice and compare.
Status:
32
®
82371AB PIIX4, 82371EB PIIX4E, 82371MB PIIX4M
USB Dribble
A USB receive packet with a bitstuff following then transmission of CRC, coupled with a dribble
bit due to prop delays through cables and HUBs may be incorrectly interpreted by the USB host
controller state machine as a poorly formed EOP.
communicated to the software. If this condition persists the error count associated with this packet
will be exceeded and an interrupt can be generated to software. This will stall the USB device.
Current software reports a device error to the user via a pop up window. Another implication is that
the installed base may have limited USB expandablility via HUBs.
1.
2.
This will not be fixed in the PIIX4/PIIX4M/PIIX4E. This is planned to be fixed in future
implementations of the UHCI host controller.
ACPI Timer
The power management timer may return improper result when read. Although the timer value
settles properly after incrementing, while incrementing there is a 3 ns window every 69.8 ns where
the timer value is indeterminate (a 4.2% chance that the data will be incorrect when read). As a
result, the ACPI free running count up timer specification is violated due to erroneous reads.
and delays.
This will not be fixed in the PIIX4 or PIIX4E. It has been fixed in the PIIX4M.
Hardware: Try plugging the USB device into a USB port closer to the root hub.
Software: Detect the CRC/Timeout error and count exceeded and attempt to re-queue the
packets while changing the length of the packets. Changing the length of the packets will
change the CRC and thus potentially (likely) remove the combination of the two events
causing the failure.
Specification Update
R