parallax Smart Card Reader

be80be

Can any one till me more about the Smart Card Reader is it more or less just a case that the card slide in and
six or so pins that contacted the Smart card and are then run out to a 12 pin header basically and maybe a pull up on the
IO lines. But no on board Ic chips. Thanks for any info.

Franklin

Have you read the documentation? www.parallax.com/Portals/0/Downloads/docs/prod/rf/32320-SmartCardReader-v1.0.pdf

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Stephen

be80be

Yes I read the to whole 2 pages. I was looking for a little more details but I would say I covered most it has 8 pins that brake out the
header and gives you 6 of them to work with thanks for the reply

Pilot

be80be,

I have just started playing with the reader. I am using the 32320 reader with the 32321 card.

Here are a few observations:
1. The 4442.bs2 code from the file 32320-SCRBS2Code.zip does not fit in my Homework board (revB). The 32321-ISCSC4442_Demo.bs2 code from 32321-ISCSC4442_Demo.zip does fit.

2. I claim the connections shown in 32320-SmartCardReader-v1.0.pdf do not agree with with the code in 32321-ISCSC4442_Demo.bs2. I chose to modify the code to match the pdf.

3. After modifying the code, I was able to successfully read, authenticate, write, and read a byte of data to address 0x40. However when I removed and reinserted the card it failed to authenticate. Additional experimentation locked one of my two 32321 cards. A repeat with a second card (that was never used when the reader and code wiring disagreed) has used one of the three failed authentications.

Below is a virgin read, I hope it is of some help
'

---

[ DATA ]

---

'Addr. *0 *1 *2 *3 *4 *5 *6 *7 *8 *9 *A *B *C *D *E *F
'____________________________________________________________________________________
'0* | A2 13 10 91 FF FF 81 15 FF FF FF FF FF FF FF FF
'1* | FF FF FF FF FF D2 76 00 00 04 00 FF FF FF FF FF
'2* | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
'3* | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
'4* | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
'5* | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
'6* | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
'7* | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
'8* | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
'9* | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
'A* | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
'B* | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
'C* | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
'D* | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
'E* | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
'F* | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
'____________________________________________________________________________________

I hope to continue debug of this problem, hopefully without locking up my last card, If I learn anything new I will try to post it here. Perhaps others have already run into these problems?

These type of issues are not that big a deal, but they are less than what I have come to expect from the hard working people at Parallax, please remember this is newly released product.

Pilot

Pilot

be80be,

I think I have uncovered a little more of the puzzle, Note the proper Compare subroutine sequence is on page 16 of the IS23SC4442_Datasheet.pdf.

I claim the following: In the code 32321-ISCSC4442_Demo.bs2

When doing a validation (#2 from the main memory)
subroutine Authenticate: is called
subroutine Authenticate calls Subroutine Compare:
subroutine Compare: sets the variable dat to 0x00 and then calls Read_security:
When the Read_Security: subroutine is called the 1st time it will return four bytes of 0x00's (see p11 of IS23SC4442_Datasheet.pdf) The variable errCounter is set to the 1st of these four bytes so errCountert is now at 0x00.

After returning from the Read_security subroutine, Compare: now does three If statements based on errCount to set dat for the Update security command.
IF(errCounter = %111) THEN dat = %011
IF(errCounter = $011) THEN dat = $001
IF(errCounter = $001) THEN dat = $000

errCount = 0x00 is not one of the three tests so dat remains at 0x00!

The Update security command now writes the chips error counter to %000 which is the value for the last try (should be 011 for the 1st try). This means that if for some other reason the sequence on p16 fails we are now locked out of the card.

Also note the misuse of the use of the hex base when the binary base was obviously desired for the 2nd and third if lines.

I claim one possible solution to the code could be:
IF(errCounter = %000) THEN dat = %011 ' 1st time Read_security returns 0x00
IF(errCounter = %111) THEN dat = %011 ' validation called a 2nd time no errors
IF(errCounter = %011) THEN dat = %011 'validation selected with 1 error
IF(errCounter = %001) THEN dat = %000 'validation selected with 2 errors

Of course this failure sequence would not show up in nominal testing, without a failure (probably caused by my removal and reinsertion of the card) the sequence on p16 resets the chips error Counter (not to be confused with the programs variable errCounter) to %111 and we still have a non-locked card.

I was unable to debug why removal and reinsertion of the card caused the failure before I locked my second and last card.

I hope this is of some help to you.

Perhaps it is time for Parallax to comment on the validity of my claims made here.

Pilot

be80be

Thanks for the info I haven't tried any code. I was looking for more info about how the reader was made if it had pullups on the pins. I made my own reader and was thinking this would be a good start at learning how it all works

Pilot

Some more notes for anyone following me.

I claim:

1. The 32321-ISCSC4442_Demo.bs2 also has commented out the part of the the sequence on p16 that resets the chips error Counter so it seems to me this code is destined to lock up the card.
' Command=UpdateSecurity ' Erase Error Counter
' Address=$00
' Dat=$07 ' If password match then the counter restore
' GOSUB Send_Command
' GOSUB Process

2. I also experimented with the 32323 card. Both the 32323-IS24C02_Demo.bs2 and the IS24C02.bs2 code work, but again you need to get the pin declarations to match how 32320-SmartCardReader-v1.0.pdf suggests you hook up the card. (a symptom of leaving the original pin declarations is that the CD will be detected without a card in the reader.)

3. I also experimented with the 32322 card. Both the 32322-IS24C16A_Demo.bs2 and the IS24C16.bs2 code work, but again you need to get the pin declarations to match how 32320-SmartCardReader-v1.0.pdf suggests you hook up the card.

The 32322 card has what ISSI (IS24C16A-Datasheet.pdf) calls multiple blocks of 256 bytes each. The 32322-IS24C16A_Demo.bs uses the concept of pages for access to different pages. The IS24C16.bs2 seems to treat all the blocks as contiguous memory unfortunatly the address are in decimal.

4. I seem to be missing the documentation that shows how the ISSI chips' pins are connected (if at all) to the smartCard contacts and the smartCard reader pins. It would be nice if the use of WP and the A[0:2] lines described in the ISSI documentation (IS24C16A-Datasheet.pdf) was documented.

Pilot

be80be

You been working thanks for the info I know the pin hook up for the reader the cards I have
may be locked I haven't read them I was waiting till I get blank cards