TRF7961: problem in reading data more than 9 bytes

Hello Devendra,

First off, SLOC247 is not one of our NFC collateral pieces, so I am not sure what you are actually referencing. Maybe SLOA227 or SLOC297?

The process you are describing with getting a 0x80 and 0x60 is good to that point, but I am not so sure about the rest. Clarifying the firmware base you are reference would be important here so I can check exactly what is done in our provided code and explain.

I agree that the 0x46 or 0x42 is not good to get back and doesn't make sense, I suspect something that is not handled quite right is causing that.

The IRQ would go low after the first read of 0x60 and not rise again until the 0x40 is supposed to be reported.

Please help clarify the firmware so I can investigate further.

Hi Ralph,
You are right. I Typed the wrong name. The reference firmware I'm using is SLOC297. Still I'm getting 0x42 and 0x46 and sometimes 0x56 also. Also another question if we get a separate interrupt after 0x60 why is there a need to poll the irq pin in the do while loop used in the interrupt handler.

Regards
Devendra

Hello Devendra,

The polling for the IRQ pin shouldn't be causing the issue you are describing. If you are using SLOC297 Version C, you have the latest code, and so I assume the do while loop is the one inside of TRF79xxA_irqHandler right?

If so the IRQ handler would exit when the IRQ pin remains cleared after processing the IRQ. The reason for this is because we do not want an interrupt to trigger to disrupt the handling of the initial IRQ, and don't want to miss on a subsequent IRQ. So by using the do while loop, this allows the IRQ to be processed without another IRQ interrupt disrupting the processing, but also allows for the IRQ pin to be checked for a second interrupt immediately after the first is processed.

Do you have a logic state analyzer, or at least an oscilloscope that can decode SPI data and show time intervals between packets? This would be easiest to solve by seeing the communication on the SPI lines, particularly the timing between events.

Hello Ralph, 

Yes I'm using the SLOC297 version C. I have taken screenshots of oscilloscope as that is the only tool i have. Images are attached.

The command Sent is "get system information command(2B)" which expects a response of 15 bytes. 1st byte is FLAGS byte. 2nd byte is INFO FLAGS byte. 3rd byte to 10th byte is the UID. 11th is DSFID, 12th is AFI. 13th and 14th are memory information byte and 15th is IC info byte.

These images are arranged in order. The pink probe is the IRQ line , the Yellow is the clock and the blue is the MISO line.

All the images are expanded version of the of the zoomed out portion shown at the top of every image.

As we can see from the zoomed out part the TRF7960 is pulling the interrupt line high 3 times. The first time it is doing for 0x60 as can be seen from the first image. After that the next 4 images show the 9 bytes of data being read which is correct as i have checked. It gives the first 7bytes of UID which matches with the UID of the card.

The 5th image shows the next interrupt which results from IRQ status register value of 0x42 which can read from the middle portion in the MISO line.  From Image 6 You can see that after the 0x42 is read out the interrupt line is again pulled high. But we enter into the collision detection portion of the interrupt handler ( due to receiving 0x42 )in which we first send the the STOP decoders command(0x16|0x80). after that we reset the FIFO with reset FIFO command(0x8F). And finally we read out the status register to clear it(0x6C). From Image 7 you can see the value received in the IRQ register after 3rd interrupt is 0x40  which is of no use now as we have already processed the collision detection portion of the interrupt handler in which  we have stopped the decoders, cleared the fifo and cleared the status register.

Could you help me to resolve this

Regards 

Devendra

Hello Devendra,

The RX IRQ's look far too long. The amount of time to service an IRQ should not differ from TX and RX operations:

It takes about ~20 microseconds for the the IRQ line to return to low in our example. I am not sure what the time interval is in yours, and 20 microseconds is very fast handling, but it looks like your situation it is taking too long.

Given I cannot recreate this issues, that what I believe is causing your problem, please see if you can shorten the time to service IRQ on RX - especially the 2nd IRQ for 0x40 which has the longest time until being serviced, and see if you get proper operation.

Hello Ralph,

The time taken for IRQ line  to go from high to low in my case is ~10 us  which is what is expected i guess. So i dont think that is the issue. But one thing that I see different in my case and the image that you have attached is the difference b/w occurence of 0x60 and 0x40 interrupts. From your image i can see that these occur 1-2 ms apart. But in my case the time difference bw 0x60 and 0x42 (which is what i'm getting not 0x40) is 80 -100 us which is atleast 10 times less than in your case. Which means that TRF7961 is sending the second interrupt too early. Could this be causing the issue. 

Regards 

Devendra

Hello Devendra,

I see, I think I didn't fully understand the order of your images on my end either which is my mistake as you explained it well.

The speed of the second interrupt is quite fast... I am not certain for sure what may be causing that, but typically those kinds of issues end up being a result of the device not being configured or started up properly.

For your system, do you use both EN and EN2? Did you make any changes to the startup sequence?

Additionally the TRF7961 is slightly different from the TRF796xA devices that code has been tested on, and in general we recommend using the TRF7962A for ISO15693 applications. Would it be possible for you get a few samples of that and test that device as well? There could be a system specific issue with the combination of a non-MSP430 MCU and using the TRF7961 that has not come up before. I haven't supported non-MSP430 applications for the TRF7961 in the 5 years I've worked on these products... and it's not uncommon to see some initial growing pains with non-TI MCU's that are difficult for us to debug because we cannot recreate them with our setup.

Hopefully it's just due to the start-up sequence though.

Hi Ralph,

I think we use only EN as we are not using TRF7961 to provide clock to the mcu. Anyways I'm attaching the schematic of TRF7961 used in our system, you can take a look at that. I used the startup sequence as mentioned in SLOC297 anyways I will send the configuration code snippet tomorrow as i have already left the office today. Also I will talk to my superiors about the use of TRF7962A.

TRF_schematic.pdf

Best regards 

Devendra

Hello Devendra,

Thank you for sharing the schematic.

The matching network has a number of inconsistencies that will impact performance. It's not definite those changes also are causing this issue, but it's possible, and just in general they will negatively affect read range:

1) C711 and C713 should be 1500pf
2) C710 should 10pF
3) C716 should be 27pF

The matching network was designed to maximize performance and has been used by 100's of customers with success, so please revise that.

The other portion which may be more directly related to the issue is the resistors on the SPI and IRQ lines, I am not sure what impact that may be having but on our systems we don't need extra resistance and definitely do not need pull up or pull down resistors on those lines. I presume the tri-state buffers are to have multiple SPI devices on the same bus, but beyond that, there is a lot of extra components. And the pull up on IRQ needs to be removed. I would recommend de-populating R702 and see if you get the same behavior.

Hi Ralph,

I will ask my hardware team to make changes to the schematic you mentioned in previous reply . Meanwhile I made a weird observation today i am getting correct output sporadically when i wiggle the tag around the TRF7961. I put a break inside my code for whenever i get the correct output and started a counter to check the no of counts before i get the correct output. There is no fix time for getting the correct output. Sometimes i get it in the 3rd iteration or sometimes in the 30th or sometimes in the 100th. Does this observation helps you to diagnose the issue? I dont think its a firmware issue as i get the correct output sometimes. Could it be a issue with the antenna or some other hardware ? 

Below mentioned is my startup sequence and command which i am doing continuously inside a loop.

This part is the setup for ISO15693

g_sTrfStatus = TRF_IDLE;

//soft init command 

send_command(0x83); //14
//idle command
send_command(0x80); //15

// put 1 ms delay
delay(1);

send_command(0x8F); //17

write_a_register(0x09, 0x01); //18
write_a_register(0x0B, 0x01); //19

write_a_register(0x00, 0x20); //20

write_a_register(0x01, 0x02); //21
write_a_register(0x09, 0x01); //22
write_a_register(0x07, 0x15); //23
write_a_register(0x08, 0x1F); //24

 delay(20); //25

 

This part is for sending the command

buf[0] = 0x8F;
buf[1] = 0x91; // send with CRC
buf[2] = 0x3D; // write continuous from 1D
buf[5] = 0x02; // ISO15693 flags
buf[6] = 0x2B;

size = 0x02;

buf[3] = (char) (size >> 8);
buf[4] = (char) (size << 4);

SpiRawWrite(&buf[0], 7);

TRF79xxA_waitTxIRQ(5);
TRF79xxA_waitRxIRQ(15);

 

I'm doing this continuously inside the loop to coomunicate with a single RFID tag

 

 

Best Regards

Devendra Singh

Hello Devendra,

How much time are you delaying between turning the RF field on and sending the command to the tag?

How much time is there between cycles?

Are you resetting the device and re-configuring it every cycle?

Hi Ralph,

I am having a delay of 20 ms between turning the rf field on and sending the command. There is no time between cycles once i get the response from TRF7961. Yes I am turning off the RF at the end of the cycle and restarting it again at the begining of the cycle. I'm reconfiguring the device every cycle.  The only delay i'm having between cycles is the delay for receiving RX interrupt which is 15 ms as mentioned in the Reference code of TI. I am using these two routines which are mentioned in the Reference firmware TRF79xxA_waitTxIRQ(5);TRF79xxA_waitRxIRQ(15) to wait for the RX and TX interrupts. Once i receive them i'm instantly going back to the start of new cycle and again configuring the device for ISO 15693 mode as mentioned in the startup sequence in my previous email. Is anything wrong with that approach? I did that because i wanted to make sure that at least one command is working perfectly and then i will implement the others.  

Best Regards 

Devendra

Hello Devendra,

I would suggest the following tests:

1) Try other ISO15693 commands, both ones that need more than 9 bytes in reply, and ones that need less. Inventory and Read Single Block would be good options for this. If Get System Information is the only command that has an issue, it could be tag related.

2) Try turning off the RF field at the end of the loop and then adding another 10-15 ms delay before it goes back to reset the device. This will slow down the process and also allow the tag to reset as well. Usually you would not have the device just constantly oscillating between resetting and transmitting as that is not standard communication, so the loop could be influencing this.

3) Make the recommended hardware changes and be sure to test with multiple tags as well. Sometimes tags from different vendors perform differently.

Beyond those suggestions, there is not a lot else I can really offer for guidance given the system setup is with an MCU I don't have access to so I can't do any testing on my end. As a whole your software seems fine aside from possibly the endless loop the device is going into, but the hardware concerns need to be addressed. But ultimately if none of those resolve the issue, I don't have further ideas as usually what I see in cases like this are software-based issues that are not present since you have been following SLOC297 closely. If it ends up being system specific, since I cannot re-create the system setup, I can't help much.

Hopefully one of the above recommendations solves this case.

Hi Ralph,

Thank you for your excellent support. I would definitely try these three suggestions. Hopefully these may resolve my issue.
Have a great weekend. Cheers!!


Regards
Devendra