ST25R3916 Not Initializing Properly when using the RFAL library

[CGraham]

Hello,

I am developing an application that uses a ST25R3916 to detect and process tags. The application is running Azure RTOS and I've connected the reader to the uP using SPI. Physically, I am using an NXP RT1060 dev kit and the X-NUCLEO-NFC06A1 dev kit connected with jumper cables. I am trying to get to the point where I can detect a tag, but I'm getting errors as I run the code per the example.

Per the example and my code, I use the following sequence to initialize the device for communication with a ISO 15963 tag:

1. rfalAnalogConfigInitialize();
2. err = rfalInitialize();
   1. Returns ERR_NONE
3. err = rfalNfcvPollerInitialize();
   1. Returns ERR_NONE
4. err = rfalFieldOnAndStartGT();
   1. Returns ERR_INTERNAL (12U)
   2. Generated by line 1190 in rfal_rfst25r3916.c
      1. ret = st25r3916PerformCollisionAvoidance( ST25R3916_CMD_INITIAL_RF_COLLISION, ST25R3916_THRESHOLD_DO_NOT_SET, ST25R3916_THRESHOLD_DO_NOT_SET, gRFAL.timings.nTRFW );
   3. Check ignored as per in the example
5. err = rfalNfcvPollerCheckPresence( &invRes);
   1. Returns ERR_IO (3U)
   2. Generated by line 2953 in rfal_rfst25r3916.c
      1. ret = rfalTransceiveRunBlockingTx();

At this point, I'm trying to understand why I'm getting these errors so I can continue debugging. I'm fairly confident in the SPI interface since I can communicate and configure the device. Additionally, I am confident in the mutexs implementation and the irq handler.

Does anyone have any thoughts on things to check?

Thanks in advance!

[Brian TIDAL]

Hi,

I would suggest to enable ST25R_SELFTEST and ST25R_SELFTEST_TIMER switches to check that the porting to your MCU is properly functional (in particular for the ST25R3916 Interrupt handling). Just recompile your code with those 2 switches defined and check the return code of st25r3911Initialize. My guess is that the ST25R3916 Interrupt is not properly handled.

Let us know the return code of st25r3911Initialize when ST25R_SELFTEST and ST25R_SELFTEST_TIMER are enabled.

Rgds

BT

[CGraham]

Hello Brian,

Adding ST25R_SELFTEST and ST25R_SELFTEST_TIMER adds in the communication, irq, and gp timer tests. All tests seem to pass and st25r3916Initialize() returns ERR_NONE. st25r3916Initialize() is called directly from rfalInitialize(), but you referenced the return of st25r3911Initialize(); did you intend for me to add a call st25r3916Initialize() or did you want me to add the 3911 call?

Best Regards,

Chad

[Brian TIDAL]

Hi,

sorry for the typo, I meant st25r3916Initialize() which is called by rfalInitialize(). So, this part seems to be OK as ERR_NONE is returned.

This issue reminds me a similar post on ST25R3911B device https://community.st.com/s/question/0D50X0000C8f3duSQA/errors-in-initializing-st25r3911b

Can you connect a logic analyzer on the SPI (CLK/MOSI/MISO/CS) + ST25R3916 IRQ and check the SPI CS behavior?

Feel free to share details about your platformSpiXXX implementation in particular for the SPI CS? Make sure the CS stays low during a whole transaction. Do you use ST25R391X_COM_SINGLETXRX ?

Rgds

BT

[CGraham]

Hello Brian,

Hope you had a pleasant weekend.

I have continued working on this and have made some progress, but I'm still not able to communicate with a tag.

First off, I've spent a fair amount of time walking the code and I'm consistently getting ERR_NONE when I initialize the device. I detected an unusual issue where my system was calling the rfalWorker only twice as fast as my system thread and it was creating an inconsistent return where it worked 90% of the time, but not 100%. I ended up spinning up a thread that solely calls the rfalWorker every 1ms and the system seems to be doing better.

Unfortunately, I now fail the rfalFieldOnAndStartGT(); line 1190 of rfal_rfst25r3916.c returns only 12 (0x0C).

ret = st25r3916PerformCollisionAvoidance( ST25R3916_CMD_INITIAL_RF_COLLISION, ST25R3916_THRESHOLD_DO_NOT_SET, ST25R3916_THRESHOLD_DO_NOT_SET, gRFAL.timings.nTRFW );

This is identical to the thread you referenced, but the root cause of their problems appears to be different. Setting up an oscope/la; I can see the entire bus and the IRQ. Using the irq as the trigger, I can see the ISR properly firing using only a single CS and that the irq signal is transitioning as intended.

To answer your question, I am treating the CS as a gpio output that is controlled by the rfal library, not as part of the bus. Also, we are setup as ST25R_COM_SINGLETXRX in platform.h.

What else can I try?

[Brian TIDAL]

Hi,

Can you connect a logic analyzer on the SPI (CLK/MOSI/MISO/CS) + ST25R3916 IRQ and send us the trace ?

Can you check:

• that CN6.4 and CN6.5 are properly powered (respectively to 3V3 and 5V). See UM2615 table 1 and 2
• that CN6.6 and CN6.7 and CN5.7 are properly connected to GND

Make sure that your jumper cables are relatively short and firmly connected.

Also feel free to share details about your firmware architecture with Azure RTOS:

• ISR handling (do you have a dedicated task for the ST25R3916 ISR)
• SPI communication protection between NFC task and ST25R3916 interrupt
• IRQ status protection (platformProtectST25RIrqStatus) as the status of the ST25R3916 interrupt is shared between the ISR and the main NFC task

Rgds

BT

[Ulysses HERNIOSUS]

Hi,

looking at the code the problem is around

    irqs = st25r3916WaitForInterruptsTimed( ( ST25R3916_IRQ_MASK_CAC | ST25R3916_IRQ_MASK_APON ), ST25R3916_TOUT_CA );

If neither CAC nor APON is received in-time then ERR_INTERNAL is returned. So potentially your timer implementation is causing premature timeout (before ST25R3916_TOUT_CA).

As Brian indicated a Logic Analyzer trace will give us facts and avoids speculating.

BR, Ulysses

[CGraham · Accepted solution]

Good Morning,

I'm pleased to report that the problem appears to be solved. Since I'm running in an RTOS system, my final issue related to using an interrupt flag to trigger the ISR verse calling it directly. Despite the 1ms thread being set at a higher priority than the thread I was using to control the chip, I had to elevate the 1ms thread's priority significantly to get it run reliably.

Thanks for the help!

[Brian TIDAL]

Hi,

Well done!

in our FreeRTOS implementation, we have a dedicated ISR task running the st25r3916Isr(). This ISR task has an higher priority (osPriorityHigh) than the NFC task (osPriorityNormal). This ISR task is waken up through a notification from the interrupt handler. Once the st25r3916Isr() is completed, the ISR task signals the NFC task through a semaphore and returns in the wait for notification state until the next interrupt. I guess a similar architecture could be used with Azure RTOS. See ST25 embedded NFC library for source code of the FreeRTOS demo.

Rgds

BT