Zilog Z16C30 - Manual (Page 90)

5-23
Z16C30 USC ®
U SER ' S M ANUAL Z ILOG
UM97USC0100
If the TxCRCatEnd bit (TMR8) is 1 and the TxMode field
(CMR11-8) specifies a synchronous mode, the Transmitter
sends the contents of its CRC generator after sending a
character marked as EOF/EOM. If TxCRCatEnd is 0 the
Transmitter doesn’t send a CRC after such a character. (A
character can be marked as EOF/EOM if software writes a
command to the Transmit Command/Status Register
(TCSR), or when software or an external Transmit DMA
controller writes one or two characters to the TxFIFO so that
the Transmit Character Counter decrements to zero.)
Whether or not it sends a CRC, the Transmitter then sends
a Sync or Flag sequence, depending on the protocol.
In synchronous modes, the MS 1 or 2 bits of the TxSubMode
field (CMR15 and in some modes also CMR14) control
whether the Transmitter sends the contents of its CRC
generator if it encounters a Transmit Underrun condition,
namely if it needs a character to send but the TxFIFO is
empty. Whether or not it sends a CRC, the Transmitter then
sends a Sync or Flag sequence, depending on the proto-
col.
On the receive side , in synchronous modes other than
HDLC/SDLC, HDLC/SDLC Loop, and 802.3, there’s a two
character delay between the time a Receiver places each
received character in the RxFIFO and when it processes
(or doesn’t process) the character through the CRC gen-
erator. Therefore, software can examine each received
character and set RxCRCEnab appropriately to exclude
certain characters from CRC checking, if it can do so
before the next one arrives. A Receiver doesn’t introduce
this delay in HDLC/SDLC, HDLC/SDLC Loop, or 802.3
mode, because in these modes all characters in each
frame should be included in the CRC calculation.
Figure 5-9 shows how a Receiver routes data to the
Receive CRC generator differently in HDLC/SDLC, HDLC/
SDLC Loop, and 802.3 modes than in other synchronous
modes. In the former three modes, the Receiver shifts each
bit from RxD into the CRC generator when it shifts the bit
into its main shift register. In other sync modes, the Re-
ceiver passes the data through a second shift register
located between the main shift register and the CRC
generator. This second shift register is effectively
(RxLength) bits long, and gives the software time to decide
whether to include each received character in the CRC
calculation.
The Receive CRC generator constantly checks whether its
contents are “correct” according to the kind of CRC
specified by the RxCRCType field (RMR12-11). In some
modes this simply means whether it contains an all-zero
value. The CRC generator provides a corresponding Error
output that the Receiver captures in the RxFIFO with each
received character. This bit migrates through the RxFIFO
with each character and eventually appears as the CRCE/
FE bit in the Receive Command/Status Register (RCSR3).
Software should ignore this bit for all characters except the
one associated with the end of each message or frame (it’s
almost always 1).
The CRCE bit that’s important is the one that reflects the
output of the CRC generator after the Receiver has shifted
the last bit of the CRC into it. But the operating difference
described above affects which character this bit is asso-
ciated with. The Receiver always places the CRC code
itself in the RxFIFO; if RxLength calls for 8-bit characters
the CRC represents either 2 or 4 characters. In HDLC/
SDLC or 802.3 mode, the CRCE bit associated with the last
character of the CRC is the one that shows the CRC-
correctness of the frame. But in the other synchronous
modes, the CRCE bit of interest is the one with the second
character after the last character of the CRC. This means
that the Receive Status Block feature can’t be used to
capture the CRC correctness of received messages in
Transparent Bisync mode.
Note that the CRCE/FE bit can represent the status at the
time that an RxBound character was read from the RxFIFO,
or the status of the oldest 1 or 2 characters that are still in
the RxFIFO, as described later in 'Status Reporting'.
Because the Receiver places all the bits of each received
CRC in the RxFIFO, a USC channel can be used for CRC-
pass-through applications. This is not true of all serial
controllers.
UM009402-0201