 |
|
| If you can't view the Datasheet, Please click here to try to view without PDF Reader . |
|
|
|
| If you can't view the Datasheet, Please click here to try to view without PDF Reader . |
|
|
| Datasheet File OCR Text: |
| this is information on a product in full production. october 2014 docid018669 rev 10 1/72 CR95HF 13.56-mhz multi-protocol contactless transceiver ic with spi and uart serial access datasheet - production data features ? operating modes supported: ? reader/writer ? hardware features ? dedicated internal frame controller ? highly integrated analog front end (afe) for rf communications ? transmission and reception modes ? optimized power management ? tag detection mode ? rf communication @13.56 mhz ? iso/iec 14443 type a and b ? iso/iec 15693 ? iso/iec 18092 ? mifare? classic compatible (a) (b) ? communication interfaces with a host controller ? serial peripheral interface (spi) slave interface ? universal asynchronous receiver/transmitter (uart) ? up to 528-byte command/reception buffer (fifo) ? 32-lead, 5x5 mm, very thin fine pitch quad flat (vfqfpn) ecopack?2 package applications typical protocols supported: ? iso/iec 14443-3 type a and b tags ? iso/iec 15693 tags ? iso/iec 18000-3m1 tags ? nfc forum tags: types 1, 2, 3 and 4 ? st short-range interface (sri) tags ? st long-range interface (lri) tags ? st dual interface eeprom a. mifare and mifare classic are registered trademarks of nxp b.v. and are used under license. b. parity framing mode is compatible with mifare? classic requirements. however, access to authenticated state must be supported by an external secure host which embeds the mifare? classic library. vfqfpn32 5x5 mm www.st.com
contents CR95HF 2/72 docid018669 rev 10 contents 1 description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 list of terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2 pin and signal descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3 power management and operating modes . . . . . . . . . . . . . . . . . . . . . . . 8 3.1 operating modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2 startup sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4 communication protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1 universal asynchronous receiver/transmitter (uart) . . . . . . . . . . . . . . . 11 4.2 serial peripheral interface (spi) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2.1 polling mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2.2 interrupt mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.3 error codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.4 support of long frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5 commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1 command format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2 list of commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.3 idn command (0x01) description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.4 protocol select command (0x02) description . . . . . . . . . . . . . . . . . . . . . . 17 5.5 send receive (sendrecv) command (0x04) description . . . . . . . . . . . . . 22 5.6 idle command (0x07) description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.6.1 idle command parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.6.2 using lfo frequency setting to reduce power consumption . . . . . . . . . 30 5.6.3 optimizing wake-up conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.6.4 using various techniques to return to ready state . . . . . . . . . . . . . . . . 31 5.6.5 tag detection calibration procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.7 read register (rdreg) command (0x08) description . . . . . . . . . . . . . . . 34 5.8 write register (wrreg) command (0x09) description . . . . . . . . . . . . . . . 35 5.8.1 improving rf performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 5.8.2 improving frame reception for iso/iec 14443 type a tags . . . . . . . . . . 37 docid018669 rev 10 3/72 CR95HF contents 3 5.8.3 improving rf reception for iso/iec 18092 tags . . . . . . . . . . . . . . . . . . 37 5.9 baudrate command (0x0a) description . . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.10 echo command (0x55) description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 6 electrical characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 6.1 absolute maximum ratings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 6.2 dc characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 6.3 power consumption characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 6.4 spi characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 6.5 rf characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 6.6 oscillator characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 7 package mechanical data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 8 part numbering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 appendix a additional idle command description . . . . . . . . . . . . . . . . . . . . . . . 49 appendix b example of tag detection calibration process . . . . . . . . . . . . . . . . 50 appendix c example of tag detection command using results of tag detection calibration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 appendix d examples of CR95HF command code to activate nfc forum and iso/iec 15693 tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 d.1 iso/iec 14443 type a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 d.1.1 nfc forum tag type 1 (topaz) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 d.1.2 nfc forum tag type 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 d.1.3 nfc forum tag type 2 or 4: using split frames to resolve collisions. . . 57 d.1.4 nfc forum tag type 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 d.1.5 nfc forum tag type 4a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 d.2 iso/iec 14443 type b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 d.2.1 nfc forum tag type 4b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 d.3 iso/iec 18092 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 d.3.1 nfc forum tag type 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 d.4 iso/iec 15693 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 d.4.1 iso/iec 15693 tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 description CR95HF 4/72 docid018669 rev 10 1 description the CR95HF is an integrated transceiver ic for contactless applications. the CR95HF manages frame coding and decoding in reader mode for standard applications such as near field communication (nfc), proximity and vicinity standards. the CR95HF embeds an analog front end to provide the 13.56 mhz air interface. the CR95HF supports iso/iec 14443 type a and b, iso/iec 15693 (single or double subcarrier) and iso/iec 18092 communication protocols. the CR95HF also supports the detection, reading and writing of nfc forum type 1, 2, 3 and 4 tags. 1.1 block diagram figure 1. CR95HF application overview CR95HF host interrupt management spi uart controller (mcu) figure 2. CR95HF block diagram docid018669 rev 10 5/72 CR95HF description 7 1.2 list of terms table 1. list of terms term meaning dac digital analog converter gnd ground hfo high frequency oscillator lfo low frequency oscillator mcu microcontroller unit nfc near field communication rfid radio frequency identification rfu reserved for future use spi serial peripheral interface t l low frequency period t ref reference time uart universal asynchronous receiver-transmitter wfe wait for event pin and signal descriptions CR95HF 6/72 docid018669 rev 10 2 pin and signal descriptions figure 3. CR95HF pinout description table 2. CR95HF pin descriptions pin pin name type (1) main function alternate function 1 tx1 o driver output 1 2 tx2 o driver output 2 3 nc not connected 4 nc not connected 5 rx1 i receiver input 1 6 rx2 i receiver input 2 7 nc not connected 8 gnd_rx p ground (analog) 9 st_r0 o st reserved (2) 10 nc not connected 11 nc not connected 1 17 25 9 vps_tx gnd_tx xout xin nc nc nc gnd st_r1 ssi_1 spi_miso spi_ss uart_rx / irq_in vps tx1 tx2 nc nc rx1 shaded area represents the dissipation pad. (must be connected to ground.) rx2 nc gnd_rx nc nc nc ssi_0 spi_sck spi_mosi nc nc st_r0 uart_tx / irq_out docid018669 rev 10 7/72 CR95HF pin and signal descriptions 7 12 uart_rx / irq_in i (3) uart receive pin (4) interrupt input 13 vps p main power supply 14 uart_tx / irq_out o (5) uart transmit pin interrupt output 15 spi_ss i (6) spi slave select (active low) 16 spi_miso o (6) spi data, slave output 17 spi_mosi i (6) spi data, slave input (6) 18 spi_sck i (7) spi serial clock 19 ssi_0 i (6) select serial communication interface 20 ssi_1 i (6) select serial communication interface 21 st_r1 i (8) st reserved 22 gnd p ground (digital) 23 nc not connected 24 nc not connected 25 nc not connected 26 nc not connected 27 nc not connected 28 nc not connected 29 xin crystal oscillator input 30 xout crystal oscillator output 31 gnd_tx p ground (rf drivers) 32 vps_tx p power supply (rf drivers) 1. i: input, o: output, and p: power 2. must add a capacitor to ground (~1 nf). 3. pad internally connected to a very weak pull-up to vps. 4. we recommend connecting this pin to the v ps pin using a 3.3 kohm pull-up resistor. 5. pad internally connected to a weak pull-up to vps. 6. must not be left floating. 7. pad internally connected to a weak pull-down to gnd. 8. pad input in high impedance. must be connected to vps. table 2. CR95HF pin descriptions (continued) pin pin name type (1) main function alternate function power management and operating modes CR95HF 8/72 docid018669 rev 10 3 power management and operating modes 3.1 operating modes the CR95HF has 2 operating modes: wait for event (wfe) and active. in active mode, the CR95HF communicates actively with a tag or an external host (an mcu, for example). wfe mode includes four low consumption states: power-up, hibernate, sleep and tag detector. the CR95HF can switch from one mode to another. hibernate, tag detector, and sleep states can only be activated by a command from the external host. as soon as any of these three states are activated, the CR95HF can no longer communicate with the external host. it can only be woken up. the behavior of the CR95HF in 'tag detector' state is defined by the idle command. table 3. CR95HF operating modes and states mode state description wait for event (wfe) power-up this mode is accessible directly after por. low level on irq_in pin (longer than 10 s) is the only wakeup source. lfo (low-frequency oscillator) is running in this state. hibernate lowest power consumption state. the CR95HF has to be woken-up in order to communicate. low level on irq_in pin (longer than 10 s) is the only wakeup source. sleep low power consumption state. wakeup source is configurable: ? timer ? irq_in pin ? spi_ss pin lfo (low-frequency oscillator) is running in this state. tag detector low power consumption state with tag detection. wakeup source is configurable: ? timer ? irq_in pin ? spi_ss pin ? tag detector lfo (low-frequency oscillator) is running in this state. active ready in this mode, the rf is off and the CR95HF waits for a command (p rotocol s elect , ...) from the external host via the selected serial interface (uart or spi). reader the CR95HF can communicate with a tag using the selected protocol or with an external host using the selected serial interface (uart or spi). docid018669 rev 10 9/72 CR95HF power management and operating modes 71 3.2 startup sequence after the power supply is established at power-on, the CR95HF waits for a low pulse on the pin irq_in (t 1 ) before automatically selecting the external interface (spi or uart) and entering ready state after a delay (t 3 ). 1. note for pin ssi0: - - - spi selected, ???? uart selected 2. pin irq_in low level < 0.2 vps_main. note: when CR95HF leaves wfe mode (from power-up, hibernate, tag detector, or sleep) following an irq_in/rx low level pulse, this pulse is not interpreted as the uart start bit character. figure 4. CR95HF initialization and operating state change figure 5. power-up sequence - 3 6 6 0 3 ) 2 1 ? ) . & i r s t v a l i d c o m m a n d t t t t 3 3 ) ? 3 3 ) ? t power management and operating modes CR95HF 10/72 docid018669 rev 10 figure 5 shows the power-up sequence for a CR95HF device; where, ? t 0 is the initial wake-up delay 100 s (minimum) ? t 1 is the minimum interrupt width 10 s (minimum) ? t 2 is the delay for the serial interface selection 250 ns (typical) ? t 3 is the hfo setup time (t su(hfo) ) 10 ms (maximum) ? t 4 is the v ps ramp-up time from 0v to v ps 10 ms (max. by design validation) note: vps must be 0v before executing the start-up sequence. the serial interface is selected after the following falling edge of pin irq_in when leaving from por or hibernate state. table 4 lists the signal configuration used to select the serial communication interface. table 4. select serial communication interface selection table pin serial interface ssi_0 uart: 0 spi: 1 ssi_1 uart: 0 spi: 0 docid018669 rev 10 11/72 CR95HF communication protocols 71 4 communication protocols 4.1 universal asynchronous receiver/transmitter (uart) the host sends commands to the CR95HF and waits for replies. polling for readiness is not necessary. the default baud rate is 57600 baud. the maximum allowed baud rate is 2 mbps. when sending commands, no data must be sent if the len field is zero. when receiving data from the CR95HF, no data will be received if the len field is zero. the formats of send and receive packets are identical. if an e cho command is sent, only one byte (0x55) is sent by the host. figure 7 shows an example of an e cho command. caution: uart communication is lsb first. stop bit duration is two elementary time units (etus). note: 1 when CR95HF leaves wfe mode (from power-up, hibernate, sleep detector or tag detector) following an |rq_in/rx low level pulse, this pulse is not interpreted as the uart start bit character. 2 if the user loses uart synchronization, it can be recovered by sending an e cho command until a valid e cho reply is received. otherwise, after a maximum of 528 e cho commands, figure 6. uart communication figure 7. e cho command and response example sending commands to the CR95HF receiving data from the CR95HF cmd len data data several data bytes resp code len data data several data bytes ai18122a CR95HF internal clock rx tx 01234567 10101010 1 1 (stop) (echo 0x55) host to CR95HF rx tx CR95HF to host 0 (start) 10101010 1 1 (stop) (echo 0x55) 0 (start) communication protocols CR95HF 12/72 docid018669 rev 10 CR95HF will reply with an error code meaning its input buffer is full. the user can now restart a uart exchange. 4.2 serial peripheral interface (spi) 4.2.1 polling mode in order to send commands and receive replies, the application software has to perform 3 steps. 1. send the command to the CR95HF. 2. poll the CR95HF until it is ready to transmit the response. 3. read the response. the application software should never read data from the CR95HF without being sure that the CR95HF is ready to send the response. the maximum allowed spi communication speed is f sck . a control byte is used to specify a communication type and direction: ? 0x00: send command to the CR95HF ? 0x03: poll the CR95HF ? 0x02: read data from the CR95HF ? 0x01: reset the CR95HF the spi_ss line is used to select a device on the common spi bus. the spi_ss pin is active low. when the spi_ss line is inactive, all data sent by the master device is ignored and the miso line remains in high impedance state. figure 8. sending command to CR95HF figure 9. polling the CR95HF until it is ready mosi 00000000 cmd len data data control byte miso xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx several data bytes mosi 00000011 xxxxxx11 xxxxxx11 xxxxxx11 control byte miso xxxxxxxx flag flag flags are polled until data is ready (bit 3 is set when data is ready) 00000xxx 00000xxx 00001xxx docid018669 rev 10 13/72 CR95HF communication protocols 71 figure 10. reading data from CR95HF data must be sampled at the rising edge of the sck signal. ?sending?, ?polling? and ?reading? commands must be separated by a high level of the spi_ss line. for example, when the application needs to wait for data from the CR95HF, it asserts the spi_ss line low and issues a ?polling? command. keeping the spi_ss line low, the host can read the flags waiting bit which indicates that the CR95HF can be read. then, the application has to assert the spi_ss line high to finish the polling command. the host asserts the spi_ss line low and issues a ?reading? command to read data. when all data is read, the application asserts the spi_ss line high. the application is not obliged to keep reading flags using the polling command until the CR95HF is ready in one command. it can issue as many 'polling' commands as necessary. for example, the application asserts spi_ss low, issues 'polling' commands and reads flags. if the CR95HF is not ready, the application can assert spi_ss high and continue its algorithm (measuring temperature, communication with something else). then, the application can assert spi_ss low again and again issue 'polling' commands, and so on, as many times as necessary, until the CR95HF is ready. note that at the beginning of communication, the application does not need to check flags to start transmission. the CR95HF is assumed to be ready to receive a command from the application. figure 11. reset the CR95HF to reset the CR95HF using the spi, the application sends the spi reset command (control byte 01, see figure 11 ) which starts the internal controller reset process and puts the CR95HF into power-up state. the CR95HF will wake up when pin irq_in goes low. the CR95HF reset process only starts when the spi_ss pin returns to high level. caution: spi communication is msb first. table 5. interpretation of flags bit meaning (application point of view) [7:4] not significant 3 data can be read from the CR95HF when set. 2 data can be sent to the CR95HF when set. [1:0] not significant mosi 00000010 xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx control byte miso xxxxxxxx resp code len data data several data bytes mosi 00000001 control byte 01 miso xxxxxxxx communication protocols CR95HF 14/72 docid018669 rev 10 4.2.2 interrupt mode when the CR95HF is configure to use the spi serial interface, pin irq_out is used to give additional information to user. when the CR95HF is ready to send back a reply, it sends an interrupt request by setting a low level on pin irq_out, which remains low until the host reads the data. the application can use the interrupt mode to skip the polling stage. caution: spi communication is msb first. 4.3 error codes table 6. possible error codes and their meaning code name meaning 0x80 eframerecvok frame correctly received (additionally see crc/parity information) 0x85 euserstop stopped by user (used only in card mode) 0x86 ecommerror hardware communication error 0x87 eframewaittout frame wait time out (no valid reception) 0x88 einvalidsof invalid sof 0x89 ebufoverflow too many bytes received and data still arriving 0x8a eframingerror if start bit = 1 or stop bit = 0 0x8b eegterror egt time out 0x8c einvalidlen valid for iso/iec 18092, if length <3 0x8d ecrcerror crc error, valid only for iso/iec 18092 0x8e erecvlost when reception is lost without eof received (or subcarrier was lost) 0x8f enofield when listen command detects the absence of external field 0x90 eunintbyte residual bits in last byte. useful for ack/nak reception of iso/iec 14443 type a. docid018669 rev 10 15/72 CR95HF communication protocols 71 4.4 support of long frames in reader mode it is possible to receive up to 528 bytes of frame data from vicc and type- b cards and up to 256 bytes of frame data from type-a cards. in this case, the device sends a reply to the external mcu in the following format: commands CR95HF 16/72 docid018669 rev 10 5 commands 5.1 command format ? the frame from the host to the CR95HF has the following format: docid018669 rev 10 17/72 CR95HF commands 71 5.3 idn command (0x01) description the idn command ( 0x01 ) gives brief information about the CR95HF and its revision. it takes approximately 6 ms to calculate the crc for the entire rom. the application must allow sufficient time for waiting for a response for this command. 5.4 protocol select command (0x02) description this command selects the rf communication protocol and prepares the CR95HF for communication with a contactless tag. table 10. idn command description direction data comments example host to CR95HF 0x01 command code >>>0x0100 0x00 length of data CR95HF to host 0x00 result code <<<0x000f4e4643204653324a415354 34002ace in this example, <<<0x4e4643204653324a4153543400 : ?nfc fs2jast4?, #4 (last character of nfc fs2jast4 means rom code revision 4.) 0x2ace : crc of rom (real crc may differ from this example) commands CR95HF 18/72 docid018669 rev 10 note that there is no ?field on? command. when the application selects an rf communication protocol, the field automatically switches on . when the application selects a protocol, the CR95HF performs all necessary settings: it will choose the appropriate reception and transmission chains, switch on or off the rf field and connect the antenna accordingly. different protocols have different sets of parameters. values for the docid018669 rev 10 19/72 CR95HF commands 71 iso/iec 14443 type a nfc forum tag type 1 (topaz) nfc forum tag type 2 nfc forum tag type 4a 0x02 0 7:6 transmission data rate 00 : 106 kbps 01 : 212 kbps (2) 10 : 424 kbps 11 : rfu >>>0x02020200 : iso/iec 14443 type a tag, 106 kbps transmission and reception rates, time interval 86/90 note that reqa, wupa, select20 and select70 commands use a fixed interval of 86/90 s between a request and its reply. other commands use a variable interval with fixed granularity. refer to the iso/iec 14443 standard for more details. 5:4 reception data rate 00 : 106 kbps 01 : 212 kbps (2) 10 : 424 kbps 11 : rfu 3 rfu 2:0 rfu 1 7:0 pp these 5 bytes are optional. the default pp:mm:dd value is 0 (corresponds to fdt 86/90 s) . for other values, fdt = (2^pp)*(mm+1)*(dd+128) *32/13.56 s 2 7:0 mm 3 7:0 dd (optional to pp:mm) 4 7:0 st reserved (optional) 5 7:0 st reserved (optional) table 12. list of commands CR95HF 20/72 docid018669 rev 10 iso/iec 14443 type b nfc forum tag type 4b 0x03 0 7:6 transmission data rate 00 : 106 kbps 01 : 212 kbps 10 : 424 kbps 11 : 848 kbps >>>0x02020301 : iso/iec 14443 type b tag with crc appended 5:4 reception data rate 00 : 106 kbps 01 : 212 kbps 10 : 424 kbps 11 : 848 kbps 3:1 rfu 0 append crc if set to ?1?. (1) 1 7:0 pp these 9 bytes are optional. default value of pp:mm:dd is 0 and corresponds to fwt ~302 s. fwt = (2^pp)*(mm+1)*(dd+128)* 32/13.56 s 2 7:0 mm 3 7:0 dd (optional to pp:mm) 5:4 7:0 tttt (optional) tr0 = tttt/fc (lsb first), default 1023 = 0x3ff 6 7:0 yy (optional) pcd min tr1 (min_tr1 = 8 * xx / f s ), default = 0 7 7:0 zz (optional) pcd max tr1 (max_tr1 = 8 * zz / f s ), default = 26 = 0x1a 8 7:0 st reserved (optional) 9 7:0 st reserved (optional) table 12. list of docid018669 rev 10 21/72 CR95HF commands 71 iso/iec 18092 nfc forum tag type 3 0x04 0 7:6 transmission data rate 00 : rfu 01 : 212 kbps 10 : 424 kbps 11 : rfu >>>0x02020451 : iso/iec18092 tag, 212 kbps transmission and reception rates with crc appended. parameter ?slot counter? is not mandatory. if it is not present, it is assumed that slotcounter = 0x00 (1 slot) for device detection commands, byte 1 bit 4 must be set to ?0?. in this case, the fwt is 2.4 ms for the 1st slot and 1.2 ms more for each following slot, if slot counter is specified. if slot counter = 0x10 , the CR95HF does not respect reply timings, but polls incoming data and searches a valid response during ~8.4 ms. 5:4 reception data rate 00 : rfu 01 : 212 kbps 10 : 424 kbps 11 : rfu 3:1 rfu 0 append crc if set to ?1?. (1) 1 7:5 rfu 4 0: fwt = 2.4 ms 1: fwt is specified by pp:mm bits 3:0 slot counter 0 : 1 slot 1 : 2 slots ? f : 16 slots 2 7:0 pp these 3 bytes are optional. default value pp:mm:dd: is 0 and corresponds to rwt ~302 s. rwt = (2^pp)*(mm+1)* (dd+128)*32/13.56 s 3 7:0 mm 4 7:0 dd (optional to pp:mm) 1. it is recommended to set this bit to ?1?. 2. not characterized. table 12. list of commands CR95HF 22/72 docid018669 rev 10 5.5 send receive (sendrecv) command (0x04) description this command sends data to a contactless tag and receives its reply. before sending this command, the host must first send the p rotocol s elect command to select an rf communication protocol. if the tag response was received and decoded correctly, the field can contain additional information which is protocol-specific. this is explained in table 14 . table 13. s end r ecv command description direction data comments example host to CR95HF 0x04 command code see table 14 and table 18 for detailed examples. docid018669 rev 10 23/72 CR95HF commands 71 table 14 gives examples of communication between the CR95HF and a contactless tag. the CR95HF receives a sendrecv command (>>> 0x04 ...) from the host and returns its response to the host (<<< 0x80 ...). table 14 provides more details on the CR95HF response format. CR95HF to host 0x88 error code <<<0x8800 invalid sof 0x00 length of data CR95HF to host 0x89 error code <<<0x8900 receive buffer overflow (too many bytes received) 0x00 length of data CR95HF to host 0x8a error code <<<0x8a00 framing error (start bit = 0, stop bit = 1) 0x00 length of data CR95HF to host 0x8b error code <<<0x8b00 egt time out (for iso/iec 14443-b) 0x00 length of data CR95HF to host 0x8c error code <<<0x8c00 invalid length. used in nfc forum tag type 3, when field length < 3 0x00 length of data CR95HF to host 0x8d error code <<<0x8d00 crc error (used in nfc forum tag type 3 protocol) 0x00 length of data CR95HF to host 0x8e error code <<<0x8e00 reception lost without eof received 0x00 length of data 1. see table 14 for details. table 14. list of send values for the s end r ecv command for different protocols protocol explanation command example comments iso/iec 15693 send example 04 03 022000 example of an inventory command using different protocol configuration: uplink: 100% ask, 1/4 coding downlink: high data rate, single sub- carrier >>> 0x0403260100 (inventory - 1 slot) <<< 0x800d0000cde0406cd62902 e0057900 if length of data is ?0?, only the eof will be sent. this can be used for an anti- collision procedure. command code length of entire data field data table 13. s end r ecv command description (continued) direction data comments example commands CR95HF 24/72 docid018669 rev 10 iso/iec 14443 type a nfc forum tag type 4a nfc forum tag type 1 (topaz) nfc forum tag type 2 send example 04 07 9370800 f8c8e 28 example of an nfc forum type 2 request sequence: >>>0x04022607 (reqa) <<<0x800544002800 (atqa) >>>0x0403932008 (anti-collision cl1) <<<0x80088804a8d5f1280000 (uid cl1)... example of an nfc forum type 1 (topaz) request sequence: >>>0x04022607 (reqa) <<<0x8005000c280000 (atq0 atq1) >>>0x040878000000000000a8 (rid) <<<0x800b11486e567a003e450800 00 (header0 header1 uid0 uid 1 uid2 uid3 crc0 crc1signifcant bits indexcolbyte indexcolbit) application sw must specify how many bits to send in the last byte. if flag splitframe is set, CR95HF will expect 8 ? docid018669 rev 10 25/72 CR95HF commands 71 figure 13. data transfer (in both command and response) when parity framing mode is enabled iso/iec 18092 nfc forum tag type 3 send example 04 05 00ffff0000 example of an iso/iec 18092 / nfc forum type 3 request sequence: >>>0x040500ffff0000 (reqc) <<<0x801201010102148e0db41310 0b4b428485d0ff00 (atqc) command code length of entire data field data 1. for more information on using split frames, refer to appendix d on page 54 . 2. if parity framing mode is used (bit 4 of transmission flag byte is set to ?1?), then the parity bit must be coded inside the data for each byte to be sent using the send/receive command in transmit mode, and is not decoded by the CR95HF in receive mode. in receive mode, each data byte is accompanied by an additional byte which encodes the parity: commands CR95HF 26/72 docid018669 rev 10 iso/iec 14443 type a nfc forum tag type 4a nfc forum tag type 1 (topaz) nfc forum tag type 2 response example 80 or 90 (1) 09 80b30b8db500 00 00 00 iso/iec 14443-a is bit oriented protocol, so we can receive non-integer amount of bytes. number of significant bits in the 1 st byte is the same as indicated in the command sent. to calculate a position of a collision, application has to take index of byte first. index of bit indicates a position inside this byte. note that both indexes start from 0 and bit index can be 8, meaning that collision affected parity. note that collision information is only valid when bit ?collision is detected? is set. (2) result code length of entire data field data received from tag 7: collision is detected 6: rfu 5: crc error 4: parity error [3:0]: shows how many significant bits are there in the first byte 7:0: index of the first byte where collision is detected [7:4]: rfu [3:0]: index of the first bit where collision is detected iso/iec 14443 type b nfc forum tag type 4b response example 80 0f 5092036a8d0 00000000071 71 3411 00 result code length of entire data field data received from tag original (received) value of crc [7:2]: rfu 1: crc error if set 0: rfu iso/iec 18092 nfc forum tag type 3 response example 80 12 01010105017b0...93ff 00 <<<0x801201010105017b 06941004014b024f4993f f00 result code length of entire data field data received from tag [7:2]: rfu 1: crc error if set 0: rfu 1. result code 90: response is decoded but number of byte is not an integer. 2. for more information on using split frames, refer to appendix d on page 54 . table 15. list of response values for the s end r ecv command for different protocols (continued) protocol explanation response example comments docid018669 rev 10 27/72 CR95HF commands 71 for more detailed examples of use with nfc forum and iso/iec 15693 tags, refer to appendix d on page 54 . if parity framing mode is used, the parity bit stays unchanged. on transmission, it is not encoded and on reception it is not decoded. the length of data must be even. each data byte is accompanied by an additional byte which encodes the parity: commands CR95HF 28/72 docid018669 rev 10 table 17. i dle command description direction data comments example host to CR95HF 07 command code example of switch from active mode to hibernate state: >>>0x07 0e 08 04 00 04 00 18 00 00 00 00 00 00 00 00 example of switch from active to wfe mode (wake-up by low pulse on irq_in pin): >>>0x07 0e 08 01 00 38 00 18 00 00 60 00 00 00 00 00 example of switch from active to wfe mode (wake-up by low pulse on spi_ss pin): >>>0x07 0e 10 01 00 38 00 18 00 00 60 00 00 00 00 00 example of wake-up by timeout (7 seconds): duration before timeout = 256 * t l * (wu period + 2) * (maxsleep + 1) >>>0x07 0e 01 21 00 38 00 18 00 60 60 00 00 00 00 08 example of switch from active to tag detector mode (wake-up by tag detection or low pulse on irq_in pin) (32 khz, inactivity duration = 272 ms, dac oscillator = 3 ms, swing = 63 pulses of 13.56 mhz): >>>0x07 0e 0a 21 00 79 01 18 00 20 60 60 64 74 3f 08 example of a basic idle command used during the tag detection calibration process: >>>0x07 0e 03 a1 00 f8 01 18 00 20 60 60 00 xx 3f 01 where xx is the dacdatah value. 0e length of data docid018669 rev 10 29/72 CR95HF commands 71 5.6.1 idle command parameters the idle command (host to CR95HF) has the following structure (all values are hexadecimal): CR95HF to host 0x00 result code this response is sent only when CR95HF exits wfe mode. <<<0x000101 wake-up by timeout <<<0x000102 wake-up by tag detect <<<0x000108 wake-up by low pulse on irq_in pin 0x01 length of data data (wake-up source): 0x01: timeout 0x02: tag detect 0x08: low pulse on irq_in pin 0x10: low pulse on spi_ss pin CR95HF to host 0x82 error code <<<0x8200 invalid command length 0x00 length of data 1. an initial calibration is necessary to determine dacdatal and dacdatah values required for leaving tag detector state. for more information, contact your st sales office for the corresponding application note. table 17. i dle command description (continued) direction data comments example table 18. idle command structure 07 0e xx yy zz yy zz yy zz aa bb cc dd ee ff gg comma nd code data length wu source enter control wu control leave control wu period osc start dac start dac data swing count max sleep table 19. summary of idle command parameters parameter description command code this byte is the command code. ?07? represents the idle command. this command switches the device from active mode to wfe mode. data length this byte is the length of the command in bytes. its value depends on the following parameter values. wu source this byte defines the authorized wake-up sources in the wake-up source register. predefined values are: 0x01 : time out 0x02 : tag detection 0x08 : low pulse on irq_in 0x10 : low pulse on spi_ss enter control these two bytes (enterctrll and enterctrlh) define the resources when entering wfe mode. 0x0400 : hibernate 0x0100 : sleep (or 0x 2100 if timer source is enabled) 0xa200 : tag detector calibration 0x2100 : tag detection wu control these two bytes (wuctrll and wuctrlh) define the wake-up resources. 0x0400 : hibernate 0x3800 : sleep 0xf801 : tag detector calibration 0x7901 : tag detection commands CR95HF 30/72 docid018669 rev 10 5.6.2 using lfo frequency setting to reduce power consumption in wfe mode, the high frequency oscillator (hfo) is stopped and most processes being executed are clocked by the low frequency oscillator (lfo). to minimize CR95HF power consumption in wfe mode, the slower the lfo frequency, the lower the power consumption. example 1 : setting a lower lfo frequency the following equation defines a basic timing reference: t ref = 256*t l ms (where t l = 1/f lfo ) t ref = 8 ms (when bits [7:6] are set to ?00?, or 32 khz) t ref = 64 ms (when bits [7:6] are set to ?11?, or 4 khz) leave control these two bytes (leavectrll and leavectrlh) define the resources when returning to ready state. 0x1800 : hibernate 0x1800 : sleep 0x1800 : tag detector calibration 0x1800 : tag detection wu period this byte is the coefficient used to adjust the time allowed between two tag detections. also used to specify the duration before timeout. (typical value: 0x20) duration before timeout = 256 * t l * (wu period + 2) * (maxsleep + 1) osc start this byte defines the delay for hfo stabilization. (recommended value: 0x60) defines the wait time for hfo to stabilize: docid018669 rev 10 31/72 CR95HF commands 71 5.6.3 optimizing wake-up conditions using the wake-up source register, it is possible to cumulate sources for a wake-up event. it is strongly recommended to always set an external event as a possible wake-up source. to cumulate wake-up sources, simply set the corresponding bits in the wake-up source register. for example, to enable a wake-up when a tag is detected (bit 1 set to ?1?) or on a low pulse on pin irq_in (bit 3 set to ?1?), set the register to 0x0a. 5.6.4 using various techniques to return to ready state the idle command and reply set offers several benefits to users by enabling various methods to return the CR95HF to ready state. some methods are nearly automatic, such as waiting for a timer overflow or a tag detection, but others consume more power compared to the ones requesting a host action. a description of each method follows below. default setting: from por to ready state after power-on, the CR95HF enters power-up state. to wake up the CR95HF and set it to ready state, the user must send a low pulse on the irq_in pin. the CR95HF then automatically selects the external interface (spi or uart) and enters ready state and is able to accept commsands after a delay of approximately 6 ms (t 3 ). from ready state to hibernate state and back to ready state in hibernate state, most resources are switched off to achieve an ultra-low power consumption. the only way the CR95HF can wake-up from hibernate state is by an external event (low pulse on pin irq_in). a basic idle command is: >>>0x07 0e 08 04 00 04 00 18 00 00 00 00 00 00 00 00 note: the wake-up flag value is not significant when returning to ready state from hibernate state or after a por. from ready state to sleep state and back to ready state w ake-up by external event (low pulse on irq_in or spi_ss pin) in sleep or power-up states, operating resources are limited in function of the selected wake-up source to achieve a moderate power consumption level. an idle command example when wake-up source is pin irq_in: >>>0x07 0e 08 01 00 38 00 18 00 00 60 00 00 00 00 00 a similar command can be implemented using pin spi_ss as a wake-up source: >>>0x07 0e 10 01 00 38 00 18 00 00 60 00 00 00 00 00 w ake-up by t imeout the lfo is required to use the timer. however, this increases the typical power consumption by 80 a. several parameters can be modified to reduce power consumption as much as possible. commands CR95HF 32/72 docid018669 rev 10 the duration before timeout is defined by parameters wu period and maxsleep, respectively 0x60 and 0x08 in the following example. duration before timeout = 256 * t l * (wu period + 2) * (maxsleep + 1) note: note that: 0x00 < maxsleep < 0x1f. an idle command example when wake-up source is timer ( 0x01 ) when f lfo = 32 khz (mean power consumption is 25 a) >>>0x07 0e 01 21 00 38 00 18 00 60 60 00 00 00 00 08 an idle command example when wake-up source is timer ( 0xc1 ) when f lfo = 4 khz (mean power consumption is 20 a): >>>0x07 0e c1 21 00 38 00 18 00 60 60 00 00 00 00 08 the same command can be used mixing a timer and the irq_in pin ( 0xc9 ) as a wake-up source: >>>0x07 0e c9 21 00 38 00 18 00 60 60 00 00 00 00 08 wake-up by tag detection in this mode, the typical consumption can greatly vary in function of parameter settings (wu period without rf activity and swing count defining the rf burst duration). using default settings, consumption in the range of 100 a can be achieved. tag detector is a state where CR95HF is able to detect an rf event, a wake-up will occur when a tag sufficiently modifies the antenna load and is detected by the CR95HF. an idle command example when wake-up source is tag detection ( 0x02 ): >>>0x07 0e 02 21 00 79 01 18 00 20 60 60 64 74 3f 08 the same command can be used mixing tag detection and the irq_in pin ( 0x0a ) as a wake-up source: >>>0x07 0e 0a 21 00 79 01 18 00 20 60 60 64 74 3f 08 the tag detection sequence is defined by dedicated parameters: ? wu source (byte 3) ( wake-up source register on page 49 ) ? the timeout bit (bit 0) must be set to ?1? in order to manage a certain number of emitted bursts. otherwise, bursts will be sent indefinitely until a stop event occurs (for example, tag detection or a low pulse on pin irq_in). ? the tag detect bit (bit 1) must be set to ?1? to enable rf burst emissions. ? it is recommended to also set bits 3 or 4 to ?1? to ensure that it is possible to leave tag detect mode via an external event (for example, a low pulse on pin irq_in). ? wu period (byte 10): defines the period of inactivity (t inactive ) between two rf bursts: t inactive = (wuperiod + 2) * t ref ? oscstart, dacstart (bytes 11 and 12): define the set-up time of the hfo and digital analog converter, respectively. in general, 3 ms is used both set-up times. hfo | dac set-up time = (oscstart | dacstart) * t l ? dacdatal, dacdatah (bytes 13 and 14): reference level for tag detection (calculated during the tag detection calibration process). ? swingscnt (byte 15): represents the number of 13.56-mhz swing allowed during a tag detection burst. we recommend using 0x3f . docid018669 rev 10 33/72 CR95HF commands 71 ? maxsleep (byte 16): the CR95HF emits (maxsleep +1) bursts before leaving tag detection mode if bit 0 (timer out) of the wu source register is set to ?1?. otherwise, when this bit is set to ?0?, a burst is emitted indefinitely. note: bytes 4 to 9 should be used as shown in the examples in section 5.6: idle command (0x07) description . note that the maxsleep value is coded on the 5 least significant bits, thus: 0x00 < maxsleep < 0x1f. all the previously described command parameters must be chosen accordingly for the initial tag detection calibration when setting up the CR95HF. their value will impact tag detection efficiency, and CR95HF power consumption during tag detection periods. 5.6.5 tag detection calibration procedure the idle command allows the use of a tag detection as a wake-up event. certain parameters of the idle command are dedicated to setting the conditions of a tag detection sequence. during the tag detection sequence, the CR95HF regularly emits rf bursts and measures the current in the antenna driver i drive using the internal 6-bit dac. when a tag enters the CR95HF antenna rf operating volume, it modifies the antenna loading characteristics and induces a change in i drive , and consequently, the dac data register reports a new value. this value is then compared to the reference value established during the tag detection calibration process. this enables the CR95HF to decide if a tag has entered or not its operating volume. the reference value (dacdataref) is established during a tag detection calibration process using the CR95HF application setting with no tag in its environment. the calibration process consists in executing a tag detection sequence using a well-known configuration, with no tag within the antenna rf operating volume, to determine a specific reference value (dacdataref) that will be reused by the host to define the tag detection parameters (dacdatal and dacdatah). during the calibration process, dacdatal is forced to 0x00 and the software successively varies the dacdatah value from its maximum value (0xfe) to it minimum value (0x00). at the end of the calibration process, dacdataref will correspond to the value of dacdatah for which the wake-up event switches from timeout (no tag in the rf field) to tag detected. to avoid too much sensitivity of the tag detection process, we recommend using a guard band. this value corresponds to 2 dac steps (0x08). recommended guard band value: dacdatal = dacdataref ? guard and dacdatah = dacdataref + guard the parameters used to define the tag detection calibration sequence (clocking, set-up time, burst duration, etc.) must be the same as those used for the future tag detection sequences. when executing a tag detection sequence, the CR95HF compares the dac data register value to the dac data parameter values (dacdatal and dacdatah) included in the idle command. the CR95HF will exit wfe mode through a tag detection event if the dac data register value is greater than the dac data parameter high value (dacdatah) or less than the dac data parameter low value (dacdatal). otherwise, it will return to ready state after a timeout. commands CR95HF 34/72 docid018669 rev 10 an efficient 8-step calibration algorithm is described in example of tag detection calibration process on page 50 . an example of a basic idle command used during the tag detection calibration process: >>>0x07 0e 03 a1 00 f8 01 18 00 20 60 60 00 xx 3f 01 where xx is the dacdatah value. an example of a tag detection sequence is provided in example of tag detection command using results of tag detection calibration on page 53 . 5.7 read register (rdreg) command (0x08) description this command is used to read the wakeup register. note: the management of the analog register configuration register ( arc_b ) is described in section 5.8: write register (wrreg) command (0x09) description . table 20. r d r eg command description direction data comments example host to CR95HF 0x08 command code ex 1. >>> 0x0803690100 reads the arc_b register. (1) ex 2. >>> 0x0803620100 reads the wake-up event register. 1. this command must be preceded by the setting of the arc_b register index ( 0x0903680004). 0x03 length of data 0x62 or 0x69 register address 0x01 register size 0x00 st reserved CR95HF to host 0x00 result code <<<0x000101 wake-up by timeout (ex. 1) <<<0x000102 wake-up by tag detect (ex. 1) <<<0x000113 depth = 1, gain = 3 (ex. 2) <<< 0x000113 (arc_b register) depth = 1, gain = 3 (ex. 2). see write register description for more information on received data. docid018669 rev 10 35/72 CR95HF commands 71 5.8 write register (wrreg) command (0x09) description the write register (w r r eg ) command ( 0x09 ) is used to: ? set the analog register configuration address index value before reading or overwriting the analog register configuration register (arc_b) value ? set the timer window (timerw) value used to improve CR95HF demodulation when communicating with iso/iec 14443 type a tags ? set the autodetect filter used to help synchronization of CR95HF with iso/iec 18092 tags ? configure the hf2rf bit (a) to manage i cc rf (v ps_tx ) consumption in ready state 5.8.1 improving rf performance adjusting the modulation index and receiver gain parameters helps improve application behavior. the default value of these parameters ( table 24 ) is set by the p rotocol s elect command, but they can be overwritten using the write register (w r r eg ) command ( 0x09 ). table 22 and table 23 list possible values for the modulation index and receiver gain parameters respectively. this new configuration is valid until a new p rotocol s elect or write register (of register arc_b) command is executed. register values are cleared at power off. the default value of these parameters ( table 24 ) is set by the p rotocol s elect command, but they can be overwritten using the write register (w r r eg ) command ( 0x09 ). a. when the hf2rf bit is ?0?, reader mode is possible (default mode). when set to ?1?, v ps_tx power consumption is reduced (ready mode). table 21. w r r eg command description (modulation index and receiver gain) direction data comments example host to CR95HF 0x09 command code >>>0x090468010113 update arc_b value to 0x13 >>>0x0903680001 set analog register index to 0x01 (arc_b) (1) 1. this command must be executed before reading the arc_b register ( 0x0803690100 ). 0x03 or 0x04 length of data 0x68 analog register configuration address index 0x00 or 0x01 flag increment address or not after write command 0x01 index pointing to the modulation index and receiver gain values in the arc_b register (0x01) (see section 5.8.1 ) 0xxx new value for modulation index and receiver gain nibbles (see section 5.8.1 ) CR95HF to host 0x00 result code <<<0x0000 register written 0x00 length of data (= regcount ) commands CR95HF 36/72 docid018669 rev 10 this new configuration is valid until a new p rotocol s elect or write register (of register ) command is executed. register values are cleared at power off. how to modify analog register configuration register (arc_b) values 1. use the p rotocol s elect command ( 0x02 ) to select the correct communication protocol. for example, to select the iso/iec 18092 protocol: send p rotocol s elect command: >>> 0x02020451 CR95HF reply: <<< 0x0000 2. read the analog register configuration register (arc_b) value. a) write the arc_b register index at 0x01: >>>0x0903680001 CR95HF reply: <<< 0x0000 b) read the arc_b register value: >>> 0x0803690100 CR95HF reply: <<< 0x015f in this example, the arc_b register value is 0x5f , where ?5? is the modulation index and ?f? is the receiver gain. 3. modify the modulation index and receiver gain values with 0x23. write the arc_b register index: >>> 0x090468010123 CR95HF reply: <<< 0x0000 4. read the analog configuration register (arc_b) value. a) write the arc_b register index at 0x01: >>> 0x0903680001 CR95HF reply: <<< 0x0000 b) read the arc_b register value: >>> 0x0803690100 CR95HF reply: <<< 0x0123 modulation index and receiver gain values . table 22. possible modulation index values code 1 2 3 4 5 6 d modulation index (1) 1. characterized only using iso/iec 10373 test set-up. 10% 17% 25% 30% 33% 36% 95% table 23. possible receiver gain values code 0 1 3 7 f receiver gain (1) 1. characterized by design simulation. 34 db 32 db 27 db 20 db 8 db docid018669 rev 10 37/72 CR95HF commands 71 default code per protocol 5.8.2 improving frame reception for iso/iec 14443 type a tags to improve CR95HF demodulation when communicating with iso/iec 14443 type a tags, it is possible to adjust the synchronization between digital and analog inputs by fine-tuning the timer window (timerw) value. this can be done using the write register (w r r eg ) command to set a new timerw value (min. 0x50, max. 0x60). the recommended value is 0x56 or 0x58 when using the CR95HF demo board. the default value of this parameter (0x52) is set by the p rotocol s elect command, but it can be overwritten using the w r r eg command ( 0x09 ). 5.8.3 improving rf reception for iso/iec 18092 tags to improve CR95HF reception when communicating with iso/iec 18092 tags, it is possible to enable an autodetect filter to synchronize iso/iec 18092 tags with the CR95HF. this can be done using the write register (w r r eg ) command to enable the autodetect filter. table 24. arc_b default code for available reader protocols communication protocol default value recommended values for CR95HF demo board possible modulation index values (ms nibble) possible receiver gain values (ls nibble) iso/iec 14443 type a reader 0xdf 0xd1 or 0xd3 0xd 0x0, 0x1, 0x3, 0x7 or 0xf iso/iec 14443 type b reader 0x2f 0x20 0x1, 0x2, 0x3 or 0x4 0x0, 0x1, 0x3, 0x7 or 0xf iso/iec 18092 reader 0x5f 0x20 0x1, 0x2, 0x3 or 0x4 0x0, 0x1, 0x3, 0x7 or 0xf iso/iec 15693 reader 30% 0x53 0x50 0x4, 0x5 or 0x6 0x0, 0x1, 0x3, 0x7 or 0xf iso/iec 15693 reader 100% 0xd3 0xd0 0xd 0x0, 0x1, 0x3, 0x7 or 0xf table 25. w r r eg command description (timer window) direction data comments example host to CR95HF 0x09 command code >>> 0x09043a005804 set recommended timerw value. 0x03 or 0x04 length of data 0x3a timer window (timerw) value 0x00 or 0x01 flag increment address or not after write command 0xxx set timerw value (recommended value is 0x56 or 0x58) 0x04 timerw value confirmation CR95HF to host 0x00 result code <<<0x0000 register written 0x00 length of data (= regcount) commands CR95HF 38/72 docid018669 rev 10 by default, this filter is disabled after the execution of the p rotocol s elect command, but it can be enabled using the w r r eg command ( 0x09 ). 5.9 baudrate command (0x0a) description this command changes the uart baud rate. caution: if the baudrate command is not correctly executed, the baud rate value will remain unchanged. 5.10 echo command (0x55) description the e cho command verifies the possibility of communication between a host and the CR95HF. table 26. b aud r ate command description direction data comments example host to CR95HF 0x0a command code 0x01 length of data < baudrate > new baud rate = 13.56 /(2* docid018669 rev 10 39/72 CR95HF electrical characteristics 71 6 electrical characteristics 6.1 absolute maximum ratings note: stresses listed above may cause permanent damage to the device. this is a stress rating only and functional operation of the device at these or any other conditions above those indicated in the operational sections of the specification is not implied. exposure to absolute maximum rating conditions for extended periods may affect device reliability. table 28. absolute maximum ratings symbol parameter value unit vps_main supply voltage (1) 1. to properly reset the device, vps_main must be tied to 0v before executing the start-up sequence. ?0.3 to 7.0 v vps_tx supply voltage (rf drivers) ?0.3 to 7.0 v v io input or output voltage relative to ground ?0.3 to vps_main +0.3 v v maxcarrier maximum input voltage (pins rx1 and rx2) 14.0 v t a ambient operating temperature ?25 to +85 c ambient operating temperature (rf mode) ?25 to +85 t stg storage temperature (please also refer to package specification). ?65 to +150 c t lead lead temperature during soldering see note (2) 2. compliant with jedec standard j-std-020d (for small-body, sn-pb or pb assembly), the st ecopack? 7191395 specification, and the european directive on restrictions on hazardous substances (rohs directive 2011/65/eu of july 2011). c v esd electrostatic discharge voltage according to jesd22-a114, human body model 2000 v p tot (3) 3. depending on the thermal resistance of package. total power dissipation per package 1 w electrical characteristics CR95HF 40/72 docid018669 rev 10 6.2 dc characteristics 6.3 power consumption characteristics t a = ?25c to 85c, unless otherwise specified. the CR95HF supports two vps_tx supply ranges for rf drivers: 2.7v to 3.3v or 4.5v to 5.5v. antenna matching circuit must be defined accordingly. table 29. dc characteristics symbol parameter condition min. typ. max. unit vps_main supply voltage 2.7 3.0 5.5 v vps_tx supply voltage (rf drivers) 2.7 3.0 5.5 v v il input low voltage (i/os) 0 0.2 x vps_main v v ih input high voltage (i/os) 0.7 x vps_main vps_main v v oh output high voltage (i/os) i oh = - 8 a 0.7 x vps_main vps_main v v ol output low voltage (i/os) i olmax = 500 a0 0.15 x vps_main v por power-on reset voltage 1.8 v table 30. power consumption characteristics (vps_main from 2.7 to 3.3 v) symbol parameter condition typ. max. unit i cc (v ps ) power-up supply current in power-up state t a = 25c 200 600 a i cc (v ps ) hibernate supply current in hibernate state t a = 25c 1 5 a i cc (v ps ) sleep supply current in sleep state t a = 25c 20 80 a i cc (v ps ) ready supply current in ready state t a = 25c 2.5 5.0 ma i cc (v ps ) tag detect average supply current in tag detector state t a = 25c, 4 rf bursts per second 50 100 a table 31. power consumption characteristics (vps_tx from 2.7 to 3.3 v) symbol parameter condition typ. max. unit i cc rf (v ps_tx ) rf field on supply current in rf field (reader mode) (1) t a = 25c 70 100 ma i cc rf (v ps_tx ) rf field off supply current in rf field (ready mode) (2) t a = 25c 200 a i cc rf (v ps_tx ) tag detect peak (3) current during burst detection t a = 25c 70 100 ma 1. parameter measured using recommended output matching network. (z load is 27 ? and 0). 2. this consumption can be reduced to approximately 2 a (typ.) by setting a control bit (bit hf2rf) to ?1? using command 090468010710 . in this case, reader mode is not available. to re-enable reader mode, reset the hf2rf bit to ?0? using the command 090468010700 or execute a new p rotocol s elect command. 3. the maximum differential input voltage between pins rx1 and rx2 (vrx1-rx2) has a peak-peak of 18 v. docid018669 rev 10 41/72 CR95HF electrical characteristics 71 table 32. power consumption characteristics (vps_tx from 4.5 to 5.5 v) symbol parameter condition typ. max. unit i cc rf (v ps_tx ) rf field on supply current in rf field (reader mode) (1) t a = 25c 120 200 ma i cc rf (v ps_tx ) rf field off supply current in rf field (ready mode) (2) t a = 25c 300 a i cc rf (v ps_tx ) tag detect peak (3) current during burst detection t a = 25c 120 200 ma 1. parameter measured using recommended output matching network. (z load is 16 ? and 0). 2. this consumption can be reduced to approximately 2 a (typ.) by setting a control bit (bit hf2rf) to ?1? using command 090468010710 . in this case, reader mode is not available. to re-enable reader mode, reset the hf2rf bit to ?0? using the command 090468010700 or execute a new p rotocol s elect command. 3. the maximum differential input voltage between pins rx1 and rx2 (vrx1-rx2) has a peak-peak of 18 v. this voltage can be limited by adding a damping resistor in parallel of the antenna or between st_r0 and ground. electrical characteristics CR95HF 42/72 docid018669 rev 10 6.4 spi characteristics the CR95HF supports (cpol = 0, cpha = 0) and (cpol = 1, cpha = 1) modes. figure 14. spi timing diagram (slave mode and cpol = 0, cpha = 0) table 33. spi interface characteristics symbol parameter condition min. max. unit f sck 1/ t c(sck) spi clock frequency 2.0 mhz v il input low voltage 0.3 x v ps v v ih input high voltage 0.7 x v ps v ol output low voltage 0.4 x v ps v oh output high voltage 0.7 x v ps t su(nss) (1) 1. values based on design simulation and/or characterization results, and not on tested in production. nss setup time 70 ns t h(nss) (1) nss hold time 0 t ch(sckl) (1) clock low time 200 ns t ch(sckh) (1) clock high time 200 t su(si) (1) data slave input setup time 20 ns t h(si) (1) data slave input hold time 80 t v(so) (1) data slave output valid time 80 ns t h(so) (1) data slave output hold time after enable edge 150 c b_spi_in capacitive load for input pins nss, clk, mosi 3pf c b_spi_out capacitive load for input pins mosi 20 pf - 3 6 3 # + ) n p u t . 3 3 i n p u t t 3 5 . 3 3 t c 3 # + t h . 3 3 t 6 3 / t h 3 / t s u 3 ) t h 3 ) # 0 / , # 0 ( ! t # ( 3 # + ( t # ( 3 # + , - 3 " / u t - 3 " ) n " i t / u t " i t ) n , 3 " / u t , 3 " ) n - ) 3 / - / 3 ) docid018669 rev 10 43/72 CR95HF electrical characteristics 71 figure 15. spi timing diagram (slave mode and cpol = 1, cpha = 1) figure 16. - 3 6 3 # + ) n p u t - / 3 ) - ) 3 / t c 3 # + t h . 3 3 t # ( 3 # + , t v 3 / t h 3 / t s u 3 ) t h 3 ) . 3 3 i n p u t - 3 " / u t - 3 " ) n " i t / u t " i t ) n , 3 " / u t , 3 " ) n t # ( 3 # + ( t 3 5 . 3 3 # 0 / , # 0 ( ! electrical characteristics CR95HF 44/72 docid018669 rev 10 6.5 rf characteristics test conditions are t a = 0c to 50c, unless otherwise specified. table 34. reader characteristics symbol parameter min. typ. max. unit f c frequency of operating field (carrier frequency) 13.553 13.56 13. 567 mhz mi carrier carrier modulation index (1) iso/iec 14443-a iso/iec 14443-b iso/iec 18092 iso/iec 15693 (10% modulation) (2) iso/iec 15693 (100% modulation) 1. maximum values based on design simulation and/or characterization results, and not tested in production. 8 8 10 80 100 14 14 30 100 % transmitter specifications (vps_tx = 2.7 to 3.3 v) z out differential impedance between tx1 and tx2 (1) 27 ? output power for 3v operation on pin vps_tx (1)(2) 2. parameter measured on samples using recommended output matching network. (z load is 27 ? and 0.) 55 mw transmitter specifications (vps_tx = 4.5 to 5.5 v) z out differential impedance between tx1 and tx2 (1) 16 ? output power for 5v operation on pin vps_tx (1) (2) 230 mw receiver specifications small signal differential input resistance (rx1/rx2) (1) 100 k ? vrx1-rx2 differential input voltage between pins rx1 and rx2 (3) 3. this voltage can be limited by adding a damping resistor in parallel of the antenna or between st_r0 and ground. 18 v small signal differential input capacitance (cx1/cx2) (1) 22 pf sensitivity (106 kbps data rate) (4) 4. based on iso/iec 10373-6 protocol measurement. the reader sensitivity corresponds to the load modulation value of the req reply sent by an iso reference card when decoded by the CR95HF. 8mv docid018669 rev 10 45/72 CR95HF electrical characteristics 71 6.6 oscillator characteristics the external crystal used for this product is a 27.12 mhz crystal with an accuracy of 14 khz. for c l1 and c l2 , it is recommended to use high-quality external ceramic capacitors in the 10 pf to 20 pf range (typ.), designed for high-frequency applications, and selected to match the requirements of the crystal or resonator (see figure 17 ). c l1 and c l2 are usually the same size. the crystal manufacturer typically specifies a load capacitance which is the series combination of c l1 and c l2 . figure 17. typical application with a 27.12 mhz crystal note: for c l1 and c l2 it is recommended to use high-quality ceramic capacitors in the 10 pf to 20 pf range selected to match the requirements of the crystal or resonator. c l1 and c l2, are usually the same size. the crystal manufacturer typically specifies a load capacitance which is the series combination of c l1 and c l2 . load capacitance c l has the following formula: c l = c l1 x c l2 / ( c l1 + c l2 ) + c stray where c stray is the pin capacitance and board or trace pcb-related capacitance. typically, it is between 2 pf and 7 pf. table 35. hfo 27.12 mhz oscillator characteristics (1) (2) 1. resonator characteristics given by the crystal/ceramic resonator manufacturer. 2. based on characterization, not tested in production. symbol parameter conditions min. typ. max. unit f xtal oscillator frequency 27.12 mhz r f feedback resistor 2 m ? c recommended load capacitance versus equivalent serial resistance of the crystal (r s ) (3) 3. the relatively low value of the r f resistor offers a good protection against issues resulting from use in a humid environment, due to the induced leakage and the bias condition change. however, it is recommended to take this point into account if the host is used in tough humidity conditions. r s = 30 ?? 6pf t su(hfo) (4) 4. t su(hfo) is the startup time measured from the moment it is enabled (by software) to a stabilized 27.12 mhz oscillation is reached. this value is measured for a standard crystal resonator and it can vary significantly with the crystal manufacturer. startup time v ps is stabilized 6 10 ms d l e 9 ; 2 8 7 ; , 1 i + ) 2 & / 5 ) 1 ) & g h y l f h 0 + ] f u \ v w d o & / package mechanical data CR95HF 46/72 docid018669 rev 10 7 package mechanical data in order to meet environmental requirements, st offers these devices in different grades of ecopack ? packages, depending on their level of environmental compliance. ecopack ? specifications, grade definitions and product status are available at: www.st.com . ecopack ? is an st trademark. this device is available in a 32-lead, 5x5 mm, 0.5 mm pitch, very thin fine pitch quad flat pack no-lead package (vfqfpn). figure 18. 32-lead vfqfpn package outline 6 h d w l q j s o d q h g g g & & $ $ $ ' h 3 l q , ' 5 ( / / ' e ( b 0 ( % r w w r p y l h z docid018669 rev 10 47/72 CR95HF package mechanical data 71 note: 1 amkor variation b. dimensions are not in accordance with jedec. 2 amkor. table 36. 32-pin vfqfpn package mechanical data symbol millimeters inches (1) 1. values in inches are rounded to 4 decimal digits. note min. typ. max. min. typ. max. a 0.800 0.900 1.000 0.0315 0.0354 0.0394 a1 0.000 0.020 0.050 0.0000 0.0008 0.0020 a3 0.200 0.0079 b 0.180 0.250 0.300 0.0071 0.0098 0.0118 d 4.850 5.000 5.150 0.1909 0.1969 0.2028 d2 (amk_b) 3.500 3.600 3.700 0.1378 0.1417 0.1457 1 e 4.850 5.000 5.150 0.1909 0.1969 0.2028 e2 (amk_b) 3.500 3.600 3.700 0.1378 0.1417 0.1457 1 e 0.500 0.0197 l 0.300 0.400 0.500 0.0118 0.0157 0.0197 ddd (amk) 0.050 0.0020 2 part numbering CR95HF 48/72 docid018669 rev 10 8 part numbering not all combinations are necessarily available. for a list of available options (speed, package, etc.) or for further information on any aspect of this device, please contact your nearest stmicroelectronics sales office. table 37. ordering information scheme example: cr 95 hf ? v md 5 t device type cr = contactless reader ic wired access 95 = spi and uart frequency band hf = high frequency (13.56 mhz) operating voltage v = 2.7 to 5.5 v package md = 32-pin vfqfpn (5 x 5 mm) operating temperature 5 = ?25 to +85 c packaging t = tape and reel docid018669 rev 10 49/72 CR95HF additional idle command description 71 appendix a additional idle command description this section provides examples of use for the i dle command. the wake-up source is the third of the 16 bytes in the i dle command. this byte specifies authorized wake-up events. this revision now also provides the capability to set the lfo frequency in wfe mode. the lfo frequency and the authorized wake-up source settings are stored in the wake-up source register as the parameters of the i dle command. the wake-up event is updated by the CR95HF when it exits wfe mode. the contents of the wake-up event register can be read using the read register command or in the CR95HF reply to the idle command. bits [7:6] define the lfo frequency (f lfo ): 00: 32 khz 01: 16 khz 10: 8 khz 11: 4 khz bit 4 : when set, the CR95HF will wake up when an external interrupt (low level on pin spi_ss) is detected. this is useful for uart communication. bit 3 : when set, the CR95HF will wake up when an external interrupt (low level on pin irq_in) is detected. this is useful for spi communication. it is recommended to set this bit to ?1? in order to recover in the event of a system crash. bit 1 : when set, the CR95HF will wake up when a tag is detected in the rf field. this bit must also be set during tag detection calibration or during a tag detection sequence. bit 0 : when set, the CR95HF will wake up and return to ready state at the end of a predefined cycle. the timeout (to) value is defined by the maxsleep and wake-up period: to = (maxsleep *(wuperiod+1)*t ref t ref = 256*t l = 8 ms (f lfo = 32 khz), mean power consumption in sleep mode is 25 a t ref = 256*t l = 64 ms (f lfo = 4 khz), mean power consumption in sleep mode is 20 a note: note that: 0x00 < maxsleep < 0x1f. this bit must be set when using the timer as a possible wake-up source. it must be set during tag detection calibration to force a wake-up after the first tag detection trial. table 38. wake-up source register bits [7:6] bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 lfo frequency rfu (1) 1. must be set to ?0?. irq on pin spi_ss irq on pin irq_in rfu (1) tag detect timeout table 39. wake-up event register bits [7:6] bit 5 bit 4 bit 3 bit 2 bit 1 bit 0 lfo frequency rfu irq on pin spi_ss irq on pin irq_in rfu tag detect timeout example of tag detection calibration process CR95HF 50/72 docid018669 rev 10 appendix b example of tag detection calibration process the following script works on the demo_CR95HF evaluation board and with the CR95HF developement software available from the st internet site. this is a dichotomous approach to quickly converge to the dacdataref value for which a wake-up event switches from tag detection to timeout. in this process, only the dacdatah parameter is changed in successive idle commands. and we look at the wake-up event reply to decide the next step. 00 01 02 corresponds to a tag detect, 00 01 01 corresponds to a timeout. rem, tag detection calibration test rem, sequence: power-up tag detect wake-up by tag detect (1 try measurement greater or equal to dacdatah) or timeout rem, cmd 07 0e 03 a100 d801 1800 01 60 60 00 xx 3f 00 rem, 03 wu source = tagdet or timeout rem, a100 initial dac compare rem, f801 initial dac compare rem, 1800 hfo rem, 20 wup period 32 inactivity period = 256ms (lfo @ 32khz) rem, 60 osc 3ms (lfo @ 32khz) rem, 60 dac 3ms (lfo @ 32khz) rem, 00 dacdatal = minimum level (floor) rem, xx dacdatah 00 = minimum level (ceiling) rem, 3f swing 13.56 4.6 us rem, 01 maximum number of sleep before wakeup 2 rem, tag detection calibration test rem, during tag detection calibration process dacdatal = 0x00 rem, we execute several tag detection commands with different dacdatah values to determine dacdataref level corresponding to CR95HF application set-up rem, dacdatareg value corresponds to dacdatah value for which wake- up event switches from timeout (0x01) to tag detect (0x02) rem, wake-up event = timeout when dacdataref is between dacdatal and dacdatah rem, search dacdataref value corresponding to value of dacdatah for which wake-up event switches from tag detect (02) to timeout(01) docid018669 rev 10 51/72 CR95HF example of tag detection calibration process 71 rem, step 0: force wake-up event to tag detect (set dacdatah = 0x00) rem, with these conditions wake-up event must be tag detect >>> CR95HFdll_stcmd, 01070e03a100f801180020606000003f01 <<< 000102 rem, read wake-up event = tag detect (0x02); if not, error . rem, step 1: force wake-up event to timeout (set dacdatah = 0xfc rem, with these conditions, wake-up event must be timeout >>> CR95HFdll_stcmd, 01070e03a100f801180020606000fc3f01 <<< 000101 rem, read wake-up event = timeout (0x01); if not, error . rem, step 2: new dacdatah value = previous dacdatah +/- 0x80 rem, if previous wake-up event was timeout (0x01) we must decrease dacdatah (-0x80) >>> CR95HFdll_stcmd, 01070e03a100f8011800206060007c3f01 <<< 000101 rem, read wake-up event = timeout (0x01) or wake-up event = tag detect (0x02) rem, step 3: new dacdatah value = previous dacdatah +/- 0x40 rem, if previous wake-up event was timeout (0x01), we must decrease dacdatah (-0x40); else, we increase dacdatah (+ 0x40) >>> CR95HFdll_stcmd, 01070e03a100f8011800206060003c3f01 <<< 000102 rem, read wake-up event = timeout (0x01) or wake-up event = tag detect (0x02) rem, step 4: new dacdatah value = previous dacdatah +/- 0x20 rem, if previous wake-up event was timeout (0x01), we must decrease dacdatah (-0x20); else, we increase dacdatah (+ 0x20) >>> CR95HFdll_stcmd, 01070e03a100f8011800206060005c3f01 <<< 000102 rem, read wake-up event = timeout (0x01) or wake-up event = tag detect (0x02) example of tag detection calibration process CR95HF 52/72 docid018669 rev 10 rem, step 5: new dacdatah value = previous dacdatah +/- 0x10 rem, if previous wake-up event was timeout (0x01), we must decrease dacdatah (-0x10); else, we increase dacdatah (+ 0x10) >>> CR95HFdll_stcmd, 01070e03a100f8011800206060006c3f01 <<< 000102 rem, read wake-up event = timeout (0x01) or wake-up event = tag detect (0x02) rem, step 6: new dacdatah value = previous dacdatah +/- 0x08 rem, if previous wake-up event was timeout (0x01), we must decrease dacdatah (-0x08); else, we increase dacdatah (+ 0x08) >>> CR95HFdll_stcmd, 01070e03a100f801180020606000743f01 <<< 000101 rem, read wake-up event = timeout (0x01) or wake-up event = tag detect (0x02) rem, step 7: new dacdatah value = previous dacdatah +/- 0x04 rem, if previous wake-up event was timeout (0x01), we must decrease dacdatah (-0x04); else, we increase dacdatah (+ 0x04) >>> CR95HFdll_stcmd, 01070e03a100f801180020606000703f01 <<< 000101 rem, read wake-up event = timeout (0x01) or wake-up event = tag detect (0x02) rem, if last wake-up event = tag detect (0x02), search dacdataref = last dacdatah value rem, if last wake-up event = timeout (0x01), search dacdataref = last dacdatah value -4 rem, for tag detection usage, we recommend setting dacdatal = dacdataref -8 and dacdatah = dacdataref +8 >>> CR95HFdll_stcmd, 01070e0b21007801180020606064743f01 <<< 000101 docid018669 rev 10 53/72 CR95HF example of tag detection command using results of tag detection calibration 71 appendix c example of tag detection command using results of tag detection calibration the following script works on the demo_CR95HF evaluation board and with the CR95HF development software available from the st internet site. this is an example of a tag detection command when a tag is not present in the rf operating volume using the CR95HF: >>> CR95HFdll_stcmd, 01 070e0b21007801180020606064743f01 <<< 000101 wake-up event = timeout (0x01) >>> CR95HFdll_stcmd, 01 0803620100 <<< 000101 this is an example of a tag detection command when a tag is present in the rf operating volume using the CR95HF: >>> CR95HFdll_stcmd, 01 070e0b21007801180020606064743f01 <<< 000102 wake-up event = tag detect (0x02) >>> CR95HFdll_stcmd, 01 0803620100 <<< 000102 examples of CR95HF command code to activate nfc forum and iso/iec 15693 tags CR95HF 54/72 docid018669 rev 10 appendix d examples of CR95HF command code to activate nfc forum and iso/iec 15693 tags the following script works on the demo_CR95HF evaluation board and with the CR95HF developement software available from the st internet site. this section provides examples of CR95HF command code used to activate nfc forum and iso/iec 15693 tags using CR95HF development software. CR95HFdll_stcmd : is the standard CR95HF frame exchange command. in this command, the first byte 01 is not sent, it is only requested by the CR95HF development software in order to recognize if it is a user or service command. CR95HFdll_sendrecv : is the encapsulated CR95HF sendreceive command for which command codes, number of bytes, and crc are automatically appended to the parameter. in this section, ? the CR95HF command overhead (command code, length of data and transmission flag) is in black. ? the tag instruction is in blue . ? the CR95HF response overhead (result code, length of data and status) is in green . ? the tag response is in red . when the crc append option is set in the protocol select command, the crc is automatically appended by the CR95HF, but the crc is not visible in the instruction log file. when the crc is present in the command or response, crc reply is in italics . the following symbols correspond to: >>> frame sent by host to CR95HF <<< frame received by host from CR95HF d.1 iso/iec 14443 type a d.1.1 nfc forum tag type 1 (topaz) rem, CR95HF code example to support nfc forum tag type 1 14443_a rem, test topaz 14443a (uid 6e567a00) rem, first byte 01 in CR95HFdll_stcmd is only requested by CR95HF development sw rem, rfoff >>> CR95HFdll_stcmd, 01 02020000 <<< 0000 rem, test topaz 14443a (uid 6e567a00) rem, sel prot 14443a option topaz >>> CR95HFdll_stcmd, 01 020402000300 <<< 0000 docid018669 rev 10 55/72 CR95HF examples of CR95HF command code to activate nfc forum and iso/iec 15693 tags 71 rem, optimization of synchronization between digital and analog inputs by adjusting timerw value (default 0x52, min. 0x50, max. 0x60). recommended value is 0x56 or 0x58 for nfc forum tag type 1 (topaz). >>> CR95HFdll_stcmd, 01 09043a00 58 04 <<< 0000 rem, recommended modulation and gain is 0xd1 or 0xd3 for nfc forum tag type 1 (topaz). >>> CR95HFdll_stcmd, 01 0904680101 d1 <<< 0000 rem, last byte x7 or x8 in CR95HFdll_sendrecv command number of bits in the 14443 _type a frame rem, reqa reply atqa 000c >>> CR95HFdll_stcmd, 01 04 02 26 07 <<< 80 05 000c 280000 rem, rid reply hr0 hr1 uid0 uid 1 uid2 uid3 >>> CR95HFdll_stcmd, 01 04 08 78000000000000 a8 <<< 80 0b 11 48 6e567a00 3e45 080000 rem, rall 0408 0000 uid0 uid 1 uid2 uid3 reply hr0 hr1 uid0 uid 1 uid2 uid3 datas >>> CR95HFdll_stcmd, 01 04 08 000000 6e567a00 a8 <<< 80 40 11 48 6e567a00 0002250000100e000313d1010f5402656e557365204352393552462021000000000 0000000000000000000000000000000000000000000cccccc rem, read ad08 00 uid0 uid 1 uid2 uid3 >>> CR95HFdll_stcmd, 01 04 08 01 0800 6e567a00 a8 <<< 80 07 08 00 87c1 080000 rem, write_e ad08 data 12 uid0 uid 1 uid2 uid3 >>> CR95HFdll_stcmd, 01 04 08 53 0812 6e567a00 a8 <<< 80 07 08 12 14f2 080000 rem, read ad08 00 uid0 uid 1 uid2 uid3 >>> CR95HFdll_stcmd, 01 04 08 01 0800 6e567a00 a8 <<< 80 07 08 12 14f2 080000 rem, write_ne ad08 data a5 uid0 uid 1 uid2 uid3 >>> CR95HFdll_stcmd, 01 04 08 1a 08a5 6e567a00 a8 <<< 80 07 08 b7 b300 080000 rem, read ad08 00 uid0 uid 1 uid2 uid3 >>> CR95HFdll_stcmd, 01 04 08 01 0800 6e567a00 a8 examples of CR95HF command code to activate nfc forum and iso/iec 15693 tags CR95HF 56/72 docid018669 rev 10 <<< 80 07 08 b7 b300 080000 rem, write_e ad08 data 00 uid0 uid 1 uid2 uid3 >>> CR95HFdll_stcmd, 01 04 08 53 0800 6e567a00 a8 <<< 80 07 08 00 87c1 080000 rem, read ad08 00 uid0 uid 1 uid2 uid3 >>> CR95HFdll_stcmd, 01 04 08 01 0800 6e567a00 a8 <<< 80 07 08 00 87c1 080000 d.1.2 nfc forum tag type 2 rem, CR95HF code example to support nfc forum tag type 2 14443_a rem, test inventory then read & write in memory rem, protocol select 14443a >>> CR95HFdll_stcmd, 01 02020200 <<< 0000 rem, optimization of synchronization between digital and analog inputs by adjusting timerw value (default 0x52, min. 0x50, max. 0x60). recommended value is 0x56 or 0x58 for nfc forum tag type 2. >>> CR95HFdll_stcmd, 01 09043a00 58 04 <<< 0000 rem, recommended modulation and gain is 0xd1 or 0xd3 for nfc forum tag type 2. >>> CR95HFdll_stcmd, 01 0904680101 d1 <<< 0000 >>> CR95HFdll_anticolselect123 ------ iso14443-a starting anticollision algorithm ------ iso14443-a reqareply atqa >>> CR95HFdll_sendrecv, 26 07 <<< 80 05 4400 280000 iso14443-a anticol 1 >>> CR95HFdll_sendrecv, 93 20 08 <<< 80 08 8804179f04 280000 iso14443-a select 1 >>> CR95HFdll_sendrecv, 93 70 8804179f04 28 <<< 80 06 04 da17 080000 docid018669 rev 10 57/72 CR95HF examples of CR95HF command code to activate nfc forum and iso/iec 15693 tags 71 iso14443-a anticol 2 >>> CR95HFdll_sendrecv, 9520 08 <<< 80 08 7910000069 280000 iso14443-a select 2 >>> CR95HFdll_sendrecv, 9570 7910000069 28 <<< 80 06 00 fe51 080000 --> uid = 04179f10000069 --> tag selected ------ iso14443-a end of anticollision algorithm ------ rem, read @a5 >>> CR95HFdll_sendrecv, 300c 28 <<< 80 15 00000000ffffffffffffffffffffffff f4cd 080000 rem, write @0c data a5 >>> CR95HFdll_sendrecv, a20ca5a5a5a5 28 <<< 87 00 : frame wait time out or no tag rem, read @a5 >>> CR95HFdll_sendrecv, 300c 28 <<< 80 15 a5a5a5a5ffffffffffffffffffffffff 84d8 080000 d.1.3 nfc forum tag type 2 or 4: using split frames to resolve collisions rem, test anticolision 2 tags 14443_a rem, CR95HF configuration : iso14443-a protocol >>> CR95HFdll_select, 02000280 <<< 0000 rem, iso14443-a : config >>> CR95HFdll_stcmd, 01 09043a005a04 <<< 0000 rem, iso14443-a : increase demod gain >>> CR95HFdll_stcmd, 01 0904680101df <<< 0000 rem, anticollision 2 tags rem, tag 1 --> uid = 044b744aef2280 examples of CR95HF command code to activate nfc forum and iso/iec 15693 tags CR95HF 58/72 docid018669 rev 10 rem, tag 2 --> uid = 043b114aef2280 rem, response when 2 tags are present nvb = nb byte ok + nb bit ok rem, collision b8 rem, first byte coll 02 (3 eme byte) (8804 ok) rem, index bit coll 04 (5eme bit) => sn finish by 0 or 1 rem, set nvb = 45 rem, reqa poll field with two tags in operating volume >>> CR95HFdll_stcmd, 01 04022607 <<< 80 05 4403 280000 rem, ant cl1 collision detection (nvb 20) none data on uid rem, response flag f1=b8 f2=02 f3=04 rem, f1=b8 collision detected 8 bits significatifs in first byte of response rem, f2=02 collision detected in 3rd response byte, index start at 0 rem, f3=04 collision detected on 5th bit, index start at 0 >>> CR95HFdll_stcmd, 01 0403932008 <<< 80 08 88047b75b7 b80204 rem, collision management usage of split frame with nvb = 45 4bytes ok + 5 lsb bit ok in next byte rem, last bit (collision one) arbitrary fixed to select only one branch of uid tree rem, padding of last byte with zeros as msb (tranmission lsb first) 0b rem, command flag 45 usage of split frame (4) with 5 bits significatif in last byte rem, uncomplete response byte is padded with 0 as lsb bits rem, response flag f1=23 f2=00 f3=00 rem, f1=23, no collision rem, 3 bit significatif (msb last received bits) in first response byte 40 rem, f2=00, not significant rem, f3=00, not significant >>> CR95HFdll_stcmd, 01 0406934588040b45 docid018669 rev 10 59/72 CR95HF examples of CR95HF command code to activate nfc forum and iso/iec 15693 tags 71 <<< 80 06 4074b3 230000 rem, activation tag highest branch >>> CR95HFdll_sendrecv, 937088044b74b328 <<< 80 06 24d836 080000 rem, ant cl2 >>> CR95HFdll_stcmd, 01 0403952008 <<< 80 08 4aef228007 280000 rem, sel cl2 tag highest branch >>> CR95HFdll_sendrecv, 95704aef22800728 <<< 80 06 20fc70 080000 rem, iso14443-a hlta tag1 highest branch >>> CR95HFdll_sendrecv, 500028 <<< 8700 : frame wait time out or no tag rem, wupa second tags in field >>> CR95HFdll_stcmd, 01 04025207 <<< 80 05 4403 280000 rem, ant cl1 detection collision second tag (no collision) >>> CR95HFdll_stcmd, 01 0403932008 <<< 80 08 88047b75b7 b80204 rem, activation tag lowest branch 043b114aef2280 >>> CR95HFdll_sendrecv, 937088043b11a6789808 <<< 80 06 24d836 080000 rem, ant cl2 >>> CR95HFdll_stcmd, 01 0403952008 <<< 80 08 4aef228007 280000 rem, sel cl2 tag highest branch >>> CR95HFdll_sendrecv, 95704aef22800728 <<< 80 06 20fc70 080000 rem, iso14443-a hlta tag2 lowest branch >>> CR95HFdll_sendrecv, 500028 <<< 8700 : frame wait time out or no tag examples of CR95HF command code to activate nfc forum and iso/iec 15693 tags CR95HF 60/72 docid018669 rev 10 rem, reqa no other tag in operating volume >>> CR95HFdll_stcmd, 01 04022607 <<< 8700 d.1.4 nfc forum tag type 2 communication using parity framing mode which is compliant with mifare? framing requirements. rem, test extract ndef message of nfc tag type 2 using parity framing mode option rem, iso14443-a protocol select >>> 02000280 <<< 0000 rem, iso14443-a configuration >>> 09043a005a04 <<< 0000 rem, iso14443-a: increase modulation and gain >>> 0904680101df <<< 0000 rem, reqa >>> 04 02 26 07 <<< 80 05 4400 280000 rem, ant cl1 >>> 04 03 93 20 08 <<< 80 08 8804cb8ccb 280000 rem, sel cl1 >>> 04 08 9370 8804cb8ccb 28 <<< 80 06 04 da17 080000 rem, ant cl2 >>> 04 03 9520 08 <<< 80 08 1a432880f1 280000 rem, sel cl2 >>> 04 08 9570 1a432880f1 28 <<< 80 06 00 fe51 080000 docid018669 rev 10 61/72 CR95HF examples of CR95HF command code to activate nfc forum and iso/iec 15693 tags 71 rem, all commands below are sent using parity framing mode option which defines the parity bit value coming with data byte. rem, all commands byte including crc are sent or received in format data byte parity byte. rem, special case occur when receiving single nibble for ack (9004 0a 2400) or nak (9004 0y 2400) where ?y? depends on error code. rem, row0 sn0 sn1 sn2 bcc0 rem, read row0 option (cmd crc1 addr crc1 crc2) parity automatically included rem, response result code length data status >>> 04 05 30 00 02 a8 08 <<< 80 15 04 cb 8c cb 1a 43 28 80 f1 48 00 00 e1 10 12 00 cf2f 080000 rem, read row0 option parity framing (cmd crc1 addr crc1 crc2) parity specify after each byte rem, response result code length data (data byte+parity byte) status >>> 04 09 30 80 00 80 02 00 a8 00 18 <<< 80 27 04 00 cb 00 8c 00 cb 00 1a 00 43 00 28 80 80 00 f1 00 48 80 00 80 00 80 e1 80 10 00 12 80 00 80 cf 80 2f 00 080000 rem, read row0 option parity framing (cmd crc1 addr crc1 crc2) with error in parity rem, response result code length data (data byte+parity byte) status rem, nack rem, CR95HFdll_stcmd rem, CR95HFdll_stcmd rem, read row1_9 option parity framing (cmd crc1 addr crc1 crc2) parity specify after each byte rem rem, row1 sn3 sn4 sn5 sn6 >>> 04 09 3080 0100 8b80 b900 18 <<< 80 27 1a00 4300 2880 8000 f100 4880 0080 0080 e180 1000 1280 0080 0100 0380 a080 1000 1880 7a00 080000 rem, row2 bcc1 internal lock byte0 lock byte1 >>> 04 09 3080 0200 1000 8b80 18 <<< 80 27 f100 4880 0080 0080 e180 1000 1280 0080 0100 0380 a080 1000 4480 0380 0b00 d180 a580 4c00 080000 examples of CR95HF command code to activate nfc forum and iso/iec 15693 tags CR95HF 62/72 docid018669 rev 10 rem, row3 ccfile magic e1 ver 10 mmy size 12 access 00 >>> 04 09 3080 0380 9980 9a80 18 <<< 80 27 e180 1000 1280 0080 0100 0380 a080 1000 4480 0380 0b00 d180 0100 0700 5580 0100 8880 1300 080000 rem, row4 first tl (t01 pro pl3v) >>> 04 09 3080 0400 2600 ee80 18 <<< 80 27 0100 0380 a080 1000 4480 0380 0b00 d180 0100 0700 5580 0100 7300 7480 2e80 6380 5a80 2a00 080000 rem, row5 second tlv ndef msg (t03 l 0b v www.st.com) >>> 04 09 3080 0580 af80 ff80 18 <<< 80 27 4480 0380 0b00 d180 0100 0700 5580 0100 7300 7480 2e80 6380 6f80 6d00 fe00 0080 3f80 8500 080000 rem, row6 second tlv ndef msg ( t v www.st.com) >>> 04 09 3080 0680 3400 cd00 18 <<< 80 27 0100 0700 5580 0100 7300 7480 2e80 6380 6f80 6d00 fe00 0080 0080 ff80 0080 ff80 3f80 f680 080000 rem, row7 secobd tlv ndef msg (t v www.st.com) >>> 04 09 3080 0700 bd80 dc00 18 <<< 80 27 7300 7480 2e80 6380 6f80 6d00 fe00 0080 0080 ff80 0080 ff80 4500 7300 7300 6100 4880 cb00 080000 rem, row8 third tlv terminator (t v fe 00) >>> 04 09 3080 0800 4a00 2480 18 <<< 80 27 6f80 6d00 fe00 0080 0080 ff80 0080 ff80 4500 7300 7300 6100 0080 ff80 0080 ff80 f080 4b80 080000 rem, row9 read scratch pad >>> 04 09 3080 0980 c380 3580 18 <<< 80 27 0080 ff80 0080 ff80 4500 7300 7300 6100 0080 ff80 0080 ff80 4500 4600 2000 5400 9a80 4880 080000 rem, write row9 option parity framing (cmd crc1 addr crc1 crc2) parity specify after each byte docid018669 rev 10 63/72 CR95HF examples of CR95HF command code to activate nfc forum and iso/iec 15693 tags 71 rem, response result code length data (data byte+parity byte) status rem, row9 write scratch pad (ack) >>> 04 11 a200 0980 aa80 5580 aa80 5580 2900 7d80 18 <<< 90 04 0a 240000 rem, row9 read scratch pad >>> 04 09 3080 0980 c380 3580 18 <<< 80 27 aa80 5580 aa80 5580 4500 7300 7300 6100 0080 ff80 0080 ff80 4500 4600 2000 5400 1780 b480 080000 rem, row9 write scratch pad (ack) >>> 04 11 a200 0980 0080 ff80 0080 ff80 c800 2780 18 <<< 90 04 0a 240000 rem, row9 read scratch pad >>> 04 09 3080 0980 c380 3580 18 <<< 80 27 0080 ff80 0080 ff80 4500 7300 7300 6100 0080 ff80 0080 ff80 4500 4600 2000 5400 9a80 4880 080000 rem, select sector 0 (nack) >>> 04 09 c200 ff80 c200 e880 18 <<< 90 04 00 240000 break >>> CR95HFdll_reset_spi <<< 8000 >>> CR95HFdll_echo <<< 5500 >>> CR95HFdll_idn <<< 00 0f 4e46 4320 4653 324a 4153 5434 002ace d.1.5 nfc forum tag type 4a **** CR95HF code example to support nfc forum tag type 4a (14443-a) & ndef message rem, 14443b (CR95HF protocol selection 14443_a ) rem, first byte 01 in CR95HFdll_stcmd is only requested by CR95HF development sw examples of CR95HF command code to activate nfc forum and iso/iec 15693 tags CR95HF 64/72 docid018669 rev 10 ********** CR95HF setting to support extended frame waiting time ********** >>> CR95HFdll_stcmd, 01 020402000180 <<< 0000 rem, optimization of synchronization between digital and analog inputs by adjusting timerw value (default 0x52, min. 0x50, max. 0x60). recommended value is 0x56 or 0x58 for nfc forum tag type 1 (topaz). >>> CR95HFdll_stcmd, 01 09043a00 58 04 <<< 0000 rem, recommended modulation and gain is 0xd1 or 0xd3 for nfc forum tag type 1 (topaz). >>> CR95HFdll_stcmd, 01 0904680101 d1 <<< 0000 rem, last byte x7 or x8 in CR95HFdll_sendrecv command number of bit in the 14443 _type a frame >>> CR95HFdll_anticolselect123 ------ iso14443-a starting anticollision algorithm ------ iso14443-a reqa >>> CR95HFdll_sendrecv, 26 07 <<< 80 05 0400 280000 iso14443-a anticol 1 >>> CR95HFdll_sendrecv, 9320 08 <<< 80 08 08192d a29e 280000 iso14443-a select 1 >>> CR95HFdll_sendrecv, 937008192da29e 28 <<< 80 06 20 fc70 080000 --> uid = 192da29e , tag selected ------ iso14443-a end of anticollision algorithm ------ *** iso14443a_4 rats/ats (bit rate capability/fdt/cid usage) >>> CR95HFdll_sendrecv, e050 28 <<< 80 0a 057833b003 a0f8 080000 ****** iso14443a_4 pps (protocol parameter data rate) >>> CR95HFdll_sendrecv, d01100 28 docid018669 rev 10 65/72 CR95HF examples of CR95HF command code to activate nfc forum and iso/iec 15693 tags 71 <<< 80 06 d0 7387 080000 ** iso14443_4 apdu (command & reply are using iblock format, prolog information (apdu) epilog) *** 7816_ apdu format (class instruction, param , length cmd data length expeted) *** last byte 28 is a control byte to request CR95HF to automatically happen crc as epilog *** in response first 2 byte 80 xx and last three bytes 08 0000 are CR95HF's control bytes *** detect & access ndef message *** select application by name >>> CR95HFdll_sendrecv, 02 00 a4040007d2760000850100 28 <<< 80 08 02 9000 f109 080000 ******************* select cc file by name >>> CR95HFdll_sendrecv, 03 00 a4000002e103 28 <<< 80 08 03 9000 2d53 080000 ******************* readbinary cc (offset le) >>> CR95HFdll_sendrecv, 02 00 b000000f 28 <<< 80 17 02 000f1000ff00ff0406000100ff0000 9000 b755 080000 ******************* select ndef msg by identifier 0001 >>> CR95HFdll_sendrecv, 03 00 a40000020001 28 <<< 80 08 03 9000 2d53 080000 ******************* readbinary ndef msg (msg length offset 00 2 bytes) >>> CR95HFdll_sendrecv, 02 00 b0000002 28 <<< 80 0a 02 0015 9000 abb3 080000 ******************* select ndef file by name >>> CR95HFdll_sendrecv, 03 00 a40000020001 28 <<< 80 08 03 9000 2d53 080000 ******************* readbinary ndef (msg offset 02 , 20 bytes) examples of CR95HF command code to activate nfc forum and iso/iec 15693 tags CR95HF 66/72 docid018669 rev 10 >>> CR95HFdll_sendrecv, 02 00 b0000215 28 <<< 80 1d 02d101115402656e4d32344c52313620747970652034 9000 25c5 080000 *** header d1 type 01 payload 11 type 54 status 02 english 656e , msg : m24lr16 type d.2 iso/iec 14443 type b d.2.1 nfc forum tag type 4b **** CR95HF code example to support nfc forum tag type 4b (14443-b) & ndef message rem, check CR95HF setting & protocol selection rem, field off rem, first byte 01 in CR95HFdll_stcmd is only requested by CR95HF development sw >>> CR95HFdll_stcmd, 01 02020000 <<< 0000 rem, 14443b (CR95HF protocol selection 14443_b >>> CR95HFdll_stcmd, 01 020403010180 <<< 0000 rem, 14443b optimization CR95HF analog configuration for 144443 (0x30) >>> CR95HFdll_stcmd, 01 090468010130 <<< 0000 rem, access to nfc forum tag type 4b rem, reqb 0x 050000 + crc_b (apf afi param (slot0)) rem, reply atqb 0x50 4bytes 4 bytes 3 bytes + crc_b (pupi applidata protocol info) rem, reply from CR95HF 80 0f 50aabbccdd30abab010081e1ae00 00 rem, 80 response ok, 0f nb byte response including tag reply and the ultimate CR95HF status byte 00 (reply ok) rem, tag reply 50aabbccdd30abab010081e1ae00 rem, response code 50 rem, pupi aabbccdd rem, afi 30 access control docid018669 rev 10 67/72 CR95HF examples of CR95HF command code to activate nfc forum and iso/iec 15693 tags 71 rem, crc_b(aid) abab rem, nb appli (1) 01 rem, prot info byte1 00 (106 kbps both direction) rem, prot info byte 2 81( frame max 256 bytes iso compliant) 0081e1ae0000 rem, prot info byte 3 e1 (max frame wait time 4.9 ms appli proprietary cid supported) rem, crc_b ae00 rem, 14443_3 rem, reqb .... >>> CR95HFdll_stcmd, 01 04 03 050000 <<< 80 0f 50aabbccdd30abab010081e1 ae00 00 rem, attrib 0x1d pupi 1byte 1byte 1byte 1 byte + crc_b (1d identifier param1 param2 param3 param4) rem, param1 00 use default tr0 tr1 use eof rem, param2 07 max frame size 106 kbps up & dwn link rem, param3 01 iso14443 compliant rem, param4 08 cid (8) card identifier rem, reply CR95HF 80 04 18ebc3 00 rem, 80 response ok 04 nb byte response including ultimate byte 00 CR95HF reply ok rem, reply 10f9e0 coefbufferlength 1 cid 1 + crc_b rem, attrib ....cid0 >>> CR95HFdll_stcmd, 01 04 09 1d aabbccdd00070100 <<< 80 04 10 f9e0 00 rem, 14443_4 , cid not used rem, apdu for ndef management rem, command format (inf) cla ins p1 p2 lc(optional) data(optional) rem, response (optional ): body (optional) sw1 sw2 rem, block format prolog info epilog ( 02 [cid] [nad] [inf] crc_b ) examples of CR95HF command code to activate nfc forum and iso/iec 15693 tags CR95HF 68/72 docid018669 rev 10 rem, sequence lecture ndef ( for all following commands crc_b is automatically appends by CR95HF) rem, select application suivant la version du tag (100) >>> CR95HFdll_sendrecv, 02 00 a4 040007d2760000850100 <<< 80 06 029000296a 00 rem, response 90 00 ok rem, response 6a 82 application not found rem, select cc >>> CR95HFdll_sendrecv, 03 00 a4 0000 02 e103 <<< 80 06 03 9000 f530 00 rem, read cc >>> CR95HFdll_sendrecv, 02 00 b0 0000 0f <<< 80 15 02 000f1000ff00ff0406000110020000 9000 e7fa 00 rem, select ndef 0001 >>> CR95HFdll_sendrecv, 03 00 a4 0000 02 0001 <<< 80 06 03 9000 f530 00 rem, read msg length >>> CR95HFdll_sendrecv, 02 00 b0 0000 02 <<< 80 08 02 0013 9000 53aa 00 rem, select ndef 0001 >>> CR95HFdll_sendrecv, 03 00 a4 0000 02 0001 <<< 80 06 03 9000 f530 00 rem, read message >>> CR95HFdll_sendrecv, 02 00 b0 0002 13 <<< 80 19 02 d1010f5402656e557365204352393548462021 9000 8571 00 d.3 iso/iec 18092 d.3.1 nfc forum tag type 3 rem, CR95HF code example to support nfc forum tag type 3 rem, test inventory iso/iec 18092 rem, rfoff >>> CR95HFdll_stcmd, 01 02020000 <<< 0000 docid018669 rev 10 69/72 CR95HF examples of CR95HF command code to activate nfc forum and iso/iec 15693 tags 71 rem, select protocol 14443c >>> CR95HFdll_stcmd, 01 02020451 <<< 0000 rem, iso/iec 18092 new modulation and gain 0x50 >>> CR95HFdll_stcmd, 01 090468010150 <<< 0000 rem, iso/iec 18092 enable autodetect filter to synchronize nfc forum tag type 3 with CR95HF device >>> CR95HFdll_stcmd, 01 09040a0102a1 <<< 0000 rem, reqc 00 ffff 00 00 (command code system code no request slot 0) rem, atqc 80 12 01 010102148e0db413 (manuf id) 100b4b428485d0ff (manuf parameter) >>> CR95HFdll_stcmd, 01 04 05 00ffff0000 <<< 80 12 01 010102148e0db413 100b4b428485d0ff 00 d.4 iso/iec 15693 d.4.1 iso/iec 15693 tag rem, test tag iso/iec 15693 (lr family) rem, protocol selection up link ask 30% coding 1/4 rem, down link single sub carrier high data rate rem, inventory one slot rem, command protocol select 02 02 01 05 rem, protocol selection >>> CR95HFdll_stcmd, 01 02020105 <<< 0000 rem, modification of indexmod & gain in analog value register @69_index1 0x50 >>> CR95HFdll_stcmd, 01 0904680101 50 <<< 0000 rem, inventory 1 slot >>> CR95HFdll_stcmd, 01 0403 260100 examples of CR95HF command code to activate nfc forum and iso/iec 15693 tags CR95HF 70/72 docid018669 rev 10 <<< 80 0d 0000b7100128b42102e0 66cc 00 rem, getsystem info rem, flags, uid e00221b4280110b7 dsfid 00 afi 00 memorysize 3f blocksize 03 ic reference 21 >>> CR95HFdll_sendrecv, 022b <<< 80 12 00 0f b7100128b42102e000003f03 21 dfb0 00 rem, test tag iso/iec 15693 (dual family) rem, protocol selection up link ask 30% coding 1/4 rem, down link single sub carrier high data rate rem, inventory 1 slot rem, command protocol select 02 02 01 05 rem, protocol selection >>> CR95HFdll_stcmd, 01 02020105 <<< 0000 rem, modification of indexmod & gain in analog value register @69_index1 0x50 >>> CR95HFdll_stcmd, 01 0904680101 50 <<< 0000 rem, inventory 1 slot >>> CR95HFdll_stcmd, 01 0403 260100 <<< 80 0d 00ff07062092132c02e0 3d22 00 rem, getsystem info rem, flags ,uid e0022c1392200607 dsfid ff afi 00 memorysize 07ff blocksize 03 ic reference 2c >>> CR95HFdll_sendrecv, 0a2b <<< 80 13 00 0f 07062092132c02e0 ff 00 ff07 03 2c 984d 00 docid018669 rev 10 71/72 CR95HF revision history 71 revision history table 40. document revision history date revision changes 30-mar-2011 1 initial release. 08-sep-2011 2 removed ssi_2 pin. 26-oct-2011 3 upgraded document from preliminary data to full datasheet. 28-oct-2011 4 updated device revision information. added section 6.2: dc characteristics on page 40 and updated section 6.3: power consumption characteristics on page 40 . 06-jan-2012 5 updated table 12: list of CR95HF 72/72 docid018669 rev 10 important notice ? please read carefully stmicroelectronics nv and its subsidiaries (?st?) reserve the right to make changes, corrections, enhancements, modifications, and improvements to st products and/or to this document at any time without notice. purchasers should obtain the latest relevant in formation on st products before placing orders. st products are sold pursuant to st?s terms and conditions of sale in place at the time of o rder acknowledgement. purchasers are solely responsible for the choice, selection, and use of st products and st assumes no liability for application assistance or the design of purchasers? products. no license, express or implied, to any intellectual property right is granted by st herein. resale of st products with provisions different from the information set forth herein shall void any warranty granted by st for such product. st and the st logo are trademarks of st. all other product or service names are the property of their respective owners. information in this document supersedes and replaces information previously supplied in any prior versions of this document. ? 2014 stmicroelectronics ? all rights reserved |
Price & Availability of CR95HF
 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|
|
All Rights Reserved © IC-ON-LINE 2003 - 2022 |
| [Add Bookmark] [Contact Us] [Link exchange] [Privacy policy] |
|
Mirror Sites : [www.datasheet.hk]
[www.maxim4u.com] [www.ic-on-line.cn]
[www.ic-on-line.com] [www.ic-on-line.net]
[www.alldatasheet.com.cn]
[www.gdcy.com]
[www.gdcy.net] |
