...the world's most energy friendly microcontrollers
2014-01-23 - an0820_Rev1.00
15
www.silabs.com
3.4 Typical Transaction Sequences
To further understand the typical communication pattern between both the PC and the CCID and
between the CCID and the smart card, it helps to look at how the transaction sequences play out
over time. This section has a couple of example-sequences indicating the difference between the
APDU- and TPDU-exchanges. Notice that all of these sequences follows the T=0 protocol. Also note
that the transaction diagram on the USB-side is simplified to only show the APDU-content of the
PC_to_RDR_XfrBlock USB-BulkOut messages, in addition these USB-messages actually contains a
fixed-length header-field with message-type, sequence numbering, status-bytes and so forth.
3.4.1 Sending Data to Card
When the host has data it wants to write to the smart card, it sends an APDU with data appended after
the mandatory CLA,INS,P123-header. The CCID sends first only the header to the smart card, it then
waits for a procedure byte, indicating what further action the CCID should take. See state-diagram in
Figure 3.4 (p. 14) for how the send-APDU function is implemented in the EFM32-based CCID.
If the procedure byte indicates that the smart card is ready to receive data, the CCID proceeds with
sending the data to the smart card. It then waits for a further procedure byte. Note that in the case
of successful transaction, the procedure byte is in fact the SW1-character and therefore part of the
response expected from the host. The CCID fetches the SW2 character as well and sends both SW1
and SW2 back to the host. See Figure 3.5 (p. 15) for an example-transaction of this sequence.
Figure 3.5. Host Sends Data to Card
DATA
Procedure
byt e
Host - PC
Sm art Card
EFM32
CCID
Reader
7816- 3, T= 0 Prot ocol
USB
CLA INS
P1
P2
P3
SW1 SW2
CLA INS
P1
P2
P3
DATA
SW1 SW2
3.4.2 Receiving Data from Card
When the host has data it wants to read from the smart card it sends an APDU containing just a header,
which the CCID forwards directly to the smart card. The CCID must interpret the content of the APDU
to know that it is supposed to read data from the smart card and how many bytes it is supposed to
read. The CCID then waits for a procedure byte, and if indicating a data transmission the smart card
proceeds to send data after that the procedure byte. At the end of the data, the two status bytes, SW1
and SW2 are appended.
The CCID-response to the host is the data it received and the SW1 and SW2 bytes appended to the
end of the data. Figure 3.6 (p. 16) illustrates this smart card read transaction.
Summary of Contents for EFM32
Page 27: ......
