Porting NXP NFC Reader Library to New MCU (KEA64)

[andrew_meessema]

Hello,

I have recently been using a CLEV6630B V2.0 (target MCU LPC1769) evaluation board to develop and test the RC663 NFC frontend. I first used NFC Cockpit to get it going and have since then moved onto using the NFC Reader Library and some example projects to get a grasp of what is going on. However, rather than using the evaluation board going forward, I am going to be using a KEA64 MCU, along with CodeWarrior.

For our application, we are just going to be scanning tags and receiving this data via SPI and buffering it to be processed and later sent elsewhere. Do not want to use OS for our application (no FreeRTOS or Linux) so NullOS will be used.

My questions and concerns are:

1. What NFC protocol should be used for this? After some consideration (as well as scanning Galaxy S10, NXP Sample Card, along with a Crystal Cube NFC tag), it looks as if it is only necessary to use ISO/IEC 14443 type A. Should I take out all other protocol abstraction layers from stack besides type A? Is it necessary to use any other protocols for just reading tag data?

-(somewhat a continuation of last question) What layers do I need from the NFC reader library if all I am going to do is initialize the frontend registers and read NFC tag data via SPI? I am thinking just parts of NxpNfcRdLib (AL MIFARE Classic phalMfc, RC663 HAL in phhalHw, phNfcLib, protocol abstraction for type A in phpal14443p3a). Is there anything else that should be ported over (in terms of source code)?

2. Since there is no OS (NullOS), is it still required to use OSAL based on how the library is written?

3. The initialization and register setup of the RC663 upon powering up. Are there certain functions in the library where registers on the NFC frontend are changed in order to meet different requirements and applications (such as turning off/on RF field)? All I see and have found is that phhalHw_Rc663_ReadRegister() and phhalHw_Rc663_WriteRegister() in HAL (both in phhalHw_Rc663_Cmd.c), provide direct SPI communication to NFC frontend. However, are there specific register write functions happening/being called upon initilization that should be tinkered with?

4. Since development is going to happen in CodeWarrior for S9KEA64..., is there anything in the library that I have to change in terms of the target MCU. In what areas do I need to change preprocessor statements or anything else in order to develop on a different MCU than what is supported in the library?

Any help would be greatly appreciated.

Thank you,

Andrew Meesseman

[estephania_mart]

Hello,

You can check this guide , I believe this it's going to be helpful for you, the guide not only shows the migration steps needed but also explains a little more about your questions of the library.

For what I understand, I believe that the read/write mode should be enough for you, still It is not quite clear if you want to read the mobile phone, if you are, please take into account that this device has only support for passive peer to peer mode. That it's the only part I'm worried about, are you planning to read a cellphone ?

In the library you will find examples that will do some modifications to the reader registers to configure it, it will depend on what you will develop the needed elements

You can check this other links for another migration examples

NFC reader library porting guide for LPC11u37h(Ver 5.12) - Switching the NFC frontend

NFC Reader Library Porting to i.MX RT1050 

We do not have any file or library for code warrior as it is is only supported in MCUXpresso, still, you should be able to do the migration as both of the IDEs are eclipse based ones.

Also, I would recommend you to check this videos

NFC Standards 

NFC Essentials

CLRC663 plus - Push your NFC design further

NFC Reader Library - SW support for NFC frontend solutions

How to port the NFC Reader Library to K64F

Regards,

Estephania

[andrew_meessema]

Hi Estephania, 

Actually, I believe the use case for scanning the cell phone would be when it is had died (is off). I believe our team has tested this with the development board and example code and it has worked for what we're doing. In this case, does the phone just act as a normal tag/card would?

And for each scenario (with tag, card, or phone), the only thing that we are going to do is pass along the UID that is received.

Regards,

Andrew Meesseman

[estephania_mart]

Hello,

Well,  if you already have an example that works for your needs and you are sure that it works as you want it, the NFC modes are not a problem or limitation for you.

You will only need to adapt the guides I provided for your needs in the IDE.

Regards,

Estephania

[andrew_meessema]

Hello,

The only problem I see with this is that I don't necessarily want the discovery loop to run or to port the whole library as it will not be the main application. The only thing that we really want to do is configure the board's registers upon startup initialization and buffer in any tag data that is received. 

For our different board, the processor is connected to the NFC frontend and a MC33662 LIN transceiver. The only thing that we want to do is buffer tag information to the processor and then send it along the LIN bus when requested. There is no OS and the main loop running is going to be listening for LIN headers (and responding/listening accordingly), in which case it will send new NFC information if there is any new tag info when it is polled.

So the basic discovery loop does work, however, I am starting to think it may be overkill for our application. Is it possible just to do something like setting up an IRQ register on the RC663 and then reading data via SPI when an interrupt occurs? I would like to do this but am still confused on how tag info that is received on the frontend is sent to the processor as I cannot pinpoint where the data is coming from while debugging. 

Regards,

Andrew

[estephania_mart]

Hello,

Do you mean something like the LPCD mode ?

Regards,

Estephania

[andrew_meessema]

Hello,

I have two questions.

1. After looking more at LPCD and AN11145, it looks as if it would be better to configure the RC663 to go into LPCD for our application as you suggested. Is the only difference between normal functionality and LPCD the fact that it only polls for card detection every ~200-500ms (along with lower power consumption).

2. When a device/tag is scanned while RC663 is in LPCD mode, how do you access device/tag data (such as UID for our application)? Do you have to exit LPCD mode to access tag info? Where is this information stored on the frontend? Or is it immediately sent over the detected communication method (SPI, I2C, SSP) when it is received?

Regards,

Andrew

[estephania_mart]

Hello,

The difference might seem not that much, but the fact that the polling just in a certain period of time it's quite a difference  as the LPCD detects the detuning and loading of the reader antenna before starting any command sequence.

It uses the available FIFOs buffers in the device, maybe for this you can check the example of the LPCD mode  in the reader library  NFCRDLIBTST12_RC663LPCD, after testing it and verify if that also work for what you need the migration I believe that will be easier for you.

Hope that helps,

Regards,

Estephania

[andrew_meessema]

Hi Estephania,

That definitely helps. And we are definitely going to use LPCD mode.

Now correct me if I am wrong but while in LPCD, if you receive the LPCDIRQ due to a card/tag being detected, you can then start a command sequence after this depending on your application. For us it would be most likely to send the Receive command (to activate receive circuit) via SPI to the command register and then read the FIFO buffer to get and process the card data? If you are to send the receive command, will this buffer in data from a tag sitting on antenna, or is there another command that should be sent in order to attain the tag information?

Edit: I have definitely been trying to look more into the NFC protocol itself but it looks as if I'd have to send the REQA (0x26 7 bits) command to initiate the sequence and would in return receive an ATQA, which would contain the UID prefix I believe. I see the register TxDataNum allows you to only send a certain amount of bits so would use for sending REQA. Following this, would initiate the sequence in order to request the full UID from the tag?

Regards,

Andrew

[estephania_mart]

Hello,

Sorry for the late reply, I'm not sure of your request , are you looking for the SPI frame to request the UID form the tag ?

Regards,

Estephania

[andrew_meessema]

Hi Estephania,

Yes, I believe I am looking for the SPI frame to request the UID from the tag once it's detected. 

Regards,

Andrew

[estephania_mart]

hello,

It will depend on your tag, for example, you can check some of the UID handling of the MIFARE family in this link, most of the commands are defined in the SO/IEC 14443 type A specification and you will need to access the NFC forum for further information regarding the topic.

If you will be using some of the MIFARE or NTAG families that are under NDA, you will need to look for further information about it on DocStore, if you are not registered in Docstore yet, I would recommend you to go either with your sales representative or your distributor so they can help you with that process.

Regards,

Estephania