On Wed, Jul 7, 2010 at 12:09 PM, Sébastien Lorquet <[email protected]> wrote: > Hi, > > APDU cases are deeply linked to T=0. In T=1, you don't need anything like > this, because the block length is sent in the block header, before the block > data, so the peers know the data length. > > So I think the exchange transparency should be done at a higher level. > > In case 2, just send the 5-bytes apdu you get, do not change Le (P3) > In this case, P3=Le=00 accounts for 256 bytes to be responded. > > Then, switch to receive mode. > > If the length is correct and accepted by the card, the card will answer INS > then the proper number of data bytes and SW. you do not need a timeout. if > the procedure byte is INS, the length you requested is valid and you will > get that many bytes - plus final SW. > > If the length is not correct, the card will ALWAYS reply an error or > warning, be it 61XX, 6CXX, or anything else. you also know that you just > have 2 bytes to read, and the correct length. just go ahead with get > response or command re-emission, now you know the correct length that will > be accepted by the card.
Well this is exactly where the trouble comes : I told my driver to receive Le bytes, but card send him only 2. The driver keeps on waiting, because it does know that these are errors/warnings. I can not go out of driver RX routine to process bytes, because I did not know that it will receive only 2 bytes in the first place, and going out after 2 bytes to my transport layer can result in RX FIFO overflow (as driver is concerned he thinks that data is still coming from the card). So - in this case how to know to stop drives RX after only two bytes ? By looking at timeout (Work Waiting time exceeded) ? BR, Drasko _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
