Hi Sebastien, On 7/6/10, Sébastien Lorquet <[email protected]> wrote: > On Tue, Jul 6, 2010 at 7:03 PM, Luisa <[email protected]> wrote: > >> Hi Drasko and Sebastien, >> >> Drasko, my fault. I meant 9600 Hz on my last email, rather than 96Khz. >> >> > OK, I thought you sent something like 20MHz to your card :) > > >> And, Sebastien, that comment was unvaluable! I couldn't get to a point >> where that would had shown up from trial and error. So thanks both!. >> >> Don't mention it :) > > >> Well, I'm not still getting it. I'd say my card is definetely not >> answering me each 372uS. Though I've got yet some tests to be done. >> Will keep on trying, but the situation is being the same, whatever I >> do, the card asnwers me with just the TS at a fixed speed, above the >> 372uS between bits. >> >> Also, just to know I'm not wrong with this as well, I'm supossed to >> toggle the clock line each etu, don't I? or does the card expects a >> high and just next to it, a low on the clock line? I'm using the >> former, though have also tried with the latter with no success. >> >> > As noted by Drasko, ISO7816 is not I2C or SPI (data bits synchronous to a > clock signal). The bus is really asynchronous, ie the clock line is really > the CPU clock signal used to drive all the internal logics, and the IO > signal is driven by an UART, like a PIC or a 8051, with a baud rate > generator. This is why it's called asynchronous. The etu is of course > related to the clock speed, for example the atr is sent at 372 clocks cycles > per ETU. > > FYI: the latest native card I worked with had an internal oscillator, and > only uses the input clock signal to detect whether someone is trying to > cheat. So the IO bit rate has really nothing to do with the input clock :-) > > FYI2: once unpon a time, when Roland was still young, the clock line was > driven by a bare quartz oscillator made from an inverter gate, and the IO > line was connected to both TxD and RxD of a RS-232 port (after level > conversion). If the quartz runs a 3.57 MHz, then 3570000 / 372 = 9600 bauds > and you can use a basic PC UART with the proper data bits and parity. Now > everything is USB, CCID, and we have SoC and microcontrollers, so we don't > need these tricks anymore! But I still have such a reader on my desk when I > need to be "sure" :) > > The behaviour of you card is extremeley clear and normal. You basically send > a 9600 Hz clock. The card detects this low frequency condition just after > sending TS, which is sent in hardware, but not the other bytes. This > behaviour seems to show that your card is recent and have a free running > clock, not dependent on the input clock frequency. You're lucky to see TS > and not a mute card. > > So basically the card is extremely underclocked, and not overclocked as I > thought. and it thinks you're trying to hack it: observing the internal > states by slowing down the CPU, which is an antique attack vector detected > by all modern card hardwares. > > Cards typically work correctly when Fclk is between 1 and 5 MHz. Out of > these bounds, the security detectors are activated and the card is muted as > soon as possible. >
Thanks, tips like those are always so interesting! hehe > > In fact, I noticed the card is giving me that TS byte alone even when >> I don't toggle the clock at all during the reset sequence. >> >> One more argument for the free running internal clock. > > For the record, I'm expecting data from the card after I toggle the clock >> line. >> >> And about the hardware, is within the allowed tollerances. My guess is >> that the problem is either in my firmware, or in my spanish id card >> not allowing a cold reset at 5 volts (perhaps the majority of chips >> have already gone down to 3.3 or so, I don't know). >> >> > Per ISO7816-3, all cards are *required* to work at 5 volts, and some of them > accepts a lower voltage. > > >> That's all by now. I did setup a google code account, though I've only >> uploaded the schematics: >> >> http://openscr.googlecode.com/files/breakout.pdf >> > > Looks very good. > If I were you, I would use a GPIO to detect card insertion. This event can > be used to trigger card activation, reset sequence, ATR reading and optional > PPS exchange. Do you plan to connect your reader to a PC via a serial port? > TxD and RxD are still free on PD0 and PD1. > Thanks, am, there is another hardware usart bellow it, and yes, my intention is to connect the reader to the computer. However, given your and drasko's clarifying comments, I'm feeling a bit like this is not the chip I want to use anymore? I mean, I'm gonna study the whole thing at hardware level, and study whether this chip will leave me room for getting anywhere I ever wanted to in terms of the iso implementation/smartcard development. If it doesn't, I have some ST7XX samples arround (arm7 chips from st-microelectronics), an (iirc) believe one of them has builtin smartcard support, including clock frecuency switching at runtime. My main concern is really to have a processor powerfull enough so as let me do it by software. It's more fun to me achieve a software implementation that I made, than reading the ds and setting a few registers with a given recommended hardware-setup beneath, though having that on-chip is an advantage also, I could use it when I wanted to. Well, thanks, I'l keep you informed guys! > Regards > Sebastien > > >> Regards, >> >> >> >> > Regards > Sebastien > > > > >> On 7/5/10, Sébastien Lorquet <[email protected]> wrote: >> > You're overclocking your card and the hardware overclock detector inside >> the >> > card stops the card. Only TS is sent because this is automatic and >> hardware >> > driven, but as soon as software starts, HW detectors are enabled, the >> faulty >> > condition is detected and the card is muted in a while(1); loop. >> > >> > At reset, a card MUST be clocked a 372 etu (default params) and the >> > clock >> > must be kept within limits, ie at a max of ~4 MHz >> > >> > Are you sure the voltages are in the mandated range? 5V +- 5%, or 10% >> don't >> > remember which tolerance must be met. Card also have over / under >> > voltage >> > detectors. >> > >> > Sebastien >> > >> > On Sun, Jul 4, 2010 at 11:26 PM, Drasko DRASKOVIC < >> > [email protected]> wrote: >> > >> >> On Sun, Jul 4, 2010 at 10:48 PM, Luisa <[email protected]> wrote: >> >> > Hi, >> >> > >> >> > Thanks for your answers. >> >> > >> >> > I've got a bit further with this, though not much more either. >> >> > >> >> > I found out the card, albeit being initalized as the iso says, and >> >> > having the clock line toggling @ 96000 Hz, is answering me with a bit >> >> > each +/- 20 microseconds. >> >> >> >> Why are you clocking your card with 96kHz ? Should not it be clocked >> >> 1-5Mhz >> >> ? >> >> >> >> What is "bit" in your case ? Is it value during one ETU, as it should >> >> be, or you are looking your clock (which is wrong) ? >> >> >> >> Clock your card with 1Mhz, and have in mind ETU value while decoding >> >> characters, because it defines your baud rate. Inital ETU for ATR will >> >> be 372/1Mhz = 372uS. "Bit" is a value taken during this period. >> >> Character duration will accordingly be 1(start bit) + 8 + 1(parity >> >> bit) + 2(guard bits) = 12 ETUs, i.e. 12*372uS. >> >> >> >> BR, >> >> Drasko >> >> _______________________________________________ >> >> Muscle mailing list >> >> [email protected] >> >> http://lists.drizzle.com/mailman/listinfo/muscle >> >> >> > >> >> _______________________________________________ >> Muscle mailing list >> [email protected] >> http://lists.drizzle.com/mailman/listinfo/muscle >> > _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
