ST25R3914 Library Issue

[APant.2]

Hello,

I want to apologize in advance for how long this post is. I wanted to provide as much information as I could so I can help you (the reader) get a better picture of what might be going on. Sorry.

I am currently working on a project that uses a st25r3914 nfc chip to detect and interface with an NFCa tag. Also, I am using the pre-made RFAL for ST25R3911B library so I can get the chip up and running quickly. Unfortunately, this process has not been going so well. I am running into issues interfacing with a tag.

Background Info

• NFC Chip - ST25R3914
• NFC Lib - RFAL for ST25R3911B
• MCU - NXP S32K144
• OS: NXP freeRTOS

I have successfully merged the pre-made library with the rest of my code and have populated the platform.h header file with all that is necessary. To test if the library is setup correctly, I am using the exampleRfalNfca.c example program that came with the documentation. I have verified that the system is initializing the RFAL lib correctly given that the return of the function rfalInitialize() is 0 (ERR_NONE). As an added layer of confidence, I have also enabled the ST25R_SELFTEST and ST25R_SELFTEST_TIMER to be completely sure everything is initialized and setup correctly. With both macros enabled, the function still returns a 0.

The issue I am having then arises in the next part of the example program. When I initially power the system, and put a tag close to the antenna, the program successfully detects it. It then moves forward to running the collision resolution routine. At this point the function return a value of 4 (ERR_TIMEOUT) and does not continue with the rest of the algorithm. It then goes back and restarts the process. This time, when I bring a tag close to the antenna, the function rfalNfcaPollerTechnologyDetection() always returns a value of 4 and never detects a tag again. After debugging the library, I figure out that after the tag is detected the first time, the field does not turn on anymore, even though the program runs through the code to turn it on. This would explain why the tag isn’t being detected anymore.

Debugging

I then began to step through the code to figure out exactly why this was happening. The only thing I was able to figure out was that when the system is initially powered on and no tag has been detected, the field turns on right after ST25R3911_REG_OP_CONTROL_tx_en bit has been set in the ST25R3911_REG_OP_CONTROL register (this step in the rfalFieldOnAndStartGT routine). Once a tag has been detected and the program sets the tx_en bit, the field does not turn on. I have verified this theory using an oscilloscope. Image nfc_field shows the signal before a tag is detected, and image no_nfc_field shows after.

My next thought was that maybe it has something to do with the interrupts. I began scoping the interrupt line along with the SPI peripheral. I observed that when the library is attempting to detect a tag, 2 interrupts happen. The first one is caused by the I_txe (IRQ due to end of transmission). The second is caused by I_tim (IRQ due to timer or NFC event) and I_nre (IRQ due to No-Response Timer expuire). This makes sense. Then when I bring a tag near the antenna, 3 interrupts happen. The first one is always the same, I_txe. The second one was caused by I_rxs (IRQ due to start of receive). And the third was because I_rxe (IRQ due to end of receive). This also makes sense. After that only 2 interrupts happen, and the cause is the same as the first explanation ( I_txe and (I_tim & I_nre) ). Here is where I observed something interesting. The time between the first set of 2 interrupts (before tag) was about 162us. After the tag was found, the time between them was 81 us. This was a bit odd to me and don’t know why the chip produces the interrupts twice as fast. I have attached 3 images to show the IRQ line during all three instances - irq_beforeTag, irq_tagDetected, and irq_afterTag.

Does anyone know what might be going on? I've spend 2 days already attempting to debug this, but to no avail.

[APant.2]

I forgot to attach scope images.

Unfortunately, the system only allows me to attach 1 file, so I zipped up the images.

[Brian TIDAL]

Hi,

can you describe your HW setup: do you use a custom board or a MCU board connected to an X-NUCLEO-NFC05A1? In case of custom board, what is your cristal: 27.12 or 13.56 MHz?

Can you provide a logic analyzer trace (SPI CLK/MOSI/MISO/CS + ST25R3914 IRQ) up to the oscillator config issue? Can you probe the cristal and check that it is oscillating properly?

Once configured, the osc bit of ST25R3911_REG_IO_CONF1 register is never changed by the RFAL. Therefore, I suspect that your SPI buffer is sometimes corrupted (or memset'ed to 0x00...) before being sent. Maybe the implementation of  platformProtectST25RComm/platformUnprotectST25RComm is erroneous.

Do you use ST25R_COM_SINGLETXRX?

Rgds

BT

[APant.2 · Accepted solution]

Brian,

I finally got the library to work. The issue was caused by NXP's way of implementing the SPI protocol. It turns out that within the library, there are a couple of instances where Tx and Rx are done in two separate transactions. This works great when you have control over the CS line, but since the NXP SDK controls this line with each call to their transmit function, both instances were being treated as two different SPI calls.

 

Given this information, when the program called st25r3911ReadFifo, the second SPI call overwrote the osc bit, which inevitably caused the chip to output the 27.2Mhz signal.

Solution

After looking through the documentation, I stumbled across the ST25R_COM_SINGLETXRX preprocessor directive, as you mentioned in your post. I enabled this and the library worked. I am able to detect tags now.

Thank you Brian for all of your help! I truly appreciate it.

For anyone else using NXP SDK with freeRTOS

• Setup your project similar to ST25 embedded NFC Library (freeRTOS example)
• Create a Mutex instead of taskENTERCRITICAL/EXIT for platformProtect.
• Create a Binary semaphore for triggering between IRQ and main NFC task.
• Enable ST25R_COM_SINGLETXRX preprocessor directive at compile time.

I believe that is all of the steps. Hope this helps.

Adan

[Brian TIDAL]

Well done!