PEB2070NV2.4 ,ICC (ISDN Communication Controller)characteristics.Terms of delivery and rights to change design reserved.For questions on technology, ..
PEB2070NV2.4 ,ICC (ISDN Communication Controller)Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..
PEB2070N-V2.4 ,ICC (ISDN Communication Controller)ICs for CommunicationsISDN Communication ControllerICCPEB 2070PEF 2070 User’s Manual 01.94 PEB 207 ..
PEB2070NV2.4 . ,ICC (ISDN Communication Controller)Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..
PEB2070PV2.4 ,ICC (ISDN Communication Controller)characteristics apply at TA = 25 °C and the given supply voltage.Operating RangeIn the operating ra ..
PEB2070PV2.4 ,ICC (ISDN Communication Controller)Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..
PIC16F883 , 28/40/44-Pin, Enhanced Flash-Based 8-Bit CMOS Microcontrollers with nanoWatt Technology
PIC17C42A , High-Performance 8-Bit CMOS EPROM/ROM Microcontroller
PIC18F2525-I/SO , 28/40/44-Pin Enhanced Flash Microcontrollers with 10-Bit A/D and nanoWatt Technology
PIC18F2620-I/SO , 28/40/44-Pin Enhanced Flash Microcontrollers with 10-Bit A/D and nanoWatt Technology
PIC18F2620-I/SO , 28/40/44-Pin Enhanced Flash Microcontrollers with 10-Bit A/D and nanoWatt Technology
PIC18F2620-I/SP , 28/40/44-Pin Enhanced Flash Microcontrollers with 10-Bit A/D and nanoWatt Technology
PEB2070NV2.4-PEB2070N-V2.4-PEB2070NV2.4 .-PEB2070PV2.4-PEF2070NV2.4
ICC (ISDN Communication Controller)
General Information
Table of ContentsPageFeatures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.1Pin Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2Pin Definitions and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3Logic Symbol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4Functional Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.5System Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.5.1ISDN Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.5.2Other Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.5.3Microprocessor Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Functional Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.1General Functions and Device Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2Serial Interface Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.1IOM®-1 Mode (IMS=0, DIM2=0) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.2IOM®-2 Mode (IMS=1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.3HDLC Controller Mode (IMS=0, DIM2=1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.1 mP Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.2ISDN Oriented Modular (IOM®) Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3.3SSI (Serial Port A) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.3.4SLD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.4Individual Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.4.1Layer-2 Functions for HDLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.4.1.1Message Transfer Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.4.1.2Protocol Operations (auto mode) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.4.1.3Reception of Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.4.1.4Transmission of Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.4.2B-Channel Switching (IOM®-1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.4.3Access to B / IC Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.4.4C/I Channel Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
2.4.5MONITOR Channel Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
2.4.6Terminal Specific Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
2.4.7Test Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
2.4.8Documentation of the Auto Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Operational Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913.1Microprocessor Interface Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
3.2Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
3.3Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
3.4IOM® Interface Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
3.5Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
3.5.1Interrupt Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
3.5.2Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
3.5.2.1HDLC Frame Reception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
3.5.2.2HDLC Frame Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
General Information
Table of ContentsPageDetailed Register Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1124.1HDLC Operation and Status Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
4.1.1Receive FIFO RFIFO Read Address 00-1FH . . . . . . . . . . . . . . . . . . . . . . . . 117
4.1.2Transmit FIFO XFIFO Write Address 00-1FH . . . . . . . . . . . . . . . . . . . . . . . . 117
4.1.3Interrupt Status Register ISTA Read Address 20H . . . . . . . . . . . . . . . . . . . . . 117
4.1.4Mask Register MASK Write Address 20H . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
4.1.5Status Register STAR Read Address 2H . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
4.1.6Command Register CMDR Write Address 2H . . . . . . . . . . . . . . . . . . . . . . . . 120
4.1.7Mode Register MODE Read/Write Address 22H . . . . . . . . . . . . . . . . . . . . . . 121
4.1.8Timer Register TIMR Read/Write Address 23H . . . . . . . . . . . . . . . . . . . . . . . 124
4.1.9Extended Interrupt Register EXIR Read Address 24H . . . . . . . . . . . . . . . . . 126
4.1.10Transmit Address 1 XAD1 Write Address 24H . . . . . . . . . . . . . . . . . . . . . . . 127
4.1.11Receive Frame Byte Count Low RBCL Read Address 25H . . . . . . . . . . . . . 128
4.1.12Transmit Address 1 XAD2 Write Address 25H . . . . . . . . . . . . . . . . . . . . . . . 128
4.1.13Received SAPI Register SAPR Read Address 26H . . . . . . . . . . . . . . . . . . . 129
4.1.14SAPI1 Register SAP1 Write Address 26H . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
4.1.15Receive Status Register RSTA Read Address 27H . . . . . . . . . . . . . . . . . . . . . . 130
4.1.16SAP12 Register SAP2 Write Address 27H . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
4.1.17TEI1 Register 1 TEI1 Write Address 28H . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
4.1.18Receive HDLC Control Register RHCR Read Address 29H . . . . . . . . . . . . . . . . 132
4.1.19TEI2 Register TEI2 Write Address 29H . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
4.1.20Receive Frame Byte Count High RBCH Read Address 30H . . . . . . . . . . . . . . 134
4.1.21Status Register 2 STAR2 Read Address 2BH . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
4.2Special Purpose Registers: IOM-1Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
4.2.1Serial Port Control Register SPCR Read/Write Address 30H . . . . . . . . . . . . . . . 135
4.2.2Command/Indication Receive Register CIRR Read Address 31H . . . . . . . . . . . 137
4.2.3Command/Indication Transmit Register CIXR Write Address 31H . . . . . . . . . . . 138
4.2.4MONITOR Receive Register MOR Read Address 32H . . . . . . . . . . . . . . . . . . . . 139
4.2.5MONITOR Transmit Register MOX Write Address 32H . . . . . . . . . . . . . . . . . . . 139
4.2.6SIP Signaling Code Receive SCR Read Address 33H . . . . . . . . . . . . . . . . . . . . 139
4.2.7SIP Signaling Code Transmit SSCX Write Address 33H . . . . . . . . . . . . . . . . . . 139
4.2.8SIP Feature Control Read SFCR Read Address 34H . . . . . . . . . . . . . . . . . . . . 140
4.2.9SIP Feature Control Write SFCW Write Address 34H . . . . . . . . . . . . . . . . . . . . . 140
4.2.10Channel Register 1 C1R Read/Write Address 35H . . . . . . . . . . . . . . . . . . . . . . . 140
4.2.11Channel Register 2 C2R ead/Write Address 36H . . . . . . . . . . . . . . . . . . . . . . . . 140
4.2.12B1 Channel Register B1CR Read Address 37H . . . . . . . . . . . . . . . . . . . . . . . . . 141
4.2.13Synchronous Transfer Control Register STCR Write Address 37H . . . . . . . . . . 141
4.2.14B2 Channel Register B2CR Read Address 38H . . . . . . . . . . . . . . . . . . . . . . . . . 142
4.2.15Additional Feature Register 1 ADF1 Write Address 38H . . . . . . . . . . . . . . . . . . 142
4.2.16Additional Feature Register 2 ADF2 Read/Write Address 39H . . . . . . . . . . . . . . 143
General Information
Table of ContentsPage4.3Special Purpose Registers: IOM-2 Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
4.3.1Serial Port Control Register SPCR Read/Write Address 30H . . . . . . . . . . . . . . . 144
4.3.2Command/Indication Receive 0 CIR0 Read Address 31H . . . . . . . . . . . . . . . . . 146
4.3.3Command/Indication Transmit 0 CIX0 Write Address 31H . . . . . . . . . . . . . . . . . 146
4.3.4MONITOR Receive Channel 0 MOR0 Read Address 32H . . . . . . . . . . . . . . . . . 147
4.3.5MONITOR Transmit Channel 0 MOX0 Write Address 32H . . . . . . . . . . . . . . . . . 148
4.3.6Command/Indication Receive 1 CIR1 Read Address 33H . . . . . . . . . . . . . . . . . 148
4.3.7Command/Indication Transmit 1 CIX1 Write Address 33H . . . . . . . . . . . . . . . . . 148
4.3.8MONITOR Receive Channel 1 MOR1 Read Address 34H . . . . . . . . . . . . . . . . . 149
4.3.9Channel Register 1 C1R Read/Write Address 35H . . . . . . . . . . . . . . . . . . . . . . . 149
Electrical Characteristics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156Package Outlines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168Figure 24a until figure 26d are CCITT recommendations for comparison.
Introduction The transmission and protocol functions in an ISDN basis access can be all be implemented
using the CMOS circuits of the ISDN Oriented Modular (IOM®) chip set. While three chips, the
S Bus interface Circuit SBC (PEB 2080), the ISDN Echo Cancellation circuit IEC (PEB 2090)
and the ISDN Burst Controller IBC (PEB 2095) perform the transmission functions in different
applications (S and U interface), the ISDN Communication Controller ICC (PEB 2070) acts as
the D-channel-link-access protocol controller.
The IOM® architecture makes possible a wide range of configurations for the Basic Access,
using the basic devices. These configurations essentially differ in the implementation of the
layer-1 OSI functions, while the layer-2 functions are provided by the ICC for all configurations.
In addition to that, the PEB 2070 provides the interface to B-channel sources in the terminal
and to a peripheral board controller (PEB 2050, 51, 52 etc.) at the exchange.
The HDLC packets of the ISDN D channel are handled by the ICC which transfers them to the
associated microcontroller. The ICC has on-chip buffer memories (64 bytes per direction) for
the temporary storage of data packets. Because of the overlapping I/O operations the
maximum length of the D-channel packets is not limited. In one of its operating modes the
device offers high level support of layer-2 functions of the LAPD protocol.
Aside from ISDN applications, the ICC can be used as a general purpose communication
controller in all applications calling for LAPD, LAPB or other HDLC/SDLC based
protocols.
1.1Pin Definitions and Functions
Pin Definitions and Functions (cont’d)
Pin Definitions and Functions (cont’d)
Pin Definitions and Functions (cont’d)
1.2Logic Symbol
1.3Functional Block Diagram
1.4System Integration
1.4.1ISDN ApplicationsThe reference model for the ISDN basic access according to CCITT I series recommendations
consists ofan exchange and trunk line termination in the central office (ET, LT)a remote network termination in the user area (NT)a two-wire loop (U interface) between NT and LTa four-wire link (S interface) which connects subscriber terminals and the NT in the user
area as depicted in figure 1.
Figure 1
ISDN Subscriber Basic Access ArchitectureThe NT equipment serves as a converter between the U interface at the exchange and the S
interface at the subscriber premises. The NT may consist of either an NT1 only or an NT1 to-
gether with an NT2 connected via the T interface which is physically identical to the S interface.
The NT1 is a direct transformation between layer 1 of S and layer 1 of U. NT2 may include
higher level functions like multiplexing and switching as in a PABX.
In terms of channels the ISDN access consists of:a number of 64 kbit/s bearer channels (n x B)
e.g.n = 2 for basic rate ISDN access
n = 30 or 23 for primary rate ISDN access;and a signaling channel (D), either 16 (basic rate) or 64 (primary rate) kbit/s
(figure 2).
Figure 2
ISDN Basic Access Channel Structure
The B channels are used for end-to-end circuit switched digital connections between
communicating stations.
The D channel is used to carry signaling and data via protocols defined by the CCITT. These
protocols cover the network services layers of the open system interconnection model (Layers
1-3). At layer 2, the data link layer, an HDLC type protocol is employed, the link access
procedure on the D channel LAPD (CCITT Rec. Q. 920/1).
The ISDN Communication Controller PEB 2070 can be used in all ISDN applications involving
establishment and maintenance of the data link connection in either the D channel or B
channel. It also provides the interface to layer-1 functions controlled via the IOM which links
the ICC to any transceiver or peripheral device. Depending on the interface mode, the ICC
supports three serial interfaces and offers switching functions and μP access to voice/ data
channels.
The applications comprise:Use as a signaling controller for the D channelAccess to the D channel for data transmissionSource/ sink for secured B-channel data
and the target equipment include:ISDN terminalISDN PABX (NT2) and Central Office (ET) line cardISDN packet switches“Intelligent” NT1.
Terminal ApplicationsThe concept of the ISDN basic access is based on two circuit-switched 64 kbit/s B channels
and a message oriented 64 kbit/s D channel for packetized data, signaling and telemetry
information.
Figure 3 shows an example of an integrated multifunctional ISDN terminal using the ICC.The transceiver provides the layer-1 connection to the transmission line, either an S or U
interface, and is connected to the ICC and other, peripheral modules via the IOM-2 interface.
The D channel, containing signaling data and packet switched data, is processed by the ICC
LAPD controller and routed via a parallel μP interface to the terminal processor. The high level
support of the LAPD protocol which is implemented by the ICC allows the use of a low cost
processor in cost sensitive applications.
The IOM-2 interface is used to connect diverse voice/data application modules:sources/ sinks for the D channelsources/ sinks for the B1 and B2 channels.
Figure 3
Example of ISDN Voice/Data Terminal Different D-channel services (for different SAPI’s) can be simply implemented by connecting
an additional ICC in parallel to the first one, for instance for transmitting p-packets in the D
channel.
Up to eight ICCs may thus be connected to the D and C/I (Command/Indication) channels via
the TIC bus. The ICCs handle contention autonomously.
Data transfer between the terminal controller and the different modules are done with the help
of the IOM-2 MONITOR channel protocol. Each voice/data module can be accessed by an
individual address. The same protocol enables the control of terminal modules that do not have
an associated microcontroller (such as the Audio Ringing Codec Filter ARCOFI® : PSB 2160)
and the programming of intercommunication inside the terminal. Two intercommunication
channels IC1 and IC2 allow a 2 x 64 kbit/s transfer rate between voice/data modules.
In the example above (figure 3), one ICC is used for data packets in the D channel. A voice
processor is connected to a programmable digital signal processing codec filter via IC1 and a
data encryption module to a data device via IC2. B1 is used for voice communication, B2 for
data communication.
The ICC ensures full upward compatibility with IOM-1 devices. It provides the additional strobe,
clock and data lines for connecting standard combos or data devices via IOM, or serial SLD
and SSI interfaces. The strobe signals and the switching of B channels is programmable.
Line Card ApplicationAn example of the use of the ICC on an ISDN LT + ET line card (decentralized architecture)
is shown in figure 4.
The transceivers (ISDN Cancellation Circuit IEC: PEB 2090) are connected to an Extended
PCM Interface Controller (EPIC® PEB 2055) via an IOM interface.
This interface carries the control and data for up to eight subscribers using time division
multiplexing. The ICCs are connected in parallel on IOM, one ICC per subscriber.
The EPIC performs dynamic B- and D-channel assignment on the PCM highways. Since this
component supports four IOM interfaces, up to 32 subscribers may be accommodated.
1.4.2Other ApplicationsIf programmed in non-ISDN mode, the ICC serial port B operates as an HDLC communication
link without IOM frame structure. This allows the use of the ICC has a general purpose com-
munication controller. The valid HDLC data is marked by a strobe signal on serial port B. Ex-
amples of the use of the ICC are: X.25 packet controllers, terminal adaptors, and packet trans-
mission e.g. in primary rate/ DMI systems.
1.4.3Microprocessor EnvironmentThe ICC is especially suitable for cost-sensitive applications with single-chip microcontrollers
(e.g. SAB 8048 / 8031 / 8051). However, due to its programmable micro interface and non-
critical bus timing, if fits perfectly into almost any 8-bit microprocessor system environment.
The microcontroller interface can be selected to be either of the Motorola type (with control
signals CS, R/W, DS) of the Siemens/Intel non-multiplexed bus type (with control signals CS,
WR, RD) or of the Siemens/Intel multiplexed address/data bus type (CS, WR, RD, ALE).
Figure 5
Example of ICC Microcontroller Environment
2.4.4C/I Channel HandlingThe Command/Indication channel carries real-time status information between the ICC and
another device connected to the IOM.One C/I channel conveys the commands and indications between a layer-1
device and a layer-2 device. This channel is available in all timing modes (IOM-1
or IOM-2). It can be accessed from the microcontroller e.g. to control the layer-1
activation/deactivation procedures. Access is arbitrated via the TIC bus
access protocol:in IOM-1 mode, this arbitration is done in the MONITOR channelin IOM-2 TE timing mode (SPM = 0), this arbitration is done in C/I channel 2
(see figure 11).
This C/I channel is access via register CIRR/CIR0 (in receive direction layer 1-
to-layer 2) and register CIXR/CIX0 (in transmit direction, layer 2-to-layer 1).
The code is four bits long.
In the receive direction, the code from layer 1 is continuously monitored, with an
interrupt being generated anytime a change occurs. A new code must be found
in two consecutive IOM frames to be considered valid and to trigger a C/I
code change interrupt status (double last look criterion).
In the transmit direction, the code written in CIXR/CIX0 is continuously transmitted
in the channel.A second C/I channel (called C/I1) can be used to convey real time status
information between the ICC and various non-layer 1 peripheral devices.
The channel consists of six bits in each direction. It is available only in the
IOM-2 terminal timing mode (see figure 11).
The C/I1 channel is accessed via registers CIR1 and CIX1. A change in
the received C/I1 code is indicated by an interrupt status without double
last look criterion.
2.4.5MONITOR Channel Handling
IOM®
-1The MONITOR channel protocol can be used to exchange one byte of information at a time
between the ICC and another device (e.g. layer-1 transceiver).
The procedure is as follows:
MONITOR Transmit Channel (MOX) register is loaded with the value to be sent in the outgoing
MONITOR channel. (Bytes of the form FxH are not allowed for this purpose because of the TIC
bus collision resolution procedure).
The receiving device interprets the incoming MONITOR value as a control/information byte,
FxH excluded. If no response is expected, the procedure is complete. If the receiving device
shall react by transmitting information to the ICC, it should set the E bit to 0 and send the
response in the MONITOR channel of the following frame. The ICClatches the value in the MONITOR channel of the frame immediately following a frame with=0” into MOR register.generates a MONITOR Status interrupt MOS (EXIR register) to indicate that the MOR
register has been loaded. See figure 21.
Figure 21
IOM®
-2In this case, the MONITOR channel protocol is a handshake protocol used for high speed
information exchange between the ICC and other devices, in MONITOR channel 0 or 1 (see
figure 11). In the non-TE mode, only one MONITOR channel is available (“MONITOR channel0”).
The MONITOR channel protocol is necessary (see figure 22):For programming and controlling devices attached to the IOM. Examples of such devices
are: layer-1 transceivers (using MONITOR channel 0), and peripheral V/D modules that do
not have a parallel microcontroller interface (MONITOR channel 1), such as the Audio
Ringing Codec Filter PSB 2160.For data exchange between two microcontroller systems attached to two different devices
on one IOM-2 backplane. Use of the MONITOR channel avoids the necessity of a dedicated
serial communication path between the two systems. This greatly simplifies the system
design of terminal equipment (figure 22).
Figure 22
Examples of MONITOR Channel Applications The MONITOR channel operates on an asynchronous basis. While data transfers on the bus
take place synchronized to frame sync, the flow of data is controlled by a handshake procedure
using the MONITOR Channel Receive (MR0 or 1) and MONITOR Channel Transmit (MX0 or
1) bits. For example: data is placed onto the MONITOR channel and the MX bit is activated.
This data will be transmitted repeatedly once per 8-kHz frame until the transfer is
acknowledged via the MR bit.
The microprocessor may either enforce a “1” (idle) in MR, MX by setting the control bit MRC1,0
or MXC1,0 to “0” (MONITOR Control Register MOCR), or enable the control of these bits
internally by the ICC according to the MONITOR channel protocol. Thus, before a data
exchange can begin, the control bit MRC(1,0), or MXC(1,0) should be set to “1” by the
microprocessor.
The MONITOR channel protocol is illustrated in figure 23. Since the protocol is identical in
MONITOR channel 0 and MONITOR channel 1 (available in TE mode only), the index 0 or 1
has been left out in the illustration.
The relevant status bits are:
In addition, the status bit:
MONITOR Channel Active MAC (MAC0, MAC1)
indicates whether a transmission is in progress (Register: STAR).
Figure 23Before starting a transmission, the microprocessor should verify that the transmitter is inactive,
i.e. that a possible previous transmission has been terminated. This is indicated by an “0” in
the MONITOR Channel Active MAC status bit.
After having written the MONITOR Data Transmit (MOX) register, the microprocessor sets the
MONITOR Transmit Control bit MXC to 1. This enables the MX bit to go active (0), indicating
As a result, the receiving device stores the MONITOR byte in its MONITOR Receive MOR
register and generates a MDR interrupt status.
Alerted by the MDR interrupt, the microprocessor reads the MONITOR Receive (MOR)
register. When it is ready to accept data (e.g. based on the value in MOR, which in a point-to-
multipoint application might be the address of the destination device), it sets the MR control bit
MRC to “1” to enable the receiver to store succeeding MONITOR channel bytes and
acknowledge them according to the MONITOR channel protocol. In addition, it enables other
MONITOR channel interrupts by setting MONITOR Interrupt Enable to “1”.
As a result, the first MONITOR byte is acknowledged by the receiving device setting the MR
bit to “0”. This causes a MONITOR Data Acknowledge MDA interrupt status at the transmitter.
A new MONITOR data byte can now be written by the microprocessor in MOX. The MX bit is
still in the active (0) state. The transmitter indicates a new byte in the MONITOR channel by
returning the MX bit active after sending it once in the inactive state. As a result, the receiver
stores the MONITOR byte in MOR and generates anew a MDR interrupt status. When the
microprocessor has read the MOR register, the receiver acknowledges the data by returning
the MR bit active after sending it once in the inactive state. This in turn causes the transmitter
to generate a MDA interrupt status.
This “MDA interrupt - write data - MDR interrupt - read data - MDA interrupt” handshake is
repeated as long as the transmitter has data to send. Note that the MONITOR channel protocol
imposes no maximum reaction times to the microprocessor.
When the last byte has been acknowledged by the receiver (MDA interrupt status), the
microprocessor sets the MONITOR Transmit Control bit MXC to 0. This enforces an inactive
(“1”) state in the MX bit. Two frames of MX inactive signifies the end of a message. Thus, a
MONITOR Channel End of Reception MER interrupt status is generated by the receiver when
the MX is received in the inactive state in two consecutive frames. As a result, the
microprocessor sets the MR control bit MRC to 0, which in turn enforces an inactive state in
the MR bit. This marks the end of the transmission, making the MONITOR Channel Active
MAC bit return to “0”.
During a transmission process, it is possible for the receiver to ask a transmission to be
aborted by sending an inactive MR bit value in two consecutive frames. This is effected by the
microprocessor writing the MR control bit MRC to 0. An aborted transmission is indicated by a
MONITOR Channel Data Abort MAB interrupt status at the transmitter.
2.4.6Terminal Specific FunctionsIn addition to the standard functions supporting the ISDN basic access, the ICC contains
optional functions, useful in various terminal configurations.
The terminal specific function are enabled by setting bit TSF (STCR register) to “1”. This has
two effects:The SIP/EAW line is defined as External Awake input (and not as SLD line);Second, the interrupts SAW and WOV (EXIR register) are enabled:
–SAW (Subscriber Awake) generated by a falling edge on the EAW line
–WOV (Watchdog Timer Overflow) generated by the watchdog timer. This occurs when
the processor fails to write two consecutive bit patterns in ADF1:
The WTC1 and WTC2 bits have to be successively written in the following manner within 128
ms:
As a result the watchdog timer is reset and restarted. Otherwise a WOV is generated.
Deactivating the terminal specific functions is only possible with a hardware reset.
Having enable the terminal specific functions via TSF=1, the user can make the ICC generate
a reset signal by programming the Reset Source Select RSS bit (CIX0 register), as follows:
Note: Bit RSS has a significance only if terminal specific functions are activated (TSF=1).
The RSS bit should be set to “1” by the user when the ICC is in power-up to prevent an edge
on the EAW line or a change in the C/I code from generating a reset pulse.
Switching RSS from 0 to 1 or from 1 to 0 resets the watchdog timer.
The reset pulse generated by the ICC (output via RES pin) has a pulse width of 5ms and is
an active high signal.
2.4.7Test FunctionsThe ICC provides the following test and diagnostic functions:digital loop via TLP (Test Loop, SPCR register) command bit: IDP1 is internally connected
with IDP0, external input on IDP0 is ignored: this is used in system tests, to test layer-2
functionality independent of layer 1;special loops programmed via C2C1-0 and C1C1-0 bits (register SPCR, cf. 2.4.3).
2.4.8Documentation of the Auto ModeThe Auto Mode of the ICC and ISAC-S is only applicable for the states 7 and 8 of the LAPD
protocol. All other states (1 to 6) have to be performed in Non-Auto Mode (NAM). Therefore
this documentation gives an overview of how the device reacts in the states 7 and 8, which
reactions require software programming and which are done by the hardware itself, when
interrupts and status register contents are set or change. The necessary software actions are
also detailed in terms of command or mode register access.
The description is based on the SDL-Diagrams of the ETSI TS 46-20 dated 1989.
The diagrams are only annotated by documentary signs or texts (mostly register descriptions)
and can therefore easily be interpreted by anyone familiar with the SDL description of LAPD.
All deviations that occur are specially marked and the impossible actions, path etc. are crossed
out.
To get acquainted with this documentation, first read through the legend-description and the
additional general considerations, then start with the diagrams, referring to the legend and the
register description in the Technical Manual if necessary.
We hope you will profit from this documentation and use our software-saving auto mode.
Legend of the Auto Mode Documentation
Additional General Considerations when Using the Auto Modea) Switching from Auto Mode to Non-Auto Mode.
As mentioned in the introduction the Auto Mode is only applicable in the states
7 and 8 of the LAPD. Therefore whenever these states have to be left (which is
indicated by a “Mode:NAM” text) there are several actions to be taken that could
not all be detailed in the SDL-diagrams:
a.1)write Non Auto Mode and TMD = 0 into the mode register.
a.2)write the timer register with an arbitrary value to stop it. The timer T200 as
specified in the LAPD-Protocol is implemented in the hardware only in the
states 7 and 8; in all other states this or any other timer-procedure
has to be done by the software with the possible use of the timer in
external timer mode
a.3)read the WFA bit of the STAR2 register and store it in a software variable.
The information in this bit may be necessary for later decisions. When
switching from Auto Mode to Non-Auto Mode XPR interrupts may be lost.
a.4)In the Non-Auto Mode the software has to decode I, U and S-frames
because I and S frames are only handled autonomously in the Auto Mode.
a.5)The RSC and PCE interrupts, the contents of the STAR2 register and the
RRNR bit in the STAR register are only meaningful within the Auto Mode.
a.6)leave some time before RHR or XRES is written to reset the counters, as a
currently sent frame may not be finished yet.What has to be written to the XFIFO
In the legend description when the software has to write contents of a frame to the
XFIFO only “XFIFO” is shown in the corresponding box. We shall given here a
general rule of what has to be written to the XFIFO:For sending an I frame with CMDR:XIF, only the information field content,
i.e. no SAPI, TEI, control field should be written to the XFIFO
b) For sending an U frame or any other frame with CMDR:XTF, the SAPI,
TEI and the control field has to be written to the XFIFO.The interrupts XPR and XMR.
The occurrence of an XPR interrupt in Auto Mode after an XIF command
indicates that the I frame sent was acknowledged and the next I frame can
be sent, if STAR2:TREC indicates state 7 and STAR:RRNR indicates Peer
Rec not busy. If Peer Rec is busy after an XPR, the software should wait
for the next RSC interrupt before sending the next I-frame. If the XPR hap-
pens to be in the Timer Recovery state, the software has to poll the
STAR2 register until the state Multiple Frame Established is reached or a
TIN interrupt is issued which requires Auto Mode to be left (One of these
two conditions will occur before the time T200xN200). In Non-Auto
Mode or after an XTF command the XPR just indicates, that the frame
The occurrence of an XMR interrupt in Auto Mode after an XIF command indicates
that the I frame sent was either rejected by the Peer Entity or that a collision occu-
red on the S interface. In both cases the I frame has to be retransmitted (after an
eventual waiting for the RSC interrupt if the Peer Rec was busy; after an XMR the
device will always be in the state 7). In Non-Auto Mode or after an XTF command
the XMR indicates that a collision occurred on the S interface and the frame has
to be retransmitted.The resetting of the RC variable:
The RC variable is reset in the ICC and ISAC-S when leaving the state Timer
Recovery. The SLD diagrams indicate a reset in the state Multiple Frame
Established when T200 expires. There is no difference to the outside world between
these implementations however our implementation is clearer.The timer T203 procedure:
We do not fully support the optional timer T203 procedure, but we can still find out
whether or not S frames are sent on the link in the Auto Mode. By polling the
STAR2:SDET bit and (re)starting a software timer whenever a one is read we can
build a quasi T203 procedure which handles approximately the same task. When
T203 expires one is supposed to go into the Timer Recovery State with RC = 0.
This is possible for the ICC and ISAC-S by just writing the STI bit in the CMDR
register (Auto Mode and Internal Timer Mode assumed).The congestion procedure as defined in the 1 TR 6 of the “Deutsche Bundespost".
In the 1 TR 6a variable N2x4 is defined for the maximum number of Peer Busy
requests. The 1 TR is in this respect not compatible with the Q921 of CCITT or the
ETSI 46–20 but it is, nevertheless, sensible to avoid getting into a hangup
situation. With the ICC and ISAC-S this procedure can be implemented:
After receiving an RSC interrupt with RRNR set one starts a software–timer. The
timer is reset and stopped if one either receives another RSC interrupt with a reset
RRNR, if one receives a TIN interrupt or if other conditions occur that result in a
reestablishment of the link. The timer expires after N2x4xT200 and in this case the 1
TR 6 recommends a reestablishment of the link.Dealing with error conditions: The SLD diagrams do not give a very detailed
description of how to deal with errors. Therefore we prepared a special Application
Note:
“How to deal with an error condition of the LAPD-Protocol with your ICC
or ISAC-S”
