I can\'t find anywhere a valid APDU list for SLE5542 smartcard. Actually I found this: http://www.acs.com.hk/drivers/eng/PMA_ACR38x(CCID)_v6.01.pdf but it\'s not working.
You are in the dark, I've had similar problems with the 5528/4428 the documents are not always matching the real world. sometimes you will find two or three versions for the same card, while each suggesting different APDU sets and each will be correct or wrong in several of them. it's not going to be a fun entry into this domain. other times the documents won't reveal to you some missing detail from the connection procedure. which means that you probably won't be able to establish connection half of the time. but then if you look at the code samples in the SDK you suddenly see what you acutely have to do...
As for the SDK... you can buy SDK for the ACS reader/Card you are planning to learn. don't get me wrong, it's not that the SDK is written very well either. in fact, often you won't even be able to compile some of the code samples unless you fix some syntax errors. and even after you got trough that, sometimes there are bugs in the code samples.
One more thing, I wouldn't bet on their tech support, you'll get almost automated response which usually makes no sense at all. although they've changed the contact person now, perhaps you will have more luck then I had.
The good news are that once you got it working, it will likely do good in production.
The SLE5528 and 4428 are no SMARTcards, just dumb (synchronous) memory chips supporting the 3-wire protocol if I remember correctly. So they send no ATR and do not understand APDUs. Instead they understand just three hardwired commands: read, write (both operating with offsets) and PIN verify. The offset starting from which writing requires previous PIN entry can be configured. Unfortunately PCSC gives no support addressing stuff like this. There is a reader-independent interface called CT-API (somewhat popular in mid-90s in Germany to address health insurance cards, but possibly nearly extinguished since), but it is reader-dependent and must be provided by the reader manufacturer. Confusingly it also has an APDU-like command/response structure, but this is converted by the driver/reader to low-level hardware operation. This also explains, why the APDU list is so difficult to get: the chip itself has none. This question has a good answers, which might help further.
The link you provided is valid and the APDU commands are valid too , may be you have missed something in the implementation, please notice that before you can proceed with any command you have first to select the card by using the following command:
FF A4 00 00 01 06
this should return 90 00
if the selection succeeded.
then you can use the command for reading the data from the card
FF B0 00 XX YY
XX represent the location which should be > 32 and <256
YY represent the length of the data to be read and this should return the data and 90 00
if the read process succeeded.
to write data to the card you need to submit the secret code , the default secret code is FF FF FF
by using this command
FF 20 00 00 03
so the command for submitting the secret code will be FF 20 00 00 03 FF FF FF
then you can write data using this command:
FF D0 00 XX YY data
where XX is the location of the address in the card where you want to write the data and YY is the length of the data and data is the data to be written
you can use the other commands in the document as you need in the same way
Note : all the code commands should be in Hex
format , the data , the memory location ..etc
I just found some info that may be useful: http://flylogic.net/docs/sle4442.pdf