• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 16 subscribers
  • Views 812 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TRF7963A sanity check, getting no Rx

mslothy
Expert 1525 points
Other Parts Discussed in Thread: TRF7963A, MSP430F5438A, CC2520, TRF7960

Hello all,

I'm developing a driver for the TRF7963A RFID chip. It should be able to detect and communicate with
a single ISO 14443-2/3B tag, ie only single slot anti-collision needed.

Despite being able to transmit, I'm not getting any responses.

The transmission happens without a problem, I get the TX and no-response interrupts as expected, but
no RX interrupt.

I have two HW setups that I've tried this on: proprietary HW with MSP430F5438A and TRF7963A, and a TI development
board with RFID dev board according to the following (until I can reliably read tags on the TI dev boards
I won't move to the proprietary HW just in case).

The TI dev board setup is as follows: Trxeb-board using a msp430f5438a and a CC2520 radio. A TRF7960ATB dev board
mounted on a SmartRF06 dev board and jumper cables for SPI, IRQ, and EN. EN2 is fixed to ground. The board is
powered from the Trxeb, ie 3.3V.

I know the ISO protocol is picky and tags won't respond unless a correctly formed request is sent, and I follow
the ISO 14443B protocol. The WUPB I transmit looks like this:
0x05 WUPB magic byte
0x00 AFI == all families and sub-fam's.
0x08 Single slot WUPB, not extended ATQB

To send this WUPB I do the following.

I set ISO register to 0x0c, ie ISO14443B_106_KBPS (I've tried the high bitrate 14443B's as well),
then waited for 7 ms before writing the following over SPI:
0x8f reset
0x91 transmit with CRC
0x3d burst write to FIFO len reg
0x00 0 bytes
0x30 3 bytes len
0x050008 the WUPB

which follows every documentation I've found, and the example code.

At this point in time (just before the above SPI transaction), the registers have the following settings:

CHIP_STATUS_CONTROL 0x01
ISO_CONTROL 0x0c
ISO14443B_TX_OPTIONS 0x00
ISO14443A_HIGH_BIT_RATE_OPTIONS 0x00
RX_NO_RESPONSE_WAIT 0xff
RX_WAIT_TIME 0x01
MODULATOR_AND_SYS_CLK_CONTROL 0x10
RX_SPECIAL_SETTING 0x40
REGULATOR_AND_IO_CONTROL 0x87
IRQ_STATUS 0x00
COLLISION_POSITION_AND_INTERRUPT_MASK_REGISTER 0x3f
COLLISION_POSITION 0x00
RSSI_LEVELS_AND_OSCILLATOR_STATUS 0x40
TESTA 0x00
TESTB 0x00
FIFO_STATUS 0x00
TX_LENGTH_BYTE1 0x00
TX_LENGTH_BYTE2 0x00

No complex stuff. I relaxed the wait and no-response times to allow for slow tags, but no luck.

I've implemented and handles the five erratas found in SLOA140. And PLEASE, these are erratas and the document
should be named appropriately, not "Using the SPI interface with TRF7960"! This is really crappy, I (thought I had)
functioning SPI and hence didn't look in this document. Not until I saw it mentioned in a stray e2e thread did
I understand it was an errata document!
Namely:
SPI CLK polarity diff between reading and writing
IRQ status reg not cleared - now burst reading one byte more to clear it
Single-byte commands need an extra clock cycle - implemented, see screenshots
Wait, no-response defaults are bad - manually set to maximum relaxed setting as above
tx single byte - implemented the fix as described in the document

Now I'm at my wits end and am stabbing in the dark on what the error might be.
Can a TI rep please sanity check the register settings and my screenshots to see if my errata fixes are proper?
Any other clues/hints/suggestions?
Is it required to command stop decoders, start decoders as in some of the example code?

Unfortunately I have no access to RF analyzers to verify that anything is actually sent, but I have previously
communicated with both the 14443B tag and with a ISO15693 tag (Tag-it HF) but something has apparently changed.

More information: I'm not using the example code for a number of reasons. For one, this has to play well with
an OS and as such I cannot allow the driver to hold the CPU as in the example code.

Screenshots:

first, sending the WUPB

then we get a EOTX interrupt and read it out:

sending a command (here FIFO reset) includes the errata fix:

then we get the noresponse interrupt:

this is the time it takes for the device to transmit, from start of SPI to EOTX:

this is the time from EOTX to no-response:

  • 0
    Expert 1525 points

    Update: here I wrote about having received faulty TRF7960ATB-boards:

    http://e2e.ti.com/support/wireless_connectivity/f/667/p/321592/1321558.aspx#1321558

    but when running the code on the proprietary hw I'm still not seeing any rx interrupts. So the question still stands regarding the above, can someone sanity check it please?

    My gratitude for any help!

  • 0 in reply to mslothy
    Expert 1525 points

    Further investigations: I set ASK/OOK to debug output (B3 in reg Mod and sys_clk control/0x09) and measure with an oscilloscope.

    I set the ISO and wait a while for it to stabilize and any tag to receive power and bootup. Then, I send a WUPB. We can see this on the measurements.

    Here we can see the data transmission,

    Is my understanding correct that this debug output on the pin is the signal between the digital and the analog parts? Ie, I should be able to see both what I transmit, and what I receive from a PICC/tag?

  • 0 in reply to mslothy
    Expert 1525 points

    ....and here's the corresponding Subcarrier output on the MOD pin (through setting B6 in Test register A).

  • 0 in reply to mslothy
    TI__Guru* 90906 points

    try making Chip status control register 0x20 or 30 - this turns the transmitter on. 0x01 value you have listed is leaving it off

    also, just set the ISO control register and don't anticipate any timing needs - your setting of 0x0C is correct

    but if you want - here are what i am using with the -G2553 for Type B setup

     

    write[0] = 0x20; //write continuous, starting with register 0x00
    write[1] = 0x20; //full power out, 3.3VDC, register 0x00
    write[2] = 0x0C;//ISO14443B, register 0x01
    write[3] = 0x00;//default, register 0x02
    write[4] = 0x00;
    write[5] = 0xC1;
    write[6] = 0xBB;
    write[7] = 0x00; default, register 0x06
    write[8] = 0x0D; register 0x07
    write[9] = 0x07; register 0x08
    write[10] = 0x03;register 0x09, 8.5% mod depth (i see you are using 10%, also should be ok, if the tag you are using is compliant device)
    write[11] = 0x00;register 0x0A this setting works well for me - see note in TRF7963A data sheet - page 49
    write[12] = 0x87;//automatic regulator settings, register 0x0B

    you can also send 0x05 00 00 (this is single slot REQB) - in your case it makes no difference, but usually WupB is used after you send a Halt to the tag - no big deal really - response to either is still same ATQB

  • 0 in reply to Josh Wyatt
    Expert 1525 points

    Thanks for the suggestions Josh. The above problems turned out to be related to power. First, the faulty boards as described above, then I got the power supply working on the prop hw I have, so now the power is fine and I see that the tags do modulate the signal. I do get rx interrupts now, too. So that's good news.

    I have some further questions though, related to how to properly operate this chip. The example code, the datasheet, and various documents found in various threads here on e2e do suggest different methods.

    First, on end of TX irq, what is needed? Reset FIFO (0x87) I guess. Disable and immediately re-enable receivers (some example code did this)? Read out RSSI?

    Then, on RX irq, same thing, what is best operating practice? I do get the RX irq, but reading the length of data in the FIFO from the FIFO status register returns zero. No error is signalled. This is the supposed ATQB which should be 12 bytes long.

    For the above, assume ISO14443B. The tags I'm currently working with are simple in that aspect, simple 14443-2/3B and only 106kbps.

    Best, Marcus