ISO15693 Code for TRF7960TB with TM4C1294XL

Thank you very much, I will have a look at that. The problem is I have a design which is based on the TRF7960TB. Is the TRF7970A pin-compatible? If not I either have to redesign my board, port your example code for the TRF7970 or port the TRF7960EVM Code to the TIVA.

I got the DLP7970 running on my TM4C1294XL. It is working with the 14443A-Tag that comes with it, but I can find neither the 15693-Tag that was supplied nor my own Tags. If I check in the nfc_controller.c I always see a IRQ_STATUS_PROTOCOL_ERROR. Do I have to further adapt something in that example code to support ISO15693?

Hi Claudio,

If all you were to receive is a 0x80 for TX Complete, that would mean the tag did not reply. However, I suspect your breakpoint is set at a location within the NFC_waitForCommand function which does not allow it to properly wait for a reply from the tag while debugging, so the problem lies elsewhere.

It's going to be very hard to just track down the issue with descriptions - the best way for us to help with a situation as you described is to get Logic State Analyzer (or Oscilloscope) shots of the following lines: MISO, MOSI, SPI CLK, SS, and IRQ. Please include everything from the startup of the part to the point you present the ISO15693 tag so we can verify that everything has been initialized properly and then see which commands are issued to the tag and what, if any, replies are received.

dlp7970 debug.zip

Hi Ralph

Thanks for your help. I attached the scope shots. Sorry I only got a 4-channel scope with no logic analyzer, so I left the slave select out.The signals are:

MOSI - yellow

MISO - Magenta

CLK - Cyan

IRQ - Green

I added some debug Info in my code and printed out the transmitted data, so you dont have to guess them from the shots. They are in the text file.

Hope you can see something from this data.

Kind regards

Claudio

Hi Claudio,

Thanks, these are quite helpful. From what I can see it looks like the tag reply is not being detected by the TRF7970A and then the timeout of 10 ms is hit which would cause the 'protocol error' response to be triggered in order to allow the TRF7970A to reset and try again.

I will need to check with a colleague of mine who worked with the code example about why this might be the case, as ISO15693 should be supported fully.

In the mean time, could you also share the data logs and maybe a few screenshots of the packets being sent/received for ISO14443A which you said it working no problem? That might help us to track down what is causing ISO15693 specifically to have issues.

iso14443a.zip

Hi Ralph

I did some scope shots for the successful 14443A tag. I had to get the numbers from the scope shots, since with the logging it didn't work because of timing issues. For the 15693 I did it first without logging, so the timeout shouldn't origin there by the way. I hope you can see something there.

Kind regards

Claudio

Hi Ralph

I fixed the error with the 5V supply, but still no success with the 15693 tag.

By the way: I only activated the bISO15693_26_48kbps since the other mode is not supported. As far as I could see from the datasheet this should be o.k. for the Tag.It HF-I. Is this correct?

Kind regards

Claudio

Hi Claudio,

To add onto what Josh said, I am currently looking into the execution of the initialization prior to the command being issued and noticed some inconsistency based on what we would expect from that firmware and what you reported via the spi data.txt file.

One thing that is notably missing is changing register 0x09.

You mentioned having enabled the ISO15693 bit rate - and that is the correct one. Did you also turn on the ISO15693 flag above it as well?

• g_sRWSupportedModes.bits.bISO15693 = 1;

I'm still in the middle of comparing the expected sequence and yours to see what else might be off. I'll let you know if anything else seems to be wrong.

Hi Ralph and Josh

Yes, g_sRWSupportedModes.bits.bISO15693 is turned on.

Regarding the modulator register 0x09, there seems to be a bug in the code:

In TRF79x0_initiatorModeSetup() the Modulator is only set to 00K100%  for g_sTrf7970Status.sInitiatorMode.bits.bPassiveTypeA and g_sTrf7970Status.sInitiatorMode.bits.bActiveTypeA. I added g_sTrf7970Status.sInitiatorMode.bits.bPassive15693 there but still no success with the tag.

@Josh: register 0x00 should be 0x20 for 3V operation, not?

Scopoe shots and spi log coming soon.

Kind regards

Claudio

O.k., so here are the new log and scope shots.

There still seems to be no rx start happening.

iso15693_try2.zip

in your text log at the beginning i see some errors and the scope shots, it would be nice if you labeled them or had some legend. the one signal does not look very nice, maybe we can see a picture of your setup to understand what the root cause of that is. 

then, in the text log - you read register 0x09, and get a 0x91...this indicates you are using TRF7970ATB, not a TRF7960ATB  - which is it?

then you write a 0x00 to that register, where it should in this case be a 0x01 being written to the register 0x09

then you write a 0x21 to register 0x01???? this should be 0x02 being written. 

then you turn off the transmitter with a write of 0x00 to 0x00 and to be clear - on either the of the -ATB boards, they require 3.3VDC in and have an onboard boost converter which makes 5VDC, so always set the input VDC register setting to 5VDC

then you go back and write 0x01 to 0x09, and turn on TXer (but need to update to 0x21 please) and make ISO control register 0x02

then you send out single slot inventory command and get EOTX and clear it, but i don't see you doing the errata fix when sending one byte (for clearing the FIFO) by using dummy clock after you send the one byte direct command 0x8F. 

so - need to know if this is -60a or -70a, because the SPI is different between the two - seems like you are reading registers,  but if you are using a 60a and you got a 0x91 in register 0x09, this would be a problem...that would indicate your edges are not correct perhaps and leading to some bad data - 

you can also take an scope probe and make a pickup loop with the tip of it and the ground wire - then you should be able to see the HF field on and if triggered correctly and zoomed into the i think 20mSec per division or so, you should be able to catch the command being modulated out and decode it (or not, its pretty simple and if present at all, means you are to a certain point that most likely doing the fix above will cure and then allow the EORX to come in - you are using the IRQ line, too, correct? 

Hi Claudio,

Okay so we tested the firmware on one of our boards and compared the register sequences - beyond the issue we ID'd with the Voltage level everything else seems to be initialized fine. Based on your logs however, we are worried there is some issue with the IRQ pin.

We are a little unclear on specifically which hardware you are using, can you let us know which Evaluation platforms you are working with? Also which version of the DLP-7970ABP BoosterPack do you have (See this guide for help in identifying that: http://www.ti.com/lit/an/sloa226/sloa226.pdf )?

One thing we noticed in your most recent log is that you got two 0x80's for TX Complete, and neither of them were from an IRQ line being triggered. Were there any modifications made to the firmware in terms of how IRQ is being checked, or how the firmware is reading the FIFO Status Register? If you could list any changes you made to the firmware that was on the web before you tried to read the ISO15693 tags, that would be helpful.

Hi Ralph

I have a DLP7970ABP v4.3 together with a EK-TM4C1294XL Rev D. The DLP7970 is connected on Boosterpack1.

The missing IRQ signal was probably a mistake. Maybe the probe wasn't attached correctly. I'll check that again.
I didn't change anything in the interrupt or FIFO handling.

I didn't change anything in the nfclink-code, but we use our own task-handler instead of the RTOS. I'm calling the statemachine every 2s, so there should be no timing issue.

Kind regards

Claudio

Hi Ralph

I investigated a bit further. The TX_COMPLETE IRQ is read in the TRF79x0_irqHandler() of the write_FIFO() even without a pin interrupt. So no changes there.

But I found out some more which is documented in the txt.-File. I added more extensive comments for the scope shots in order to be easier understandable.

As far as I can see, there is a timing issue and the RESET_FIFO is sent before the IRQ signal goes high. can you verify that?

Kind reagrds

Claudio

iso16693_try3.zip