Smart card and pic programming

[Warren Thai]

Hi all,
I'm planning to do some experimentation on pic programming and smart cards.
This link refers to what product I'm talking about.
http://www.jaycar.com.au/products_uploaded/ZZ-8800.pdf
I am just looking for some tips, links to tutorials, suggestions, guidelines
etc that other people may have who may also have experience in this topic.
As far as I understand, you are meant to write a program that goes into the
16F84 in the smart card and this program acts as a 'firmware'. You then use
this 16F84 and firmware to access data in the 24LC16B eeprom. Is what I just
stated correct? or is it done differently?
My other question is, say if I made a device that reads and writes to the
smart card eeprom, does my device need to provide a seperate clock (from a
crystal for example) for the clock of the smart card? or should I generate a
clock with the microcontroller in my device.
Anyway, any useful comments, suggestions, answers to questions etc would be
most helpful.
Thanks
-Warren

 

[Palindrome]

Hi all,
I'm planning to do some experimentation on pic programming and smart cards.
This link refers to what product I'm talking about.
http://www.jaycar.com.au/products_uploaded/ZZ-8800.pdf
I am just looking for some tips, links to tutorials, suggestions, guidelines
etc that other people may have who may also have experience in this topic.
As far as I understand, you are meant to write a program that goes into the
16F84 in the smart card and this program acts as a 'firmware'. You then use
this 16F84 and firmware to access data in the 24LC16B eeprom. Is what I just
stated correct? or is it done differently?
My other question is, say if I made a device that reads and writes to the
smart card eeprom, does my device need to provide a seperate clock (from a
crystal for example) for the clock of the smart card? or should I generate a
clock with the microcontroller in my device.
Anyway, any useful comments, suggestions, answers to questions etc would be
most helpful.

If you are unfamiliar with PICs, you may want to start with a PIC
development system, which will include tutorials building up from
scratch to a thorough understanding. I can recommend:

http://www.quasarelectronics.com/3081.htm

Once you have that understanding, you will need to develop or buy a
smartcard programmer. If you develop your own, it has to provide all the
interface signals, with the correct timing (including power on timing)
specified by the standard:

http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816.aspx

Here is a suitable programmer:

http://www.maxking.com/programmers.htm


Basically, you follow much the same routine for program development for
the smartcard as you do for the tutorial kit. The programmer will take
care of all the clocks and interface signals needed.

The result will be a programmed smart card - which will start processing
whenever it is placed in a smart card reader.

Going from zero to a programmed smart card produced in your own designed
programmer is a leap too far for most.

 

[Warren Thai]

Thanks for the input.
I already have experience with pic programming so I feel confident that I
can do this. All I want to do is experiment with smart cards as a challenge
and a hobby. My aim is to program a microcontroller (just call it A) that
will connect to the smartcard (call the smart card microcontroller B) and
read and write to its EEPROM memory. I'm thinking I will have to write a
program to micro B that will use asynchronous serial transfer with one of
its portb pins to input and output data. Micro B will operate as a
'middleman' between micro A and the EEPROM in the smartcard. So a 'firmware'
needs to be written for micro B. Do others usually design their own firmware
and communication protocol or do they usually use a set standard? This is
where I am confused about. The smart card programmers out in the shops don't
actually read or write to the EEPROM do they? I'm guessing they write the
firmware and a different device is required to communicate with the smart
cards firmware to read and write to the EEPROM.
I'm also confused about the clock. Say I make a device with micro A. In this
device I can connect a smart card. Then micro A can communicate to micro B
and read/write the EEPROM. When the smart card is connected to the device, I
want to know what clock source do I use for the smart card? Do I use a
separate crytal oscillator?
Thanks again for the input.
-Warren

 

[Palindrome]

Thanks for the input.
I already have experience with pic programming so I feel confident that I
can do this. All I want to do is experiment with smart cards as a challenge
and a hobby. My aim is to program a microcontroller (just call it A) that
will connect to the smartcard (call the smart card microcontroller B) and
read and write to its EEPROM memory. I'm thinking I will have to write a
program to micro B that will use asynchronous serial transfer with one of
its portb pins to input and output data. Micro B will operate as a
'middleman' between micro A and the EEPROM in the smartcard. So a 'firmware'
needs to be written for micro B. Do others usually design their own firmware
and communication protocol or do they usually use a set standard? This is
where I am confused about. The smart card programmers out in the shops don't
actually read or write to the EEPROM do they? I'm guessing they write the
firmware and a different device is required to communicate with the smart
cards firmware to read and write to the EEPROM.
I'm also confused about the clock. Say I make a device with micro A. In this
device I can connect a smart card. Then micro A can communicate to micro B
and read/write the EEPROM. When the smart card is connected to the device, I
want to know what clock source do I use for the smart card? Do I use a
separate crytal oscillator?

OK. What a smartcard programmer does is first to load a special program
into the PIC, called a bootloader. It does that in much the same way as
any pic is programmed.

Once the bootloader is in place, it is run, allowing the programmer
access to read and write to the EEPROM (via the PIC, of course).

The final step it that the PIC code is overwritten by the operational
PIC code. At which point the EEPROM cannot be accessed by the programmer
- unless the operational code allows it. eg the operational code may
contain debug routines which are essentially the routines contained in
the bootloader.

Most people just buy a smartcard programmer - which comes with a
bootloader for each of the cards supported.

You can, of course, write your own bootloader. It would typically take
and parse text strings from the programmer.
eg

REB 032F - which equates to READ_EEPROM_BYTE address 032F

If you write your own you can do things that the standard bootloader
will not - eg read and write ASCII character mapping blocks.


You are correct that the smartcard EEPROM cannot be read or written
directly by the programmer - it uses the PIC running the bootloader.
However, that is only of academic interest as the programmer will
normally do all of this transparently - so it appears that the EEPROM is
being directly addressed.

The clock is external. It is provided by the programmer, when being
programmed, and by the smartcard reader, when in normal use.

The ISO reference that I provided gives full details of what is
acceptable as a clock signal - plus what is required for all the other
signals.

 

[Warren Thai]

Sorry to ask this again, perhaps my question wasn't clear. If a designed a
device containing a microcontroller. Noting just a general device and not
refering to a programmer. This device has one job to read and write to a
smart card's eeprom via the smartcards 16F84. What clock should be connected
to the smart card when it is connected to my device? I hope my question isnt
confusing.

 

[Palindrome]

Sorry to ask this again, perhaps my question wasn't clear. If a designed a
device containing a microcontroller. Noting just a general device and not
refering to a programmer. This device has one job to read and write to a
smart card's eeprom via the smartcards 16F84. What clock should be connected
to the smart card when it is connected to my device? I hope my question isnt
confusing.

The question isn't confusing but it is hard to make the answer simple.
The complete answer is given in the ISO reference. A very much
simplified answer is that the clock needs to have an even mark-space
ratio with a frequency between 1-5 MHz.

However the clock frequency is also constrained by a parameter called
the etu, and has to be 372/etu.

The etu is basically the width of a transmission bit.

So, you start with the Baud rate that you intend to use when
communicating with the card. That determines the etu. That determines
the clock frequency.

So, let's say that you were using 9600 Baud. That gives a transmission
bit width of 104 uSec. Which gives an etu of 104 uSec. Which gives a
clock frequency of 372/104 = 3.577MHz.

I hope that is the answer that you were looking for.

 

[Warren Thai]

That was a helpful post. However I'm sorry to say that my question was
actually talking about the physical clock. That is (refering back to this
'device' i would supposedly design) would I use the device micro to generate
the clock signal for the smart cart micro? Or should I have the smart card
micro clock input connected to RC oscillator? Because the smart card micro
will need a clock source otherwise the micro won't do anything. I ask
because with the smart card I have in mind, the internal connections between
the micro and the smart card terminals gives access to only OSC1 of the
micro so then you cannot use say a crytal oscillator which requires OSC1 and
OSC2 pins. So my real question is when I design a device to interface the
card (not a programmer so not connected to computer) how do you provide the
clock signal to run the smart card micro?

 

[Palindrome]

That was a helpful post. However I'm sorry to say that my question was
actually talking about the physical clock. That is (refering back to this
'device' i would supposedly design) would I use the device micro to generate
the clock signal for the smart cart micro? Or should I have the smart card
micro clock input connected to RC oscillator? Because the smart card micro
will need a clock source otherwise the micro won't do anything. I ask
because with the smart card I have in mind, the internal connections between
the micro and the smart card terminals gives access to only OSC1 of the
micro so then you cannot use say a crytal oscillator which requires OSC1 and
OSC2 pins. So my real question is when I design a device to interface the
card (not a programmer so not connected to computer) how do you provide the
clock signal to run the smart card micro?

You appear to have answered your own question... The smartcard is not
involved in generating the clock. Your external device(whether it be a
programmer or cardreader) has to generate it.