Zilog Z16C30 - Manual (Page 102)

5-35
Z16C30 USC ®
U SER ' S M ANUAL Z ILOG
UM97USC0100
On the Receive side , software can’t directly read the RCC
(except perhaps by using test modes that are beyond the
scope of this section). Instead, when the Receiver detects
an end-of-frame situation, it captures the decremented
value in the counter into a four-entry RCC FIFO. (It may do
this when it receives a Flag or Sync character, or, in
External Sync and 802.3 modes only, when the /DCD pin
goes false.) It then reloads the RCC from RCLR in prepa-
ration for the next frame. If software enables two-word
Receive Status Blocks, the channel stores the captured
RCC value as the second word of the RSB.
USCs manufactured before June 1993 used a hidden
register called RCHR to hold the RCC value for a 32-bit
RSB. Those manufactured since then take the RCC value
in a 32-bit RSB from the RCC FIFO.
Besides recording the length of received frames/mes-
sages, the RCC feature can help detect frames or mes-
sages that are longer than a maximum length defined by
the serial protocol. This typically happens because the
Flag, terminating character or Sync character(s) separat-
ing two frames or messages gets corrupted on the serial
link. This makes the two frames or messages look like a
single continuous one to the Receiver. The usual strategy
in such a case is to ignore (or possibly “NAK”) the whole
mess.
If the channel decrements the RCC to zero and then
receives another character as part of the same frame/
message, it sets the
RCCUnder L/U bit in the Miscella-
neous Interrupt Status Register (MISR3). To use this fea-
ture to check for overly long frames or messages, program
the RCLR with the maximum number of characters that a
frame or message can validly have. This value should
include CRC characters but exclude any Receive Status
Block information. Also, arm the RCC Underflow interrupt
by setting the RCCUnder IA bit in the Status Interrupt
Control Register (SICR3), as described in Chapter 7.
If the channel ever sets RCCUnder L/U and interrupts,
clear the condition by writing a 1 to the L/U bit, write the
“Enter Hunt Mode” command to the RCmd field of the
Receive Command/Status Register (RCSR15-12), discard
the data received for the frame(s) by purging the RxFIFO,
reprogram the external Receive DMA controller if one is
being used, and do whatever else is necessary to clean up
the situation.
5.19.2 The RCC FIFO
Figure 5-14 shows the RCC FIFO. When software has
enabled the Receive Character Counter, the FIFO cap-
tures the contents of the RCC at the end of each frame or
message in External Sync, Transparent Bisync, 802.3, and
HDLC/SDLC modes. (The previous section described how
the Receiver decrements the RCC by one for each charac-
ter it receives.)
The RCC FIFO can hold up to four 16-bit entries.
Figure 5-15 shows the Channel Command/Status Register
(CCSR), the 3 MSBits of which allow software to monitor
and control the RCC FIFO. The
RCCFAvail bit (CCSR14)
is 1 if the RCC FIFO contains at least one entry, or is 0 if the
RCC FIFO is empty.
When software selects 32-bit Receive Status Blocks as
described in a later section, USCs manufactured after
June 1993 automatically remove an entry from the RCC
FIFO as they store the second word of an RSB. In other
applications, software can monitor RCCFAvail to know
when to read the RCC FIFO: when RCCFAvail is 1 software
can read the oldest entry in the RCC FIFO from the Receive
Character Count Register (RCCR).
Whether the RCC residual is obtained from an RSB or by
reading RCCR, software can then compute the length of
the frame or message by subtracting this ending value
from the starting value that came from the Receive Count
Limit Register (RCLR). (Or, if the starting value was all
ones, software can simply one’s complement the value
from RCCR.) Reading the RCCR removes the oldest entry
from the RCC FIFO.
For internal synchronization reasons, a channel does not
set RCCFAvail, nor certain other status flags related to an
End-of-Frame condition, until one bit time after it places the
last character of the frame in the RxFIFO. USCs manufac-
tured before June 1993 will request an Rx Data interrupt
and/or an Rx DMA Request from the same clock at which
they place this last character in the FIFO, so that an Rx Data
interrupt service routine may not see RCCAvail set. How-
ever, USCs manufactured since June 1993 delay forcing
an Rx Data interrupt and/or an Rx DMA Request until the
same RxCLK rising edge at which they set RCCFAvail, so
that an Rx Data interrupt service routine can rely on the
RCC FIFO and its status flags being current.
UM009402-0201