This document explains how to upgrade E663′s and the Funkygate-IP firmwares, using the Renesas Flash Development Toolkit (FDT).

Please read the datasheet of every product for specifications and the detailed list of features.

Important disclaimer:

Please note that SpringCard is not responsible for any procedure that end user performs. Please note that not products can be recovered from improper firmware upgrade or mis-configuration !! YOU’RE FOLLOWING THIS PROCEDURE AT YOUR OWN RISK.

Getting started

Requirements

To be able to upload your firmware properly on the E663/Funkygate-IP modules, you need a computer running on Windows Xp/Vista/7. You will also need at least one working USB port and, of course, a Springcard product featuring a E663/S663 module in flash mode.

Except if the reference of your reader ends with something greater or equal to XXXX-AE, be sure to remove all power supply sources (external DC or POE) when connecting the reader to the computer through USB.

Register on Renesas Website

This registration will be necessary to download Flash Development Toolkit. Please browse to : http://www.renesas.eu/

Download and install Flash Development Toolkit

Download and installation

Once the registration is complete, you can download the  last Flash Development Toolkit “Release” (and not “update”) Version (currently v4.09) on the FDT download page:

https://www.renesas.com/en-us/products/software-tools/tools/programmer/flash-development-toolkit-programming-gui.html

You will then have to run the downloaded launcher and install FDT with all the default options.

Download latest firmware’s version

For E663/RDR (Smart Reader version, i.e. FunkyGate-IP NFC) : E663/RDR.

For E663 PC/SC (FunkyGate-IP PC/SC, TwistyWriter-IP PC/SC) : E663.

Ensure your device is ON and in Flash Mode

Make sure your device is not powered – remove Ethernet cable and shutdown DC power supply.

To enable flash mode, the switches must respect the following pattern :

  • 1 – ON
  • 2 – ON
  • 3 – OFF
  • 4 – OFF

switches_FGIP

When the switches are in correct position, connect the device to a computer’s USB port using a standard cable (mini-type B on reader side).

IMG_0066

Wait until the USB Direct driver installs automatically.

Your reader must appear as Generic boot device in the Windows’ peripheral management.

periph

If your reader does not appear in the list and if its reference ends with something greater or equal to XXXX-AE, then you have to connect it to a power supply source (external DC or POE).

Recent versions of the Funkygate do require a power supply to be flashed.

Create a new FDT firmware upgrade project

  • Launch the FDT application. A Welcome window will allow you to “Create  a new project workspace“. Click “OK” to continue.
  • New Project Workspace.
    You will have to input the “Workspace name and “Project Name” of your choice and specify a valid project directory path. Ignore “CPU familly” and click “OK” to continue.

FDT_1

  • Choose Device And Kernel.
    Select “Generic BOOT Device” at the bottom of the scroll down control and click “Next” to continue.

FDT_2

  • Communication Port. 
    On the “Select port” control, please select USB Direct and click “Next” to continue.

FDT_3

After this step a “Flash Development Toolkit” popup will appear.  Click “OK” to continue.    If at this step your device does not appear in the pop-up windows, you should check if the proper driver has been installed. FDT should have already enabled a “Generic Boot USB Direct” driver. If it is not the case, look for it when the Windows Driver installation popup appears when you connect your module in flash mode.

FDT_4

  • Select USB Device. (1 USB device located). The reader must be already selected. Click “OK” to continue.

FDT_5

FDT_6

  • After some automatic configurations, you will enter the Device Setting step. Enter “12.00MHz” for the CPU frequency, “2” for the Main Clock Frequency multiplier and “1” for the Peripheral Clock Frequency multiplier. Then click “Next” to continue.

FDT_7

  • Programming Options. Keep default settings then click on “Finish”.

FDT_8

The firmware upgrade tool configuration is now over. Select Tools >> Simple Interface to simplify the project view.

FDT_9 You can now specify the firmware binary in the “File/Image Selection” by selecting the “Download File” radio button then the “User/Data Area” checkbox and endly by clicking on the play button to browse the firmware file.

FDT_10

You can now click on “Program Flash” to load the new firmware in the reader’s flash memory and then on “Disconnect” to end the procedure.

FDT_11

Once the flash step is over, you can put your reader in play mode by setting the switches in the folowing configuration :

  • 1 – ON
  • 2 – OFF
  • 3 – OFF
  • 4 – OFF

E663_switches_play

Just press the RESET button and your reader is ready to be used!

This document explains how to upgrade the S663’s,  the Funkygate-DW’s and  the Funkycode DW‘s firmwares, using the Renesas Flash Development Toolkit (FDT).

Please read the datasheet of every product for specifications and the detailed list of features.

Important disclaimer:

Please note that SpringCard is not responsible for any procedure that end user performs. Please note that not products can be recovered from improper firmware upgrade or mis-configuration !! YOU’RE FOLLOWING THIS PROCEDURE AT YOUR OWN RISK.

Getting started

Requirements

To be able to upload your firmware properly on the S663/Funkygate-DW/Funkycode-DW modules, you need a computer running on Windows Xp/Vista/7. You will also need at least one working USB port and, of course, a Springcard product featuring a S663/Funkygate-DW/Funkycode-DW module in flash mode.

Register on Renesas Website

This registration will be necessary to download Flash Development Toolkit. Please browse to : http://www.renesas.eu/

Download and install Flash Development Toolkit

Download and installation

Once the registration is complete, you can download the  last Flash Development Toolkit “Release” (and not “update”) Version (currently v4.09) on the FDT download page:

https://www.renesas.com/en-us/products/software-tools/tools/programmer/flash-development-toolkit-programming-gui.html

You will then have to run the downloaded launcher and install FDT with all the default options.

Download latest firmware’s version

The link below will enable you to download directly the latest version of firmware: S663.

Ensure your device is ON and in Flash Mode

First you need to power up your device and plug the required serial interface. The RESET button appears on the middle right corner.

Look page 6 of this link to see how to power the device.

Link: https://files.springcard.com/pub/pmi14049-ab.pdf 

To enable flash mode, the switches must respect the following pattern :

  • 1 – ON
  • 2 – ON
  • 3 – OFF
  • 4 – OFF

Create a new FDT firmware upgrade project

  • Launch the FDT application. A Welcome window will allow you to “Create  a new project workspace“. Click “OK” to continue.
  • New Project Workspace.
    You will have to input the “Workspace name and “Project Name” of your choice and specify a valid project directory path. Ignore “CPU family” and click “OK” to continue.

FDT_1

  • Choose Device And Kernel.
    Select “Generic BOOT Device” at the bottom of the scroll down control and click “Next” to continue.

FDT_2

  • Communication Port. 
    On the “Select port” control, please select the COM port corresponding to your serial interface and click “Next” to continue.

FDT_3

  • Select Device. RX220 Series (Little Endian) must be already selected. Click “OK” to continue.

FDT_4

FDT_5

FDT_6

  • After some automatic configurations, you will enter the Device Setting step. Keep the default settings (32MHz CPU crystal frequency) and click “Next” to continue.
  • Programming Options. Keep default settings then click on “Finish”.

FDT_8

The firmware upgrade tool configuration is now over. Select Tools >> Simple Interface to simplify the project view.

FDT_9 You can now specify the firmware binary in the “File/Image Selection” by selecting the “Download File” radio button then the “User/Data Area” checkbox and endly by clicking on the play button to browse the firmware file.FDT_7

You can now click on “Program Flash” to load the new firmware in the reader’s flash memory and then on “Disconnect” to end the procedure.

FDT_8

Once the flash step is over, you can put your reader in play mode by setting the switches in the following configuration :

  • 1 – ON
  • 2 – OFF
  • 3 – OFF
  • 4 – OFF

Just press the RESET button and your reader is ready to be used! If you intend to flash your device several times, don’t forget to disconnect/reconnect after each firmware upgrade.

Using SCardControl under Linux and from a Java program

SCardControl is the PC/SC function that makes it possible for the application to invoke ‘proprietary’ functions, implemented either in the PC/SC reader itself (CSB6Prox’N’Roll PC/SCEasyFinger or CrazyWriter) , or in its driver running on the PC, or in the PC/SC middleware.

The prototype is:

LONG SCardControl(
  SCARDHANDLE hCard,
  DWORD dwControlCode,
  LPCVOID lpInBuffer,
  DWORD nInBufferSize,
  LPVOID lpOutBuffer,
  DWORD nOutBufferSize,
  LPDWORD lpBytesReturned
);

(see http://pcsclite.alioth.debian.org/api/group__API.html for the PCSC-Lite documentation, and http://msdn.microsoft.com/en-us/library/windows/desktop/aa379474%28v=vs.85%29.aspx for Microsoft’s version).

The lpInbuffer / nInBufferSize parameters hold the command buffer that will be processed by either target -reader, driver, or PC/SC middleware-.

SpringCard PC/SC Readers do provide a few ‘proprietary’ functions (called ‘Escape commands’ in the USB CCID specification). For instance, an application would send the command 58 1E 01 00 to switch the reader’s red LED ON. A question remains: what must the value of dwControlCode be, when the application wants to send the command right to the reader, bypassing both the PC/SC middleware and the driver? The answer varies with the operating system, which doesn’t help implementing portable code.

Differences between Windows and PCSC-Lite implementations

Windows

In Microsoft’s CCID driver (http://msdn.microsoft.com/en-us/library/windows/hardware/gg487509.aspx), the dwControlCode for the Escape command is defined as follows:

#define IOCTL_CCID_ESCAPE SCARD_CTL_CODE(3500)

SpringCard PC/SC Readers follow the CCID specification. SpringCard’s CCID driver (SDD480) uses the same dwControlCode as Microsoft’s.

Therefore, on Windows, the application would switch the red LED on this way:

#include <windows.h>
#include <winscard.h>

#define IOCTL_CCID_ESCAPE SCARD_CTL_CODE(3500)

(...)

const BYTE SET_RED_LED_ON[4] = { 0x58, 0x1E, 0x01, 0x00 };

SCARDCONTEXT hContext;
SCARDHANDLE hCard;
DWORD dwProtocol;
BYTE abResponse[256];
DWORD dwRespLen;
LONG rc;

(...)

/* Instanciate the winscard.dll library */
rc = SCardEstablishContext(SCARD_SCOPE_SYSTEM, NULL, NULL, &amp;hContext);
if (rc != SCARD_S_SUCCESS) { /* TODO: handle error */ }

/* Get a direct connection to the reader (we don't need a card to send Escape commands) */
rc = SCardConnect(hContext, szReader, SCARD_SHARE_DIRECT, 0, &amp;hCard, &amp;dwProtocol);
if (rc != SCARD_S_SUCCESS) { /* TODO: handle error */ }

/* Send the command */
rc = SCardControl(hCard, IOCTL_CCID_ESCAPE, SET_RED_LED_ON, sizeof(SET_RED_LED_ON), abResponse, sizeof(abResponse), &amp;dwRespLen);
if (rc != SCARD_S_SUCCESS) { /* TODO: handle error */ }

SCardDisconnect(hCard, SCARD_LEAVE_CARD);
SCardReleaseContext(hContext);

 

Important notes:

Working with MS’ CCID driver

With Microsoft’s CCID driver, the Escape feature is disabled by default.

In order to send or receive an Escape command to a reader, the DWORD registry value EscapeCommandEnable must be added and set to a non-zero value under one of the following keys.

  • HKLM\SYSTEM\CCS\Enum\USB\Vid*Pid*\*\Device Parameters (prior to Windows 7).
  • HKLM\SYSTEM\CCS\Enum\USB\Vid*Pid*\*\Device Parameters\WUDFUsbccidDriver (Windows 7 and later).

This is clearly explained in the Developer’s Manual for every PC/SC reader.

Using SpringCard’s SDD480 CCID driver shall be preferred.

Early versions of SDD480

Branch -Ax of SpringCard’s SDD480 CCID driver uses a different value for the dwControlCode parameter.

#define IOCTL_CCID_ESCAPE SCARD_CTL_CODE(2048)

Switching to the latest version of SpringCard’s SDD480 CCID driver (branch -Bx and onwards) shall be preferred.

Linux, MacOS and other Unix*

In Ludovic Rousseau’s open-source CCID driver (http://pcsclite.alioth.debian.org/ccid.html), the dwControlCode for the Escape command is defined as follows:

#define IOCTL_CCID_ESCAPE SCARD_CTL_CODE(1)

(See http://anonscm.debian.org/viewvc/pcsclite/trunk/Drivers/ccid/SCARDCONTOL.txt?view=markup for details)

Therefore, when working with PCSC-Lite, the application would switch the red LED on this way:

#ifdef __APPLE__
#include <pcsc/winscard.h>
#include <pcsc/wintypes.h>
#else
#include <winscard.h>
#endif

#define IOCTL_CCID_ESCAPE SCARD_CTL_CODE(1)

(...)

const BYTE SET_RED_LED_ON[4] = { 0x58, 0x1E, 0x01, 0x00 };

SCARDCONTEXT hContext;
SCARDHANDLE hCard;
DWORD dwProtocol;
BYTE abResponse[256];
DWORD dwRespLen;
LONG rc;

(...)

/* Instanciate the winscard.dll library */
rc = SCardEstablishContext(SCARD_SCOPE_SYSTEM, NULL, NULL, &hContext);
if (rc != SCARD_S_SUCCESS) { /* TODO: handle error */ }

/* Get a direct connection to the reader (we don't need a card to send Escape commands) */
rc = SCardConnect(hContext, szReader, SCARD_SHARE_DIRECT, 0, &hCard, &dwProtocol);
if (rc != SCARD_S_SUCCESS) { /* TODO: handle error */ }

/* Send the command */
rc = SCardControl(hCard, IOCTL_CCID_ESCAPE, SET_RED_LED_ON, sizeof(SET_RED_LED_ON), abResponse, sizeof(abResponse), &dwRespLen);
if (rc != SCARD_S_SUCCESS) { /* TODO: handle error */ }

SCardDisconnect(hCard, SCARD_LEAVE_CARD);
SCardReleaseContext(hContext);

Enabling the Escape commands

With this CCID driver, the Escape feature is also disabled by default.

You’ll have to edit the CCID driver’s Info.plist file to enable this feature:

  • Open /usr/local/lib/pcsc/drivers/ccid/Info.plist in edit mode with root priviledge,
  • Locate the line <key>ifdDriverOptions</key>,
  • The following line is typically <string>0000</string>,
  • Define the new value: <string>0001</string>,
  • Save the file and restard pcscd.

(More details on http://ludovicrousseau.blogspot.fr/2011/10/featureccidesccommand.html)

Writing portable code

The idea is only to use a #ifdef to compile the correct value:

#ifdef WIN32
#define IOCTL_CCID_ESCAPE SCARD_CTL_CODE(3500)
#else
#define IOCTL_CCID_ESCAPE SCARD_CTL_CODE(1)
#endif

Java

The javax.smartcardio API provides Java methods that are stricly bound to the underlying PC/SC subsystem. The Card.transmitControlCommand method is the wrapper for SCardControl. The prototype is coherent:

public abstract byte[] transmitControlCommand(
  int controlCode,
  byte[] command)
    throws CardException

Now the same question: what must the value of controlCode be? The answer is short: it depends on the PC/SC stack! SCARD_CTL_CODE(3500) for Windows, and SCARD_CTL_CODE(1) for PCSC-Lite. But with another difference: the macro SCARD_CTL_CODE is not computed the same way between both systems!

 

As a consequence, the Java application must detect the OS, and compute the controlCode parameter accordingly.

Same example to switch the red LED on:

import javax.smartcardio.*;

(...)

static boolean isWindows()
{
  String os_name = System.getProperty("os.name").toLowerCase();
  if (os_name.indexOf("windows") > -1) return true;
  return false;
}

static int SCARD_CTL_CODE(int code)
{
  int ioctl;
  if (isWindows())
  {
    ioctl = (0x31 < < 16 | (code) << 2);
  } else
  {
    ioctl = 0x42000000 + (code);
  }
  return ioctl;
}

static int IOCTL_CCID_ESCAPE()
{
  if (isWindows())
  {
    return SCARD_CTL_CODE(3500);
  } else
  {
    return SCARD_CTL_CODE(1);
  }
}

static final byte[] SET_RED_LED_ON = { (byte) 0x58, (byte) 0x1E, (byte) 0x01, (byte) 0x00 };

(...)

String readerName;

/* Note that the reader's name vary with the OS too!!! */
if (isWindows())
  readerName = "SpringCard Prox'N'Roll Contactless 0";
else
  readerName = "SpringCard Prox'N'Roll (00000000) 00 00";

CardTerminal terminal = CardTerminals.getTerminal(readerName);

Card virtualCard = terminal.connect("DIRECT");

virtualCard.transmitControlCommand(IOCTL_CCID_ESCAPE(), SET_RED_LED_ON);

virtualCard.disconnect(false);

Of course this code works only if the Escape feature is enable by the underlying CCID driver, as seen above.

Print and encode simultaneously using SpringCard CrazyWriter and Evolis Zenius

Evolis Zenius is a color or monochrome card printer. Evolis offers SpringCard CrazyWriter PC/SC (ISO 14443, ISO 15693 + 2 SAM) as the contactless encoding option for Zenius -as well as for the other printers in its portfolio. Zenius plus CrazyWriter makes it easy to issue personalized cards on-the-field.

In this article we’ll show how to synchronize the card encoding part (CrazyWriter PC/SC) with the card printing job using Evolis’ SDK. Our sample project (C# source code available in the PC/SC SDK, under folder /samples/dotnet/ZeniusVCard) is a real-world example: we print a business card on a Desfire EV1 smartcard, and we store a vCard object into the Desfire, following NFC Forum standard known as ‘NFC Forum Type 4 tag’. Doing so, the business card goes NFC and could be read by any compliant smartphone, that will automatically add the vCard data to its contact list! All you need to try the demo by yourself is a blank and virgin Desfire EV1 card, and, of course, an Evolis Zenius printer featuring SpringCard CrazyWriter.

In a nutshell

To print and encode a vCard, the process is as follows:

  1. Ask the printer to take one card in the feeder, and to put it in position for encoding (in front of the CrazyWriter’s antenna),
  2. Recognize the card, format it if needed, write the data,
  3. Launch the print job,
  4. Optionnaly repeat the process, until there is no card left in the feeder.

The process always encodes a card before printing it. Doing so, should any problem append (not the expected type of card, card locked read-only…), the card is ejected immediately. No time nor ribbon has been waisted printing a useless card.

Architecture

There are two ways to communicate with an Evolis printer:

  • using the Windows spooler (as with any other printer),
  • using iomem.dll, a communication library supplied within Evolis’ SDK.

Sending print jobs to the spooler is straightforward as all the steps of the printing are handled automatically by the system. Unfortunately, once the job is launched, the software has no way to know where the card actually is in the printer nor to stop it for a few seconds in front of the antenna..

On the other end, sending low level commands through iomem.dll offers a lot of flexibility, but lots of things have to be re-implemented in the printing software. This requires a specific expertise and can be time consuming.

So we’ll take the best of the two worlds: iomem.dll will be used to drive the card in the printer until the CrazyWriter has done its job, and afterwards a print job will be sent to the spooler to actually print the card. We’ll also have to use iomem.dll again to detect the end of the print job, so our software will not try to insert another card in the path until the previous card has been printed and ejected.

Step by step explanation of the sample project

Selecting the target printer and contactless coupler

The .NET PrintDialog object (System.Windows.Controls.PrintDialog) if the easiest way to select a printer. The name of the selected printer is returned in PrintDialog.PrinterSettings.PrinterName.

There’s no immediate way to know which CrazyWriter (or in general which PC/SC reader) belongs to the selected printer. So we display our common ‘Select PC/SC Reader’ dialog to let the user find the reader. Default is to select the contactless interface of the first available CrazyWriter.

Controlling the printer through iomem.dll

First step is to gain access to iomem.dll‘s entry points from our C# application. The function used are:

  • OpenPebble
  • ClosePebble
  • ReadPebble
  • WritePebble
  • GetTimeout
  • SetTimeout


Please refer to Evolis’ SDK for a detailed documentation of the DLL.

OpenPebble(PrinterName) gives use access to the printer, we then can use the couple WritePebble/ReadPebble to send arbitrary commands to the printer -and wait for its answer.

Here are the 3 only commands we need:

  • Rlr;h to check whether the feeder is empty,
  • Sic to load a card from the feeder, and to move it into position for encoding (in front of the CrazyWriter’s antenna),
  • Se to eject the card (in case the encoding has failed).

If the encoding is successful, sending a print job to the spooler is enough to make the printer take the card from its current position (in front of the antenna), print it, and eject it.

To know whether the print job is terminated or still pending, we’ll use a very simple trick: as the printer is not available to answer to iomem.dll commands while it is under control of the system’s spooler, we’ll send repeated dummy commands, and we’ll know that the job is ended when we’ll get an answer at last. The dummy command is:

  • Rfv read firmware version

Please also refer to Evolis’ SDK for details regarding the printer’s command set.

Encoding the vCard on the contactless card

This part is shared with the vCard part of NFCTool, another of our samples. The only difference is that NFCTool can also read cards, and implements a ‘wake up on card arrival’ scheme that doesn’t have to be implemented in this sample. The card ‘arrives’ only after a successful invocation of the “Sic” control command.

We start by opening a PC/SC channel to the card: scard = new SCardChannel(ReaderName) (see the documentation of our PC/SC for .NET API for details).

Then we use the methods of our NfcTag object (NfcTag.IdentifyTagType, NfcTag.BackgroundRecognize) to check whether the card is a NFC Forum tag or not. It must be either already formatted (and offering enough memory space to store the vCard) or a Desfire EV1 that we know how to format and write. Note that BackgroundRecognize, as the name says, performs the recognition in a background thread and invoke a callback function once done. This is generally speaking a good practice to implement card-related stuff in a background thread so the application’s window remains ‘alive’ even if the card takes its time to answer. At this step, the card is now for sure compliant with NFC Forum type 4 specification (or has been ejected if not, or if the user has chosen not to overwrite existing data).

Eventually, a new NfcVCard object is created, populated with the data entered by the user, and inserted as the content of the NfcTag objet. The the NfcTag.BackgroundWrite method is called, so the vCard content goes actually into the card. Once again this is done in a background thread.

Printing the layout on the card

At the end of the writing (that takes no more than one second anyway), the callback that is invoked launches the print job.

To print our business card, we process as follow:

  1. Create a PrintDocument object (System.Drawing.Printing.PrintDocument),
  2. Add to this PrintDocument object a PrintPageEventHandler function that will be invoked to actually draw the layout,
  3. Code the PrintPageEventHandler to implement the drawing of the business card from the data entered by the user,
  4. Invoke the PrintDocument.Print() method to send it to the spooler.

In this example, the PrintPageEventHandler is implemented in the FormatBusinnessCard function. The name and the title are printed in the middle of the card, respectively in Arial 16 and Arial 14; the contact information (business phone and e-mail) are in the down-left corner in Arial 10; the picture is printed in the up-right corner; etc… Of course this is the first thing you’ll have to change to design your cards according your own layout.

Waiting for the end of the job

Once PrintDocument.Print() has been called, there’s nothing else to do but wait. The spooler works in background, so the application is free to do anything else, but we can’t start encoding another card until the current one has been printed and ejected. Therefore we implement a waiting loop, sending the “Rfv” command through iomem.dll repeatedly. Once the printer responds, we know that the job is over. We could then loop to go on with the next card.

SpringCard CSB6 Family is a group of contactless smartcard readers, offering various functions and three different operating modes : PC/SC (CCID), Legacy (virtual communication port), RFID scanner (keyboard emulation). All these products share a common hardware platform, based on the same microcontroller. This document explains how to upgrade the firmware, using the flash upgrade software provided by the manufacturer of the microcontroller.

At the date of writing, this document refers to the four products in the CSB6 Family :

  • CSB6,
  • Prox’N’Roll (all version),
  • CrazyWriter,
  • EasyFinger.

Please read the datasheet of every product for specifications and the detailed list of features.

For the Prox’N’Roll you can also look at this vidéo:

Important disclaimer:

Please note that SpringCard is not responsible for any procedure that end user performs. Please note that not products can be recovered from improper firmware upgrade or mis-configuration !! YOU’RE FOLLOWING THIS PROCEDURE AT YOUR OWN RISK.

Getting started

The microcontroller used by SpringCard CSB6 Family is Renesas H8S/2212UF. This microcontroller is upgradeable on the field, through its USB link, thanks to the software ‘Flash Development Toolkit’ (FDT) version 4 or newer, provided by Renesas.

FDT works on 32-bit versions of Windows 2000/XP/Vista/7. You can’t use in on a 64-bit machine. There’s no equivalent tool for other operating systems.

Locate and download the firmware for your device

PC/SC (and Legacy)

The firmware files for PC/SC (and Legacy) products are located under https://files.springcard.com/firmwares/springprox/. The subdirectories are named after the version (for instance https://files.springcard.com/firmwares/springprox/1-70 stores all the firmware in the 1.70 branch).

In the subdirectories, the files targeting this family of products are named 2212_rc632_(product name and code)_(product version).mot. Always check that the product name and code field matches the product you actually have.

RFID Scanner

The firmware files for RFID Scanner products are located under https://files.springcard.com/firmwares/iwm2_scan/. The subdirectories are named after the version (for instance https://files.springcard.com/firmwares/iwm2_scan/1-40 stores all the firmware in the 1.40 branch).

In the subdirectories, the files targeting this family of products are named 2212_rc632_(product name and code)_rfid-scanner_(product version).mot. Always check that the product name and code field matches the product you actually have.

Quickly download latest firmware’s version

The links below will enable you to download directly the latest version of each firmware :

Important disclaimer:

Generally speaking, putting the wrong firmware in any product is possible, and may appear to work, but this is not the way the product is intend to operate. Please make sure to always put the appropriate firmware in the actual product you have. Flashing a PC/SC reader with a RFID Scanner firmware (and vice versa) is not supported.

Download and install Renesas FDT

Latest version of FDT is available free of charge at Renesas’ :

  • Go to www.renesas.com .
  • Navigate to Development Tools & Flash and PROM Programming & Flash Development Kit.
  • Choose « Download the latest version of FDT free of charge ».

You’ll be prompted for your company details before accessing the download.

Note : Renesas’ web site changes frequently, and its URLs are not « user friendly », therefore preventing us to give the actual link here.

Alternatively, we provide for convenience download FDT 4.09 (R03) at https://files.springcard.com/misc/fdtv409r03.exe but please check whether a newer version has been made available at Renesas’.

Create a workspace

Launch FDT from Start Menu.

Choose « create a new project workspace », and click « OK ».

FDT Start Menu

Enter a name for your new project workspace (for instance, CSB6 Family), and click « OK ». If left blank, the project name defaults to the same value as the workspace name.

WorkSpace Name

Enter 2212U in the filter field, and choose H8S/2212UF in the list. Click « Next » to continue.

Kernel Selection.

Choose port « USB Direct », and click « Next ».

Port selection

In the following pages, click « Next » (leaving all options to their default value), until « Finished ».

Add a firmware to your workspace

In the tree on the left, right click on the project. Then, in the popup menu, click on « Add Files… »

Adding Firmware to WorkSpace

Browse to the firmware file you want to download in the product (firmware files have the « .mot » extension).

You may later on add other firmware files to your project if you have different products or if you re-use the same project with a future version.

Put the device in flash upgrade mode

Every product in the CSB6 Family has either a switch or a push-button to go to the firmware upgrade mode.

All products but Prox’N’Roll

CSB6, CrazyWriter and EasyFinger have 4 configuration switches. Switch number 2 is devoted to firmware upgrade.

Unplug your device.

Open the casing (CSB6 and EasyFinger: there are a few PZ3 screws to unscrew).

Note the current position of the switches.

Move all the switches to ON.

4 switchs ON

Plug the device to the computer’s USB port again. For EasyFinbger, plug the external power supply as well.

The device is now enumerated as an “USB Direct” device and handled by the driver that has been installed together with FDT.

Prox’N’Roll (prior to version EAN8I9P-FD)

Warning

The top sticker (lexan) must be removed in order to unscrew the cover, before being able to access the firmware upgrade switch. As the sticker is glued, this is likely to destroy it. Please contact our sales team should you need to buy spare stickers.

You’ll have to insert a sharp blade (cutter) under the sticker to remove it. PLEASE BE CAREFUL NOT TO GET HURT.

Opening Tools

Unplug your Prox’N’Roll.

Remove the top sticker.

Removing Top Sticker

Use your stanley knife carefully.

Stanley Knife

There’s a PZ3 screw underneath the sticker.

Main Screw

Unscrew the main screw.

Unscrewing

You now have access to the PCB. There’s only one switch (with a blue body), the firmware upgrade switch.

Opened Prox'N'Roll

Move the switch to the ON position.

switch ON

Plug the Prox’N’Roll to the computer’s USB port again. It is now enumerated as an “USB Direct” device and handled by the driver that has been installed together with FDT.

Prox’N’Roll (new versions after EAN8I9P-FD)

The new version of Prox’N’Roll has got a push-button. This button is accessed via a tiny hole hidden under the reader’s bottom label. You need a paper clip to push the button and don’t have to open the reader.

Unplug your Prox’N’Roll.

If you manage to sense the hole through the bottom label, you may insert the paper clip through the label. Overwise, remove the bottom label using a stanley knife.

Removing Rear Sticker

Underneath the label, you find a tiny hole.

Tiny hole

Insert a paper-clip in the hole and push firmly until you feel or hear the button. Keep the button pressed.

paperclip pushing button

While keeping the button pressed, plug the Prox’N’Roll to the computer’s USB port again. It is now enumerated as an “USB Direct” device and handled by the driver that has been installed together with FDT. Once the driver is loaded (this may take up to 30 seconds on the first time, but normally less than 5 seconds afterwards) you may depress the button, removing the paper-clip from the hole.

Load the firmware into the device

Back to FDT screen, right-click on the file you want to load in the device.

Downloading File

In the popup menu, click « Download File ».

FDT now prompts you to select the target USB device. If you’ve plugged only one product at a time, there must be only one target!

Choosing target

Select the only target, and click « OK ».

Wait during the flash operation (this takes 20 to 60 seconds).

Flashing

When done, FDT displays this message:

Flash completed

Terminate the procedure by clicking « Disconnect » in the « Device » menu.

Disconnect

Put the device back in operation mode

All products but Prox’N’Roll

Put back the switches in the position you’ve noted in before flashing.

4 switch off

Unplug/plug the device again.

Help with switch position
  • Switch 1 must always be ON
  • Switch 2 must be OFF for normal operation
  • Switch 3 must be ON for USB-powered devices (no external power supply) and OFF for devices that have an external power-supply (EasyFinger for instance).
  • Switch 4 must be OFF for normal operation. Set it to ON only when instructed to do so by SpringCard’s support or R&D team.

Prox’N’Roll (prior to version EAN8I9P-FD)

Move the switch back to the OFF position.

switch OFF

Close the casing and put the sticker back in position.

Closing Prox'N'Roll

Screwing

Top Sticker Back

Unplug/plug the device again.

Prox’N’Roll (new versions after EAN8I9P-FD)

Unplug/plug the device again (without the paper-clip).

Optional step

It’s possible, for example if your product’s LEDs are RED that you need to follow an additional step to configure your product. See this page for more information.

If you’ve flashed a Prox’N’Roll RFID Scanner with a PC/SC firmware, or vice-versa a Prox’N’Roll PC/SC with a RFID Scanner firmware, the device will not run as expected until the firmware has been correctly configured. Until so, the firmware is in ’emergency’ mode, seen on the USB as a virtual communication port (USB CDC-ACM profile). You need to install the corresponding driver in order to access the device through a terminal program (HyperTerminal for instance) to be able to configure it.

Make sure your PC runs a 32-bit version of Windows

The driver is not WHQL-certified, therefore it can’t be installed on any 64-bit version of Windows. Should you need help there, we do support only Windows XP Pro 32 bits.

Download and install sdd470 driver

Download SDD470 driver setup.

Install the driver.

Go to Control Panel, Device Manager, and check that your device is now seen under “Communication ports”. Note the COM number that has been assigned to it by the system.

Launch HyperTerminal

Connect to the COM port you’ve identified in the device manager, using the following configuration:

  • 38400bps,
  • 8 data bits,
  • 1 stop bit,
  • no parity,
  • no flow control.

Once connected, enter “info” to check that you have the correct firmware (“Prox’N’Roll RFID Scanner” in one case, “CSB6 Prox’N’Roll” in the other).

If you need a replacement for Hyper Terminal, you can use Putty.

First command

From firmware version 1.56 (for the Prox’N’Roll) the first command you type in your Hyper Terminal session needs to start by an escape char. So for example, if your first command is info, you need to type

^info and not info

Set the new configuration

  • Enter “cfgC0=02” to put the firmware “CSB6 Prox’N’Roll” into PC/SC mode
  • Enter “cfgC0=03” to put the firmware “Prox’N’Roll RFID Scanner” into keyboard emulation mode

Check configuration

Close HyperTerminal (important !!!).

Unplug the device.

Plug the device again.

Check in Device Manager:

  • The PC/SC reader is listed under “Smartcard readers”
  • The keyboard emulation reader is listed under “Human interface devices”

Windows 7 complains on missing driver for smartcards – a practical workaround

Smartcards and smartcard-aware applications using application level commands (APDUs) are older than Windows and worked very well in the past, until Microsoft suddently decided that a smartcard shouldn’t be handheld directly by the applications anymore, and introduced the concept of smartcard driver software (ICC Service Provider withing the PC/SC framework). This issue sometimes occurs with our products in the SpringCard CSB6 Family (CSB6Prox’N’Roll PC/SCEasyFinger and CrazyWriter) and our NFC readers/encoders (H512NFC’Roll).

With Windows Seven, Microsoft goes one step further and mandates that every smartcard has its own driver (a ‘minidriver’ actually, i.e. a DLL running in user mode and not a SYS binary running in kernel mode). Everytime you put a smartcard on a contactless reader, or in a contact reader, the system tries to locate the appropriate driver, and this generally ends up with a red mark in the tray bar and this annoying message in the tray bar : “Device driver software was not successfully installed. Click here for details.” Luckily, smartcard-aware applications keep on working as usual on top of PC/SC API, thanks to classical SCardConnect / SCardTransmit function calls.

According to Microsoft, smartcard-issuers should provide a minidriver for their cards. The point is, the ICC Service Provider architecture is meaningfull to let security-sensitive applications access security features (digital signature, secure login) in an interoperable and high-level way, but it appears useless in other cases, when only one single software has to communicate with a single smartcard. And this is the case in 99% of the systems using contactless smartcards or contactless memory cards.

A techninal article has been published in Microsoft Knowledge base (http://support.microsoft.com/kb/976832/en-us) giving different solutions to prevent the system from looking for a driver and issuing the warning message. In this article we are detailing two solution :

  • 1st solution is to disable SmartCard PnP feature through a Group Policy. The side effect is that there’s not choice but to disable this feature for every cards, not only for the one that do not have a minidriver,
  • 2nd solution is to write in the system registry the list of cards that will not have a minidriver. In this article we do this through a small utility that makes it easier than entering the required lines in the registry one after the other.

Using a Group Policy to disable the smartcard PnP feature

Just follow this five steps :

  1. Run MMC.exe (Microsoft Management Console)
  2. Add Group Policy snap-in to the console
  3. Open Local Computer
  4. Browse to Policy\Computer Configuration\Windows Settings\Administrative Templates\Windows Components\Smart Card
  5. Disable Turn On Smart Card Plug And Play Services.

Command-line utility to selectively disable some smartcard minidrivers

The principle is to register in the system registry the ATRs of every smartcard we don’t want to go through the PnP feature, and to associate them to a dummy minidriver.

Here’s the technical part (details are to be found in MS’ reference article (http://support.microsoft.com/kb/976832/en-us),

  1. Create a branch under HKLM\Software\Microsoft\Cryptography\Calais\Smartcards, name the branch with any clever name that will describe the related smartcard
  2. In this branch create a REG_BINARY entry named ATR in which you put the smartcard’s ATR
  3. Create a REG_SZ entry named Crypto Provider and put the value $DisableSCPnP$ in it.

You may also add a REG_BINARY entry named ATRMask to associate this entry with more than one ATR. In the ATRMask, bits set to 1 means that the bits in ATR are relevant, and bits set to 0 act as wildcards.

 

A sample source code to do so is provided by MS’ with the article. We’ve  implemented this source code in a small command line tool, and added a lot of modifications to ease its use and to make it possible to disable smartcard PnP for any arbitrary-entered smartcard ATR, and not only for the smartcards physically inserted in the readers at the time of execution.

There are two binaries : pcsc_no_minidriver32.exe for 32-bit systems, and pcsc_no_minidriver64.exe for 64-bit systems. Invoke either software with the -h parameter to get help. With the -m parameter, the software starts monitoring all the PC/SC readers. For every card inserted, it disables the plug and play. Alternatively, the -a parameter let you specify the ATR (hexadecimal string) ; you may optionally use the -n parameter to specify a name for your smartcard (this is convenient if you want to remove it from the registry later on !).

Note, you must run this program as an administrator.

We supplied the software with 2 command line scripts (.CMD),

  • pcsc_no_minidriver_memory.cmd disables every memory card (ATR constructed according to PC/SC v.2 specification for memory cards)
  • pcsc_no_minidriver_well_known.cmd disables  some well-known contactless cards that do not have a minidriver (NXP Desfire, NXP Mifare Plus, various Calypso cards, …).

Of course, use this software and the related scripts with care and make sure you really do understand what it does, as it may prevent your system to work correctly with your 20$-cryptographic card that do need its minidriver to work with CryptoAPI.

Here’s the link to the package : http://www.springcard.com/download/pub/pcsc_no_minidriver.zip . It comes with complete source code. Just unzip in a local folder and enjoy.

Mifare Plus in a nutshell

Following the breakdown of Mifare Classic security, NXP has released a new generation of contactless cards to fill the gap, the Mifare Plus. To ease the migration of the existing applications, this new chip keeps the memory model of the Mifare Classic : the card is structured as an array of 16-byte blocks, and the blocks are grouped into sectors of 4 or 16 blocks. The security (authentication and access control) is done on a per-sector basis. The two benefits of Mifare Plus are its new security scheme (EAL 4+ certified), based on state-of-art AES cipher with 128-bit keys, and its optional Random-ID for ISO 14443-3 anti-collision, useful to address card-holder-privacy concerns.

Type X or type S

Mifare Plus comes in two types.

Mifare Plus X is the full-featured product, allowing end-to-end AES-ciphered communication and a so-called ‘Proximity Check’ feature that makes it possible to prevent relay attacks, by measuring precisely the time elapsed between reader’s commands and card’s answers.

The command set of Mifare Plus X includes a function to select one-out-of-many Mifare Plus ‘Virtual Cards’ that could be emulated by a single NFC device.

Mifare Plus S is a lightweight version of the product, optimized to be a cost-effective drop-in replacement for Mifare Classic. It doesn’t support the ‘Proximity Check’ and has only limited support for the ‘Virtual Card’ scheme. More than that, it doesn’t support the Security Level 2 (see below).

Security Levels

The Mifare Plus has four different modes of operation, known as ‘Security Level’ 0, 1, 2 and 3. The Security Level is a static parameter of the card, the reader application can’t decide to operate the card arbitrary at one security level or at the other, it must operate the card given the card’ Security Level . Using a specific AES-secured exchange, the application may switch the card from one Security Level to a higher one, but this operation is not reversible (it is impossible to go from one Security Level to a lower one).

Security Level 0 is the out-of-factory configuration. In this mode, the card is not secured at all, and even not usable to store data.  Before all, the AES keys to be used all among the card’s life-cycle must be loaded, and the card must be switched to a higher Security Level. Pay attention that all the AES keys are transmitted in plaintext, so it is very important to do this personalization step in a trusted environment.

In Security Level 1, the Mifare Plus emulates a plain-old Mifare Classic. This gives the opportunity to replace existing Mifare Classic cards without the need to replace the readers or the handler applications. But as the card keeps on using the broken CRYPTO1 cipher, the security of the system is not better…  Yet an optional AES-based 3-pass authentication makes it possible to check whether the card is a real card and not an emulator, but per-se it doesn’t protect the data from unauthorized reading or modification.

In Security Level 2, the Mifare Plus uses the CRYPTO1 stream cipher just as Mifare Classic, but instead of using static 6-byte Mifare keys, the keys are generated dynamically by an AES-based 3-pass authentication. This is said to combine the security of AES with ‘the speed of CRYPTO1’. Anyway, in a typical architecture, the CRYPTO1 is implemented in the reader (by the NXP RC chipset actually) where AES is implemented in software on a very fast host computer. The gain in speed of ciphering remains small towards the overall bandwidth of the card-to-application channel; it may even be not significant enough to balance the added exchanges (loading of the CRYTO1 key into the reader after every AES authentication).  Also, the Mifare Plus S doesn’t support the Security Level 2.

In Security Level 3, the Mifare Plus doesn’t use CRYPTO1 anymore, but only AES. The new features (optional Random-ID, Virtual Card, Proximity Check) are available only at this Level.

Note that in Level 0 as in Level 3, communication is standard-compliant (ISO 14443-4 “T=CL”) where Security Levels  1 and 2 uses legacy Mifare frames (ISO 14443-3 type A).

Compliance between SpringCard contactless readers and Mifare Plus

Whatever the Security Level, all SpringCard contactless readers are fully able to communicate with the Mifare Plus chips (anti-collision loop and retrieval of UID, ISO 14443-3 A or ISO 14443-B communication protocols).

In Security Level 1 and 2, as the Mifare Plus’ UID is 7-byte long where the UID of a Mifare Classic is only 4-byte long, an upgrade had to be written in the CRYPTO1 authentication algorithm. This is available in firmware version 1.51 and newer. Earlier versions must be upgraded to be able to read and write data on a Mifare Plus at Level 1 or Level 2.

Using the card in Security Level 1 means only calling some functions embedded in the reader (Mifare Classic function set), but the other Security Levels  involve a new function set (AES authentication, ciphering and MACing, read and write commands on top of T=CL) that has to be implemented in the host computer. This requires a major redesign of the host applications. If the host is a microcontroller with limited resources, adding support for Mifare Plus could be difficult or even impossible without changing the hardware.

SpringCard APIs for Mifare Plus

As is has already been done for Desfire and Mifare UltraLight C, SpringCard has developed a convenient software library to ease the development of applications using Mifare Plus cards. This library is available as both as source code and as binary in the latest SDKs (PC/SC and SpringProx Legacy), together with a small sample software that shows how to personalize the card in Level 0, to change the Security Level (0 to 1, 1 to 2 or 3, 2 to 3) and to operate the card in Security Level 3, including

  • AES authentication (and generation of the session keys for ciphering and MACing)
  • Read and write functions with various options
  • Virtual Card feature

When the card is at Security Level 1, the existing samples for Mifare Classic could be used unchanged. The Security Level 2 is not implemented, as it isn’t available in Mifare Plus S that is expected to be the most frequently chosen one.

Documentation of the API is available online :

Choosing between Mifare Plus, Desfire EV1 or Mifare UltraLight C

The NXP Mifare family has now 3 contactless smartcards using ‘modern’ cryptography schemes for improved security.

Desfire EV1 is a full-featured microcontroller-based card, featuring 3DES and AES cryptography, a structured memory model (files within directories), and partially compliant with smartcard-standards (ISO 7816-4). Available capacities are 2KB, 4KB or 8KB.

Mifare UltraLight C is a low-cost wired-logic card with only 140 bytes of memory (the typical target is the market of disposable contactless tickets). A single 3DES key makes it possible to ensure that the card is genuine.

Just in-between, the Mifare Plus has a flat memory model (blocks) but with a good isolation between sectors,  2KB or 4KB of storage, and AES cryptography. The key advantage is the memory mapping that is the same as Mifare Classic, so existing applications that store data in the cards may be upgraded without major changes in their logic (yet changes in the security scheme and in the command set are not trivial…). But on the other hand, if the only need is to have a serial number or to store a small amount of data, Mifare UltraLight C does the job perfectly and is cheaper. As for Desfire EV1, its compliance to 7816-4 standard is the key in interoperable schemes (including future uses of NFC phones to emulate contactless cards), where the two other products remain totally proprietary.

Java + PC/SC = accessing smartcards from a web page

The Java Smartcard I/O API (javax.smartcardio, JSR 268) introduced in Java 1.6 is the bridge between PC/SC readers and the Java world. Java-based applications and applets may now communicate with smartcards in an interoperable and portable way. This makes it possible for web pages to access data stored in smartcards, or to invoke services running in a smartcard (either running a JavaCard cardlet or whatever native card application).

An interesting extension of this technique would be the ability for  JavaScript to access the smartcards as well. JavaScript is not Java: Java code is compiled into bytecode, then translated into native code and executed by the computer’s Java Virtual Machine (JVM). JavaScript is interpreted ‘on-the-fly’ by the browser’s JavaScript engine. This would open new opportunities for developers to build quickly and easily smartcard-aware web-based applications purely in HTML+JavaScript.

It is not difficult to implement such a bridge between HTML+JavaScript and smartcards, creating a GUI-less Java applet that will translate JavaScript function calls into calls to javax.smartcardio methods. There are two technical aspects that must be mastered to do so:

  • The applet has to be signed, as the smartcard is a critical computer’s resource, not immediately available to the applets running in the sandbox,
  • The applet has to be scriptable, in order to expose itself to JavaScript through functions and events. But scriptable and signed applets normally mandate signed JavaScript, something we want to avoid to remain ‘easy’.

We’ve written a small yet precise HOWTO that explains the whole process of developing such an applet. You may download it here.

Following this HOWTO, a sample applet has been developed and signed for demos and tests. You can test it online here (the applet is signed with our certificate ‘www.springcard.com’. You must accept the signature, otherwhise you will be able to list the readers but not to connect to the cards).

You can develop this type of solution with our products in the SpringCard CSB6 Family (CSB6Prox’N’Roll PC/SCEasyFinger and CrazyWriter) and our NFC readers/encoders (H512NFC’Roll).

Mifare is out of 32-bit IDs

NXP Semiconductors has recently warned their customers that they are running out of unique IDs for the Mifare Classic family. A detailed application note is also available to give precize answers to technical questions.

Since the beginning, every card in the Mifare Classic family (1k, 4k, Mini) has a 32-bit identifier, said to be unique (4-byte UID according to ISO 14443-3 A standard). The reader uses this identifier to “see” and to select the card (anticollision + activation loop). Afterwards, the reader’s Crypto1 engine also has to know this identifier in order to perform the mutual authentication, to gain read or write access on card’s data.

Theoretically, 32 bits would mean that 4.2 billion cards coul’d be issued with different IDs (4 294 967 296 exactly). But as some values have been reserved or assigned by ISO to different uses, only 3.7 billion unique IDs were practically available. Therefore, NXP expects to run out of unique identifiers for Mifare Classic by the end of 2010.

Fortunately, ISO 14443 standard allows longer IDs: either 7-byte IDs (“cascade level 2”, widely used for years, by Mifare UltraLight and Desfire for instance) or 10-byte IDs (“cascade level 3”, but with no practical example at the date of writing). To overcome the 32-bit limit, NXP will introduce a new generation of Mifare Classic cards using 7-byte IDs. As a consequence, applications working with card IDs may have to be updated to accept longer numbers.

All SpringCard readers, whatever the version, support the whole ISO 14443 standard, including 7- or 10-byte IDs. But the Crypto1 authentication scheme has to be slightly updated to support the longer ID. In our contactless products (SpringProx, CSB, Prox’N’Roll, etc), this is implemented since version 1.51. Therefore, customers that need to read/write new Mifare Classic cards having 7-byte IDs (as well as Mifare Plus) shall make sure that their products run firmware 1.51 or newer.