CS4210 Datasheet, PDF (28/102 Pages) National Semiconductor (TI) – IEEE 1394 OHCI Controller

Operational Description (Continued)
3.7 HOST BUS ERRORS
The CS4210 has three primary goals when dealing with
host bus error conditions:
1) Continue transmission and/or reception on all contexts
not involved in the error.
2) Provide information to software which is sufficient to
allow recovery from the error when possible.
3) Provide a means of error recovery on a context other
than a general chip reset.
3.7.1 Causes of Host Bus Errors
Host bus errors can generally be classified as one of the
following:
• Addressing error (e.g., non-existent memory location)
• Operation error (e.g., attempt to write to read-only
memory)
• Data transfer error (e.g., parity or unrecoverable ECC)
• Time-out error (e.g., reply on split transaction bus was
not received in time)
Each of these errors can occur at three identifiable stages
in the processing of a descriptor:
• Descriptor fetch
• Data transfer (read or write)
• Optional descriptor status update.
In general, the nature of the bus error is not as significant
as the stage of descriptor processing in which it occurs. For
example, the difference between an addressing error and a
data parity error is not significant to the error processing.
3.7.2 CS4210 Actions When Host Bus Error Occurs
When a host bus error occurs, the CS4210 performs a
defined set of actions for all context types. Additionally,
there is a set of actions that is performed depending on the
context type. The following subsections outline these
actions.
3.7.2.1 Descriptor Read Error
When an error occurs during the reading of a descriptor or
descriptor block, the behavior of the CS4210 is the same
regardless of the context type. The CS4210 sets Context-
Control.dead and sets ContextControl.event to
evt_descriptor_read to indicate that the descriptor fetch
failed. The unrecoverable error IntEvent is generated and
the context’s IntEvent is not set. Additionally, CommandPtr
is set to point to a descriptor within the descriptor block in
which the error occurred. Since the descriptor could not be
read, its xferStatus and resCount are not written with cur-
rent values, and software must refer to ContextCon-
trol.event for the status.
3.7.2.2 xferStatus Write Error
For any type of context, when the CS4210 encounters an
error writing the status to a descriptor, it sets ContextCon-
trol.dead. The values that would have been written to xfer-
Status of a descriptor are retained in ContextControl for
inspection by system software. The unrecoverable error
IntEvent is generated and the context’s IntEvent is not set
regardless of the setting of the interrupt (i) field in the
descriptor. Additionally, CommandPtr is set to point to a
descriptor within the descriptor block in which the error
occurred.
3.7.2.3 Transmit Data Read Error
For asynchronous request transmit, asynchronous
response transmit, and isochronous transmit, the CS4210
handles system data read errors in a similar manner. The
CS4210 does not stop processing for the context. Instead,
the event code in the status of the OUTPUT_LAST*
descriptor is set to indicate that there was an error and the
nature of the error. The indicated errors are evt_data_read
or evt_underrun. If the error occurs before a packet’s
header is placed in the output FIFO, the CS4210 can
immediately abort the packet transfer, optionally set the
descriptor status to evt_data_read or evt_underrun, and
move on to the next descriptor block. If the error occurs
after the header has been placed in the output FIFO, the
CS4210 stops placing data in the output FIFO. This causes
the CS4210 to send a packet with a length that does not
agree with the data_length field of the header. If the
CS4210 receives an ack_data_error from the addressed
node, then the CS4210 substitutes evt_data_read or
evt_underrun as appropriate. If the device returns anything
other than ack_data_error, then the CS4210 stores that
value in the status for the packet. This means that if the
addressed node returns an ack_pending on a block write,
the error indication is lost.
If the packet was a broadcast write, an isochronous packet,
or an asynchronous stream packet, no ack code is received
from any node. In this case, the CS4210 assumes that
ack_data_error was received and proceeds as outlined
above.
Note:
Underruns which occur due to host bus latency are
not construed to be host bus data errors, and as a
result such asynchronous request and response
packets are retried as described in Section 4.4.3
"ATRetries Register" on page 59.
www.national.com
28
Revision 1.0