NFCLink for ARM Cortex M based CPU

Hi Christopher,

What we have on the web currently for NFCLink NCI does not have the ARM support yet, but my understanding is that we do have a version internally which has ARM support that has not been released yet. What is your time frame to begin development with ARM+NFCLink?

Another option would be to port the firmware from our recently released Reader/Writer firmware which can be found in this app note: www.ti.com/.../sloa227.pdf

The firmware included has a build for MSP432 which is an ARM M4F, so you may find porting that much easier.

Hello Christopher,

We have also released a reference design using the code Ralph mentioned for the Reader/Writer NFC mode on a TM4C platform. The TM4C project will support TI-RTOS, which is not currently supported for the MSP430 solution. The NFC stack is the same for both projects so the application note Ralph referred you to will still apply to the TM4C design.

Wi-Fi Enabled IoT Node With NFC Connection Handover Reference Design:

For your application do you need to have a host configuring the NFC modes and being aware of the NFC events occurring on the ARM Cortex?

Best regards,

Erick

Hi Ralph,

many thanks for the link to the sloa227 stand-alone reader/writer FW.. I am just looking at the source code now and it seems that it is all that we need. We will only use Reader/Writer based on ISO15693. From what I can see we can use the MSP432 example as a base.

With regard to timeframe: we are in the middle of development, we have the custom board already (SPI up and running) and it is working. One of the next steps is to get the RFID reading/writing of tags operational.

I'll start now to get the source Code integrated. I'll report back as soon as I read a tag...

thanks again

Chris

Hi Erick,

there is only the ARM Cortex, no host. Our customer is quite strict on NDA, so let me try to explain the application without violating anything:
There is an appliance, that includes a replaceable component, that component includes the RFID tag. The applicance needs to be able to identify the component and detect when it was replaced. The component includes some data on the tag, type of component, ser. # etc. Some data needs to written to the component.

So we will be doing Reader/Writer based on ISO15693.

I am also looking at the tidcav8 Code, as you said it is the same stack. I'll let you know as soon as reading /writing a tag is working.

Many thanks! This is very helpful.

best regards
Chris

Hi Eric, hi Ralph,

in the meantime we manged to compile and run the code from sloa227 on our ARM Cortex design and we also fixed an issue where the SPI interface requires switching the clock polarity when receiving data from the TRF7962A.

We can connect to our board via the UART using the Ti NFC Tool Ver. 1.7. We click on "ISO15693" and hit "Start RW".

We can see the communication on the SPI Interface, the stack switches on the RF, we can measure the 13,56MHz nicely with a scope, but:

If we present a tag to the board nothing happens. We are actively debugging the sloa227 software using the Keil ARM IDE. It seems that for some reason the TRF7962A does not recognize the tag (Tag-it HF-I).

From studying the sloa227 code we would expect at least something in the stack to happen when a tag is presented, some interrupt register changing etc. We are aware of the fact, that there are some differences between the TRF7962A and the TRF7970A which need to be addressed some time later (our design only needs ISO15693).

So my question is: was the sloa227 code ever used on TRF7962A? What could cause the ..62A to do nothing when a tag is presented? Which registers would you recommend me checking on the ..62A when a tag is presented?

Help is much appreciated. I will keep debugging...

many thanks

Chris

Hello Christopher,

Here are a list changes recommended for porting the TRF7970A driver to the TRF7962A:

- In the TRF79x0_writeFIFO() change all the FIFO size of 127 to 12 (trf797x0.c lines 261, 263, 307, 316, 349, and 352).
- Change the mask of 0x7F to 0x0F for the FIFO low/high handling in lines (trf797x0.c lines 656, and 724) since the FIFO status register's lower four bits will represent the number of valid receive bytes.
- Registers 0x14 FIFO IRQ Level and 0x18 NFC Target Level should not be modified, thus comment out the functions writing to these registers. (Reg 0x14 trf797x0.c lines 1869, 2102 and 2256. Regf 0x18 trf797x0.c lines 1186, 2112, 2261, 2362, 2368, and 2374).

Please test the recommended changes and let me know if it allows to communicate with the tag.

Best regards,

Erick

Hi Erick,

thanks a lot for the hints on the Fifo size and other registers. I was about to compare bits of the 70A and the 62A. So you saved me quite some time.

I put your recommendations in the code. Furthermore I had to add some more fixes (see sloa140 and sloa155 documents) to get the direct commands working. Fifo status needs to be "anded" with 0x0f in oder to deliver the properly masked bits at a few places in the code.

I was debugging all day today, not fully successful yet. There are issues, with reading the Fifo status of the 62A. According to the Erratas and the datasheet: n-1 in the Fifo status means n bytes to read from the fifo.

How can I check when the fifo is empty? According to the datasheet fifo Status== 0 means 1 byte in the fifo to read.

I did some tests, after presenting a tag to the chip. I can see that the chip recognizes the tag by monitoring the SPI.

The first

TRF79x0_readSingle(&ui8FifoStatusLength, TRF79X0_FIFO_STATUS_REG)

returns 9 bytes in the fifo.

In order to get the fifo status to read "0" I have to read 11 bytes.

No tag data in the Ti NFC Tool yet.

I can give you much more details on where in the code I was debugging the day after tomorrow. (I am off to see the customer tomorrow).

thanks and best regards
Chris

Hello Chris,

Please send me the modified trf79x0.c so I can test it on our hardware.

Best regards,

Erick

Hi Erick,

thanks a lot for offering to look at the modified trf7970.c source code.

I made the following changes in the code:

- some fixes related to sloa140/155, marked with
  #define NFC_ERRATA_TRF7962A_FIXES  1

- some changes related to the different fifo size of the 62a
  #define NFC_CHIP_IS_TRF7962A  1

- redirecting the rfid isr
  #define R2D2_ISR_REDIRECT  1 (set to 0 for original Ti isr)

you will easily see the changes when you do a diff to the original file. There is one change in the .h file with regard
to the overflow bit.
Since I am using ARM's cmsis OS there are two "osDelay" in the code, you might just want to comment these out.

Here is where I currently stand with debugging:

In the function: TRF79x0_irqHandler I put a breakpoint on Line 663. I present a tag. I then step through the code
until the fifo is being read. When the fifo status is read again in line 714 it never returns zero, after some time this leads to
IRQ_STATUS_OVERFLOW because if((ui8FifoStatusLength) == 0x00) never becomes true and IRQ_STATUS_RX_COMPLETE will never be returned.

That is how far I got. I think that if we manage to get the "fifo empty" condition somehow from the 62a that would be helpful.

Please le me know if you need any other information.

Many thanks in advance
Chris

two files: the trf7970.c, trf7970.h

trf79x0.c

trf79x0.h

Hello Christopher,

Happy New Years!

I was able to get the code to select and read the content of a ISO15693 tag.

I had to make a few changes to the TRF7970A driver. When the TRF796x would receive more than 9 bytes, if we read the FIFO Status register after reading the FIFO it indicated more bytes were being received by setting bit 5 (value 0x2F).After some tests, I noticed the FIFO empty case was when the FIFO Status had a 0x0F. This meant that the code could not return RX_COMPLETE when the FIFO had 0 bytes as we previously had. Currently the RX_COMPLETE flag is only being returned when the IRQ Status has the value of 0x40.

Please test with the attached files and let me know if it works on your side. (I have also included the modified SPI file I used for the MSP430F5529)

/cfs-file/__key/communityserver-discussions-components-files/667/2742.trf79x0.h

/cfs-file/__key/communityserver-discussions-components-files/667/5556.trf79x0.c

/cfs-file/__key/communityserver-discussions-components-files/667/nfc_5F00_spi.c

Best regards,

Erick M.

Hi Erick,

I highly appreciate you getting back to me! I'll test that asap and let you know the outcome. Will be somtime beginnig of next week!

thanks!

Chris

Hi Erick,

sorry, it took me some time to get back to you. I included your fixes in the project code and I think it will solve the fifo issue. Unfortunately I seem to have some other problems, not necessarily related to your sample code. RSSI is always 0 and I keep getting 0x61 in the fifo status register, 2 bytes are being read then, then 50ms pause then 0x61 again. I have to put the Tag very close to the coil to even get a reaction.

Before anything else I have to go back to the trf7960 Eval Board and check the difference to our board. Tag recognition at the Eval B. is at approx. 3 inches there, stable.

For now, thanks for your help, it is much appreciated. I'll let you know as soon as this other problem is fixed.

best regards
Chris