Bull TLP3—Smart Card Driver

SUMMARY

This driver is used for the Bull TLP3 serial smart card reader. Do not confuse this Plug and Play smart card reader with the Bull CP8 smart card reader, which looks quite similar.

This driver implements Plug and Play and Power Management.

 

BUILDING BULLTLP3.SYS

To build the Bulltlp3.sys driver, select either the checked or free DDK environment, change to the directory Bulltlp3, and type build. This driver uses services provided by the smart card driver library (Smclib.sys), which are explained in detail in the accompanying documentation.

To install the driver, plug the reader into a serial port, start the Device Manager (right-click My Computer, select Properties, select the Hardware tab, and click Device Manager) and scan for hardware changes from the View menu. The Found New Hardware wizard will appear. You will need to provide the .inf file (on a floppy disk) and the driver file, which will be copied to your System32\Drivers directory. The driver will start automatically. To stop the driver, either unplug the reader or select the appropriate taskbar icon.

Note: Unlike PCMCIA, the serial port was never designed for hot-plugging, so the driver will not unload automatically. To trigger unload of the device, in Device Manager, select Scan for hardware changes. Also, the driver will not unload as long as you have Ifdtest.exe running and connected to the driver.

 

Tools

Microsoft offers a test tool (Ifdtest.exe) that allows you to use a smart card reader directly from the command line. Normally, the smart card resource manager is connected to a reader. To use Ifdtest.exe, you must stop the smart card resource manager (Scardsvr.exe). Type net stop scardsvr in the command line. Ifdtest.exe is also used for the smart card reader logo test.

Ifdtest.exe can be downloaded from http://www.microsoft.com/hwtest (follow the links for smart cards). You need to order special test smart cards to get your smart card reader logo'ed. Ordering information can be found at the URL above.

 

RESOURCES

ISO 7816 Part 3 describes smart cards and smart card protocols in detail. Refer to the PC99 Handbook for smart card reader requirements.

The document Plug and Play External COM Device Specification describes the requirements for serial device Plug and Play, and can be downloaded from http://www.microsoft.com/hwdev/respec/pnpspecs.htm

 

CODE TOUR

File Manifest

 
Files         Description
BULLTLP3.HTM  The documentation for this sample (this file).
SOURCES       The generic file for building the code sample.
MAKEFILE      Makefile required to build the driver.
MAKEFILE.INC  Additional makefile required to build the driver.
BULLTLP3.INF  The .inf file for installing the code sample.
TLP3NT.C      The main source file.
TLP3CB.C      Source file containing the callback functions for the smart card library.
BULLTLP3.H    Data definitions for the driver.
TLP3LOG.MC    Error messages.
BULLTLP3.RC   The resource file for the driver.
 

Programming Tour

The major topics covered in this tour are:

T=1 data transfers

The Bull TLP3 reader does not have firmware that handles the low-level protocols. The T=0 and T=1 protocols are implemented in software. The T=0 implementation is done in the driver, and the T=1 protocol is implemented in the smart card library. The driver should not decide whether to cancel an unsuccessful transfer. Only the smart card library—which implements the functions SmartcardT1Request() and SmartcardT1Reply()—should decide when to abort a transmission. Even if the driver does not receive any data from a smart card, the driver must pass this result to the smart card library. For more details, see TLP3Transmit().

Plug and Play

Unlike the PCMCIA bus, the serial port was never designed for hot-plugging and device detection. So you can plug or unplug a device while the system is running, but there is no real hardware support for detection of a device. However, there is software support that implements serial device detection. It can be used in two ways:

  1. Scan for hardware changes in Device Manager, as described previously.
  2. Enable serial polling.

Both methods use a filter driver (Serenum.sys) that implements serial Plug and Play. Serenum.sys sits on top of the serial driver and "watches" the serial port actively by changing the control lines according to the serial Plug and Play specifications mentioned above.

However, both methods do not support device removal detection. Once the driver opens a connection to a serial port, it "owns" the port. Serenum.sys can’t monitor for device removal, because that would interfere with the smart card driver. This means that the smart card driver needs to do the work. The function TLP3SerialEvent() is called whenever either the card status changes (insertion or removal) or the reader has been unplugged. Unplugging the reader inserts a work queue item that triggers a function that closes the connection to the serial driver (it sends an IRP_MN_CLOSE). Once the serial driver has been closed, the serial enumerator can do its work again and start calling the device removal code of the smart card driver.

Power Management

The driver that knows most about the connected device is considered the power policy owner of a device stack. This is the case for a smart card reader driver. It has to translate system power state changes into device power state changes. The system sends a system power message to the stack, and the smart card driver translates this message into a device power message. The system can distinguish several states like Sleeping 1 (low power) or Sleeping 2 (even lower power), but the Bull TLP3 reader can’t. So the power management code translates all system power states to two different device power states, which are D0 (full power) or D3 (off), depending on the system power type. The code TLP3Power implements the power management.

In addition, one thing is specific to smart card readers: how to deal with smart card insertions/removals while the system is in standby or hibernation mode. Your reader won’t see any card insertion or removal events in these modes, because the bus might not even have power. So you need to save the card state before your reader goes into standby/hibernation mode. After the system comes back from these modes, you need to determine what the state of the card is. You need to complete card tracking calls whenever there was a card in the reader before standby/hibernation mode or whenever there is a card in the reader after these modes. This is necessary because the user could have changed the card while the system is in a low-power mode.

 

Top of page

© 1998 Microsoft Corporation