UPD360 datasheet(115/221 Pages) MICROCHIP

115 / 221 page

 2016-2017 Microchip Technology Inc.

DS00002084C-page 115

UPD360

Note that for a received good packet to abort a pending transmission, the SOP type of the received packet must match

the SOP type of the pending transmission, or the SOP type of the received packet must be SOP with the SOP type of

the pending transmission being non-SOP (the latter can be disabled via the DIS_SOP_ABRTS_NON_SOP bit in the TX

Control Register A (TX_CTL_A)) and, for messages other than Soft-Reset, the received message ID must indicate a

non-duplicated packet (Soft-Resets are never considered duplicates). Ping and GoodCRC messages do not cause a

transmission to abort.

Separate TX interrupt abort bits and separate abort status registers are provided for software issued and auto-response

packets.

11.1.2.3

Transmit Retries

Transmitted packets are retried under two scenarios: bus idle violations, and GoodCRC response timeout.

If the transmission is discarded due to the bus being non-idle, the option exists to retry instead of treating it as an abort.

In order for this to occur, the packet must have been initiated by software, not be a hard or cable reset, auto response

mode must be enabled, the retry count must be non-zero, and the RETRY_ON_LINE_BUSY bit in the TX Control Reg-

ister A (TX_CTL_A) must be set. If after the specified number of retries, the transmission failed due to bus busy, the

TX_FAILED status is set (not TX_ABORTED). Hard and Cable resets are not retried.

Following the transmission of a software initiated frame (other than Hard and Cable resets), the device will start a timer

and wait for a GoodCRC response to be indicated by the receiver. This assumes retries and / or the wait for GoodCRC

are enabled.

If a GoodCRC is received with the correct SOP type and message ID, then the wait is finished and the transmission is

done. If a GoodCRC is received with the wrong SOP type or message ID, it is ignored by the transmitter (the transmitter

is not even notified) and silently dropped by the receiver.

If the wait for CRC timer expires and the remaining retry count is non-zero, the original packet is re-transmitted. If the

remaining retry count is zero, then the packet is not retried and a failed status is indicated.

The wait for GoodCRC will be aborted if any of the following are received:

• A hard reset

• A cable reset (if cable reset reception is enabled and the SOP type of the pending TX is SOP', SOP'', SOP'_De-

bug or SOP''_Debug)

• A soft-reset (if the SOP type of the RX is the same as that of the pending TX or the SOP type of the RX is SOP

with the SOP type of the pending transmission being non-SOP)

• A good packet other than a GoodCRC or Ping (if the SOP type of the RX is the same as that of the pending TX or

the SOP type of the RX is SOP with the SOP type of the pending transmission being non-SOP (the latter can be

disabled via the DIS_SOP_ABRTS_NON_SOP bit in the TX Control Register A (TX_CTL_A)) and the package is

not a duplicate message)

The latter two causes are considered to be protocol errors.

The wait for GoodCRC can also be aborted by software. An aborted wait for GoodCRC is not retried.

11.1.2.4

Transmitter Disable

In order to avoid a race condition where the software is currently issuing a transmit and the hardware is receiving a

packet, the EN_FWTX bit in the TX Parameters Register A (TX_PARAM_A) is automatically cleared if a hard reset to a

cable reset (if enabled - no SOP type checking is done since a transmission may not be pending) has been received

(based on the RX_CABLE_RST and RX_HARD_RST bits in the RX Interrupt Status Register (RX_IRQ_STAT)) or if

there is any data in the RX FIFO. Using the interrupt and FIFO status (level sensitive) instead of the even occurrence

(edge) avoids another race condition where the software has set the EN_FWTX bit just following the event.

11.1.3

TX COMM

The TX Comm is responsible for taking the coded nibbles from TX Control, encoding it if necessary, and serializing to

make it ready for transmission. It is responsible for preamble insertion, CRC calculation, and CRC insertion. It also pro-

vides the TX clock signal for the BMC encoder.

11.1.3.1

Preamble Insertion

The device automatically adds the alternating “0” and “1” preamble to the transmitted packet. When the transmission of

the preamble is completed, data from TX Queue is processed under direction of the TX Control.

UPD360 датащи(PDF) 115 Page - Microchip Technology

UPD360 датащи(HTML) 115 Page - Microchip Technology

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