Teridian Semiconductor Corporation makes no warranty for the use of its products, other th an expressly
contained in the Company’s warranty det ai l ed i n the Teridian Semiconductor Corporation standard Terms
and Conditions. The company assumes no resp onsibility for any errors which may appear in t hi s
document, reserves the right to change device s or specifications detailed herein at any t i m e without
notice and does not make any commitment to update the information contained herein. Accordingly, the
reader is cautioned to verify that this document is current by comparing it to the latest ver sion on
http://www.teridian.com or by checking with your sales representative.
Teridian Semiconductor Corp., 6440 Oak Canyon, Suite 100, Irvine, CA 92618
TEL (714) 508-8800, FAX (714) 508-8877, http://www.teridian.com
2 Rev. 1.00
UG_12xxF_029 73S1215, 73S1217F DFU Host Driver/Application Development User’s Guide
UG_12xxF_029 73S1215, 73S1217F DFU Host Driver/Application Development User’s Guide
USB - CCID
USB - DFU
DFU
Driver
CCID
Driver
C#
App
Boot
Loader
CCID
App
TSC
Libraries
Host Controller73S12xxF Device
1 Firmware Upgrade Architecture
This document describes the Teridian USB (DFU class) Interface. Figure 1 shows the flow of this
architecture.
The firmware architecture in this document is a single-threaded C program using the API services as
detailed in the 73S12xxF Smart Card Terminal Controller Family Software User’s Guide.
software is compiled and linked using the Keil µVision3 development software. The functiona l areas of
the firmware and driver are divided into module s as shown below.
The Windows XP Kernel mode DFU driver was dev eloped using Microsoft Device Driver Developm ent Kit
(DDK) Version (3790.1830) Windows Server 2003.
The User Interface Application used for testing both the CCID and DFU driver was developed using
Microsoft Visual Studio 2008 C# programming language. The USB-DFU driver and USB-CCID have the
file names TSCDFU.sys and CCIDDFUTSC.sys respectively.
The
Figure 1: DFU and CCID Class Interface Architecture
The 73S12xxF Device side Boot Loader and CCID Application (or any application) are tightly coupled and
co-exist together but only one module will be executed at any t im e. Which module is invoked is
determined by a common ‘Check Code’. A ‘Check Code’ is a two-byte signature with the predefined
unique value of
the Application Code section (0x1800 and 0x1801) and the highest two bytes of the Application Code
section (0xFFFC and 0xFFFD). At Power On, the Boot code begins with a verification of this Check
Codes. If the Check Code in the Boot Code section (0x1800) matches the Check Code in the Applicati on
Code section (0xFFFC), it will then begin to execute the Application Code. If the Chec k Co des do not
have the same unique value, it will wait for a USB Reset to start the DFU Class Device enumeration and
then begin the Firmware Upgrade programming.
0x875A
that resides at two places within Flash pr ogram space: the lowest two bytes of
Rev. 1.00 5
73S1215, 73S1217F DFU Host Driver/Application Development User’s Gui de UG_12xxF_029
2 DFU – Phases of Operation
The USB Device Firmware Upgrade Specificat i on Revision 1.1 identified four distinctive phases of
operation:
1. Enumeration Phase
2. Reconfiguration Phase
3. Transfer Phase
4. Manifestation Phase
This user guide describes the IOCTLs as supported by Teridian’s CCID-DFU driver and DFU driver.
2.1 Enumeration Phase
The specific driver being installed is dependent on the Firmware’s Device Class type provided as part of
the enumeration. If the firmware’s DFU Boot Loader code is running, the DFU driver will be inst al led. If
the firmware’s CCID code is running, the CCID driver will be installed. Refer to the 73S1215F, 73S1217F Boot Loader – DFU Class Firmware Application Note for details of this phase of operation. No DFU’s
IOCTL are exposed by the CCID driver during this phase.
2.2 Reconfiguration Phase – Detach CCID Class/Attach DFU Class
There are two distinctive steps to transit i on and complete a successful reconfiguration phas e: Detaching
the CCID Class Device and Attaching the DFU Cla ss Device. Section 2.2.1 describes the methods of
detaching the CCID Class Device. Review the 73S1215F, 73S1217F Boot Loader – DFU Class Firmware Application Note for firmware’s behavior when these commands are processed.
2.2.1 Detaching the CCID Class Device
Once the USB-CCID driver (ccidDFUtsc.sys) is loaded successfully, at anytime the host may start
detaching the USB-CCID driver by one of two ways: USB-CCID’s Escape Command or DFU_Detach
Request. After successful execution of ei ther of these two commands, the CCID driver will be detac hed
and loading of the DFU driver will begin.
When the driver receives this IOCTL it will send an Escape command to the device. Review Section
5.2.4 of the 73S1215F, 73S1217 CCID Application Note f or m ore details of this function.
2.2.1.2 DFU Detach Request
IOCTL : #define IOCTL_DFUTSC_DFU_DETACH SCARD_CTL_CODE(2100)
IN : not required
OUT : not required
RETURN: NTSTATUS
Supported driver : ccidDFUtsc.sys, tscdfu.sys
When the driver receives this IOCTL, it sends a DFU_DETACH Class Specific Request to the device.
Review the 73S1215F, 73S1217F Boot Loader – DFU Class Firmware Application Note for firmware’s
behavior when, and after, this command is executed.
6 Rev. 1.00
UG_12xxF_029 73S1215, 73S1217F DFU Host Driver/Application Development User’s Guide
2.2.2 Attaching the DFU Class Device
Upon receiving escape command or dfu_detach, f i rmware boots up in DFU mode. This time USB-DFU
driver (TSCDFU.sys) will be loaded by operating system (if driver is already installed, otherwise a new
hardware found wizard will pop up by Windows). See the 73S1215F, 73S1217F Windows XP 32 USB CCID and DFU Drivers Installation Guide on how to install drivers. USB-DFU driver (TSCDFU.sys) will
enumerate the firmware for DFU class.
2.3 Transfer Phase – Flash Programming
During the transfer, the Boot Loader will proces s a tight loop to collect DFU_DNLOAD packets f rom the
host. Upon receiving the first
erased. Note: the firmware will need about 2.3 seconds to erase the whole 58K of Flash. It is
recommended that the host/driver allow the firmware ample time to complete this task after the first Intel
record. Thereafter, from the second record on, each record is written as soon as it is received.
After each downloaded block, the host solicits the dev i ce st atus with the DFU_GETSTATUS request. In
order to speed up the firmware programming proc ess, the Boot Loader Code will accept DFU_ DNLOAD
packets in sequential order without the need t o get (and report to) a DFU_GETSTATUS request in
between DFU_DNLOAD packets. When the last record of the file (record type = 0x01 indicating an End
of File record) is received by the firmware, it will wait for a DFU_DNLOAD packet of zero length before it
transitions to the Manifestation Phase.
valid Intel Hex record
2.3.1 DFU Download Request
IOCTL : #define IOCTL_DFUTSC_DFU_DNLOAD SCARD_CTL_CODE(2101)
IN : input (request) buffer length
IN : input (request) buffer
OUT : not required
RETURN: NTSTATUS
Supported driver : tscdfu.sys
Driver tscdfu.sys exposes this IOCTL_DFUTSC_DFU_DNLOAD to transfer (new) firmware file (Intel
record/hex format only) to the device. The Intel hex record has to be parsed by the host application.
Host appication should send each record in the “input buffer” with the “input buffer length ”. Once the
driver/tscdfu.sys receives this IOCTL with data, it will transfer the data to the device. Upon completion, the
driver returns NTSTATUS to the host application.
2.3.2 DFU Get Status Request
IOCTL : IOCTL_DFUTSC_DFU_GETSTATUS SCARD_CTL_CODE(2103)
IN : input (request) buffer length (size 6)
IN : input (request) buffer (of 6 bytes)
OUT : output(response) buffer length
OUT : output(response) buffer
RETURN: NTSTATUS
Supported driver : tscdfu.sys
Driver tscdfu.sys exposes this IOCTL_DFUTSC_DFU_GETST A T US to facilitate synchronization with the
device. The driver tscdfu.sys expects 6 bytes of input/output buffer. The firmware responds with status
data in 6-byte buffer. The driver fills the inf orm ation returned by the firmware in the output buffer and
sends it back to the host application. Refer to Section 6.1. 2 of the USB Devi ce Class Specification For Device Firmware Upgrade, Revision 1.1 (DFU Class Specification) for interpretation of the 6-byte status
returned by firmware/driver to the host applicat i on.
, the entire Application Code section of Flash will be
Rev. 1.00 7
73S1215, 73S1217F DFU Host Driver/Application Development User’s Gui de UG_12xxF_029
2.3.3 DFU Clear Status Request
IOCTL : IOCTL_DFUTSC_DFU_CLRSTATUS SCARD_CTL_CODE(2104)
IN : not required
OUT : not required
RETURN: NTSTATUS
Supported driver : tscdfu.sys
Any time the firmware detects an error and reports an error status to the host in the response to a
DFU_GETSTATUS request, it enters dfuERROR state. The firmware cannot by itself transition from the
dfuERROR state. It is the host application/driver’s responsibility to clear an error st ate by sending a
DFU_CLRSTATUS request.
The host application shall send IOCTL_DFUTS C_DFU_CLRSTATUS to the driver tscdfu.sys. T he driver,
in turn, sends the DFU_CLRSTATUS command to the firmware. Upon receipt of DFU_CLRSTATUS, the
firmware sets its status to OK and transitions to the dfuIDLE state.
2.3.4 DFU Get State Request
IOCTL : IOCTL_DFUTSC_DFU_GETSTATE SCARD_CTL_CODE(2105)
IN : input (request) buffer length (size 1)
IN : input (request) buffer (of 1 byte)
OUT : output(response) buffer length
OUT : output(response) buffer
RETURN: NTSTATUS
Supported driver : tscdfu.sys
This request solicits a report about current state of the firmware. The state reported is t he current state of
the firmware with no change in state upon transmission of the response. The values specified in the
output buffer field are identical to those report ed in DFU_GETSTATUS
2.3.5 DFU Abort Request
IOCTL : IOCTL_DFUTSC_DFU_ABORT SCARD_CTL_CODE(2106)
IN : not required
OUT : not required
RETURN: NTSTATUS
Supported driver : tscdfu.sys
The DFU_ABORT request enables the host to exit from certain states and return to the DFU_IDLE state.
The firmware sets the OK status on receipt of this request. See the 73S1215F, 73S1217F Boot Loader – DFU Class Firmware Application Note for more information on the firmware’s behavior.
2.4 Manifestation Phase – Device Restart
Read the 73S1215F, 73S1217F Boot Loader – DFU Class Firmware Application Note for details of this
phase’s operations. There is no IOCTL for t his phase.
8 Rev. 1.00
UG_12xxF_029 73S1215, 73S1217F DFU Host Driver/Application Development User’s Guide
3 Miscellaneous Features
3.1 Boot Loader and CCID Application Firmware Version Number
#defineIOCTL_DFU_GET_BLFW_VER SCARD_CTL_CODE(3501)
IN : not required
OUT : output buffer length (size 4 bytes)
OUT : output buffer (of 4 bytes)
RETURN: NTSTATUS
Supported driver : ccidDFUtsc.sys, tscdfu.sys
The USB-CCID driver ccidDFUtsc.sys provides one IO control call IOCTL_DF U_GET_BLFW_VER to the
upper layer application program. When the driver receives this IOCTL, it sends a request to the boot
loader firmware via Standard Device Reque st to Get String Descriptor from the firmware.
The firmware responds with 4-byte string: [B oot Loader Major Number], [Boot Loader Minor Number],
[The last CCID Application Major Number], [The last CCID Application Minor Number].
4 Related Documentation
The following 73S12xxF documents are available from Teridian Semiconductor Corporation:
71S1215F Data Sheet
71S1217F Data Sheet
73S12xxF Smart Card Terminal Controller Family Software User’s Guide
73S12xxF Evaluation Board User’s Guide
Teridian Flash Programming Tool
73S1215F, 73S1217F Boot Loader – DFU Class Firmware Application Note
73S1215F, 73S1217F Windows XP 32 USB CCID and DFU Drivers Installation Guide
5 Contact Information
For more information about Teridian Semiconductor products or to check the availability of the 73S12xxF,
contact us at:
6440 Oak Canyon Road
Suite 100
Irvine, CA 92618-5201