TRF7970A - ChipStatusControl REG and RFon bit - how it works?

Your understanding of bit 5 is correct.  The RF field should turn off completely when set to 0.  I tested this by changing this register from 0x21 to 0x01 with the TRF7970AEVM.  Can you confirm that the register was written succesfully, by reading it back?

Hi Eddie, thanks for the reply, 

I've tested again now and I still had the same result. My own board start the TRF7970A setting it up for the ISO14443A setting the chipStatusControl reg to 0x29. I've just tried to change it to 0x01 and read it back to check, and I've read 0x01 but the RF field is still present on the antenna.

All the other features of the TRF7970A are working correctly so I may exclude an hardware problem I think.

I wanted to achieve the possibility to power off the RF field manually, and in these last days I had to put the TRF into standby mode as workaround.

I tested with the EVM going from 0x29 to 0x01 and the field also succesfully turned off.  Have you seen this same issue with multiple TRF7970A chips?  Can you provide your schematic? 

It's a prototype board and I can't do the test on multiple TRFs. I've followed exactly the same schematic found in the datasheet.

In the next days I will try to change the TRF with another one, I don't know...

tested with mulitple parts, multiple times - it (the transmitter) always turns off when making b5 a 0 in the CSC register

I've just changed the TRF on my prototype board with a new one and I still have the same issue. I'm following this schematic:

I've the 13,56MHz sine wave at point A (about 25Vpp) and while checking it with my oscilloscope I may write the CSC register from 0x21 to 0x01, reading it back and the sine wave will be still present, rather than go to zero volts as I expect to see.

The TRF is working at 5V, with 3.3V I/O

I've found a software workaround for this problem but I still don't know why I'm the only one who have such issue.

Anyway it's not a priority issue, so I don't care so much about it, but I will be curious to know if some other ppl have the same problem.

Regards

Axxe -

do you have any screen captures of the register reads and writes? you may not consider it a priority and i appreciate that, but it seems that this should be working for you - so would like to help. also, what does rest of ckt you are using look like? any pix or drawings you have might help.

Hello Axxe,

I tried to reproduce your issue, but I am not able to get your result.

I wrote a little test application to verify your issue on my prototype where the workflow is :

1.) Direct Command for RF Initial Collission avoidance -> carrier sense + RF On

2.) Start Timer 20ms and wait for timer expiration

3.) Read Chip Status Control Register (0x00)

4.) Set rf_on = 0

5.) Write back Chip Status Control Register (0x00)

6.) Start Timer 20ms and wait for timer expiration

As you can see in the attached oscilloscope image, the rf field switches on/off every 20ms.

I am not sure if my case is compareable to yours as I am  going to use the TRF as NFC Initiator/Target device.

What steps do you perform before you try to turn off the rf-field?

Kind Regards

Marco

Hi Josh and Marco, 

first of all I wish to ask what kind of crystal are you using during those test? 13,56MHz crystal or 27,12MHz ?

I've just tried to do these steps:

-TRF is powered off (EN=0 EN2=0)

-I start powering On the TRF with " EN2=1 delay(5ms)... EN=1"

-at this moment i'm able to read all the registers, there is no RF field on the antenna.

-im using a 13,56MHz crystal, so the first thing i'm going to change is the "MOD and SYSclock register (0x09)" from 0x91 to 0x01 (13,56MHz crystal, ASK 100% and no clock output)

-at this point the 13,56MHz sine wave is present on the antenna, even if the ChisStatusControl register is still in its default value 0x01, shouldn't it be something wrong??

I'm using my own GUI to control the TRF through USB, and I'm able to read/write registers, send commands, so If any of you wanna try to help me, suggest me any procedure to try, and I will let you know in real time.

Thanks for the support.

Thanks Marco, 

we replied at the same moment ;) so it's a EN2's issue.

Hi All,

I have an EVM TRF7960A development kit and TPR0520A vicinity cards which is supporting ISO15693-2 & ISO14443B-2 protocols.

Is it possible to read/write/detect  ISO 15693-2 vicinity cards using TRF7960A EVM?

Regards

Jethin

Jethin -

this description of the card sounds alot like an Inside Contactless PicoPass device - is that correct?  

ISO15693-2 and ISO14443-2 are the air interface portions of the standard, while the -3 portion of the standard covers the commands.

when tag IC vendors explicitly state -2 compliance and not -3, this means the tags might use the same air interface as mainstream cards, but they will have non-ISO standard commands that they respond to instead of what is specified in the ISO -3 part of the standard.

if you know the commands needed for the tags you are using and can write some code to support them - then yes, more than likely you can use the TRF79xx devices to interact with the card in question.

Thank you Wyatt

Previously i was using the Tag-it™ HF-I Plus tags which is working perfectly with TRF7960A EVM using the application RFIDread_REVA_EVM.exe. In that it was using the ISO15693 protocol for the RFID operations and works fine

Now I bought TPR0520A cards from INSIDE, believing that it will work with the TRF7960A EVM and RFIDread_REVA_EVM.exe. As I Mentioned previously this card is supporting ISO15693-2 and ISO14443-2 these two protocol. My question is Why TPR0520A cards is not working with this EVM? Is there any Protocol difference between ISO15693 and ISO15693-2? Or as you said I need to write separate application to communicate with the device using the TRF7960A EVM?

Regards

Jethin

The reason is because while the air interface (meaning the frequency of operation and the downlink\uplink protocols) might be the same here, but the ISO standard commands (this is the -3 portion of the standard in both cases (ISO15693 and ISO14443) are not being used. So this means that you would need to get the detailed DS including the commands they are using, then you should be in a position to then implement those commands in firmware. The TRF796xx / -7xx will/should be just fine to support that.

make sense? let us know - if you get stuck we might be able to help you out quickly.