Datasheet
73S1215F Data Sheet DS_1215F_003
78 Rev. 1.4
1.7.15.1 ISO 7816 UART
An embedded ISO 7816 (hardware) UART is provided to control communications between a smart card
and the 73S1215F MPU. The UART can be shared between the one built-in ICC interface and the
external ICC interface. Selection of the desired interface is made by register SCSel. Control of the
external interface is handled by the I
2
C interface for any external 8010 devices. The following is a list of
features for the ISO 7816 UART:
• Two-byte FIFO for temporary data storage on both TX and Rx data.
• Parity checking in T=0. This feature can be enabled/disabled by firmware. Parity error reporting to
firmware and Break generation to ICC can be controlled independently.
• Parity error generation for test purposes.
• Retransmission of last byte if ICC indicates T=0 parity error. This feature can be enabled/disabled by
firmware.
• Deletion of last byte received if ICC indicates T=0 parity error. This feature can be enabled/disabled
by firmware.
• CRC/LRC generation and checking. CRC/LRC is automatically inserted into T=1 data stream by the
hardware. This feature can be enabled/disabled by firmware.
• Support baud rates: 230000, 115200, 57600, 38400, 28800, 19200, 14400, 9600 under firmware
control (assuming 12MHz crystal) with various F/D settings
• Firmware manages F/D. All F/D combinations are supported in which F/D is directly divisible by 31 or
32 (i.e. F/D is a multiple of either 31 or 32).
• Flexible ETU clock generation and control.
• Detection of convention (direct or indirect) character TS. This affects both polarity and order of bits in
byte. Convention can be overridden by firmware.
• Supports WTX Timeout with an expanded Wait Time Counter (28 bits).
• A Bypass Mode is provided to bypass the hardware UART in order for the software to emulate the
UART (for non-standard operating modes). In such a case, the I/O line value is reflected in SFR
SCCtl or SCECtl respectively for the built-in or external interfaces. This mode is appropriate for
some synchronous and non T=0 / T=1 cards.
The single integrated smart card UART is capable of supporting T=0 and T=1 cards in hardware
therefore offloading the bit manipulation tasks from the firmware. The embedded firmware instructs the
hardware which smart card it should communicate with at any point in time. Firmware reconfigures the
UART as required when switching between smart cards. When the 73S1215F has transmitted a
message with an expected response, the firmware should not switch the UART to another smart card
until the first smart card has responded. If the smart card responds while another smart card is selected,
that first smart card’s response will be ignored.
1.7.15.2 Answer to Reset Processing
A card insertion event generates an interrupt to the firmware, which is then responsible for the
configuration of the electrical interface, the UART and activation of the card. The activation sequencer
goes through the power up sequence as defined in the ISO 7816-3 specification. An asynchronous
activation timing diagram is shown in Figure 17. After the card RST is de-asserted, the firmware instructs
the hardware to look for a TS byte that begins the ATR response. If a response is not provided within the
pre-programmed timeout period, an interrupt is generated and the firmware can then take appropriate
action, including instructing the 73S1215F to begin a deactivation sequence. Once commanded, the
deactivation sequencer goes through the power down sequence as defined in the ISO 7816-3
specification. If an ATR response is received, the hardware looks for a TS byte that determines
direct/inverse convention. The hardware handles the indirect convention conversion such that the
embedded firmware only receives direct convention. This feature can be disabled by firmware within
SByteCtl register. Parity checking and break generation is performed on the TS byte unless disabled by
firmware. If during the card session, a card removal, over-current or other error event is detected, the
hardware will automatically perform the deactivation sequence and then generate an interrupt to the
firmware. The firmware can then perform any other error handling required for proper system operation.