CS4210 datasheet(28/102 Pages) NSC

28 / 102 page

www.national.com

Revision 1.0

Operational Description (Continued)

3.7

HOST BUS ERRORS

The CS4210 has three primary goals when dealing with

host bus error conditions:

Continue transmission and/or reception on all contexts

not involved in the error.

Provide information to software which is sufficient to

allow recovery from the error when possible.

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 theprocessingofadescriptor:

• 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

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

theCS4210tosendapacketwithalengththatdoesnot

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.

CS4210 датащи(PDF) 28 Page - National Semiconductor (TI)

CS4210 датащи(HTML) 28 Page - National Semiconductor (TI)

Html Pages

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 ...More

датащи скачать

ссылки URL