
Data Sheet
177
Rev. 1.2, 2006-01-26
QuadFALC
TM
PEF 22554 E
Functional Description T1/J1
Switching between HDLC and BOM (if both MODE.BRAC and MODE.HRAC are set) is described in
Each HDLC/BOM controller can be reset individually without disturbing the transmission on the remaining
channels. Use CMDR.SRES for HDLC channel 1, CMDR3.SRES2 for HDLC channel 2 and CMDR4.SRES3 for
Note that CMDR.RRES resets the whole RX path and therefor all HDLC channels.
After a XDU interrupt on a HDLC controller, the appropriate transmit signalling controller must be reset.
After an RDO interrupt on a HDLC controller, the receive HDLC controller needs no reset. So a receive HDLC
controller reset per channel is not necessary.
In case of common channel signaling the signaling procedure HDLC/SDLC or LAPD according to Q.921 is
supported. The signaling controller of the QuadFALC
TM performs the flag detection, CRC checking, address
comparison and zero bit removing. The received data flow and the address recognition features can be performed
in very flexible way, to satisfy almost any practical requirements. Depending on the selected address mode, the
QuadFALC
TM performs a 1 or 2-byte address recognition. If a 2-byte address field is selected, the high address
byte is compared with the fixed value FE
H or FCH (group address) as well as with two individually programmable
values in RAH1 and RAH2 registers. According to the ISDN LAPD protocol, bit 1 of the high byte address is
interpreted as command/response bit (C/R) and is excluded from the address comparison. Buffering of receive
data is done in a 64 byte deep RFIFO.
In signaling controller transparent mode, fully transparent data reception without HDLC framing is performed, i.e.
without flag recognition, CRC checking or bit stuffing. This allows user specific protocol variations.
5.3.2
Support of Signaling System #7 (T1/J1)
HDLC controller 1 of each of the four channels of the QuadFALC
TM supports the signaling system #7 (SS7) which
is described in ITU-Q.703. The following description assumes, that the reader is familiar with the SS7 protocol
definition.
SS7 support must be activated by configuring the register bits MODE.MDS(2:0) (MODE_T). The SS7 protocol is
supported by the following hardware features in receive mode:
All Signaling Units (SU) are stored in the receive FIFO (RFIFO)
Detecting of flags from the incoming data stream
Bit stuffing (zero deletion)
Checking of seven or more consecutive ones in the receive data stream
Checking if the received Signaling Unit is a multiple of eight bits and at least six octets including the opening
flag
Calculation of the CRC16 checksum: In receive direction the calculated checksum is compared to the received
one; errors are reported in register RSIS.
Checking if the signal information field of a received signaling unit consists of more than 272 octets, in this case
the current signaling unit is discarded.
In order to reduce the micro controller load, fill In signaling units (FISUs) are processed automatically. By
examining the length indicator of a received signal unit the QuadFALC
TM decides whether a FISU has been
received. Consecutively received FISUs are compared and optionally not stored in the receive FIFO (RFIFO, up
to 2 x 64 bytes), if the contents is equal to the previous one. The same applies to link status signaling units, if bit
CCR5.CSF is set. The different types of signaling units as message signaling unit (MSU), link status signaling unit
(LSSU) and fill in signaling units (FISU) are indicated in the RSIS register, which is automatically added to the
RFIFO with each received signaling unit. The complete signaling unit except start and end flags is stored in the
receive FIFO. The functions of bits CCR2.RCRC and CCR2.RADD (CCR2_T) are still valid in SS7 mode. Errored
signaling units are handled automatically according to ITU-T Q.703 as shown in Figure 45. SU counter (su) and
errored SU counter (Cs) are reset by setting CMDR2.RSUC. The error threshold T can be selected to be 64
(default) or 32 by setting/clearing bit CCR5.SUET (CCR5_T). If the defined error limit is exceeded, an interrupt
(ISR1.SUEX) is generated, if not masked by IMR1.SUEX = 1.
Note: If SUEX is caused by an aborted/invalid frame, the interrupt will be issued regularly until a valid frame is
received (e.g. a FISU).