cancel
Showing results for 
Search instead for 
Did you mean: 

ST25R3911B Collision Resolution returns TIMEOUT_ERR

AShar.10
Associate II

Hi,

I have ported RFAL library to ESP32 platform and have set up proper interrupts for it to function in capacitive wakeup mode.

So the issue:

We are using RFAL-HL ( higher layer ) in our project ( based on X-Cube-NFC5, but using the latest version of RFAL ) and while using it to detect NFC-A cards, tech detection is done successfully, upon moving to NFC-A collision resolution ( rfalNfcaPollerGetFullCollisionResolutionStatus ), the library always returns TIMEOUT_ERR ( 4 ) no matter how I place the tag against the antenna.

The issue is described in this pic ( I've added debug commands to interpret it easily ):

0693W00000AMH8GQAX.png 

Any kind of help will be appreciated.

Regards,

Ayush

1 ACCEPTED SOLUTION

Accepted Solutions

Hi Ayush

ad 2. Look for ST25R_SELFTEST in st25r3911.c.

ad 3. I expect that you don't need anything for platform(Un)ProtectWorker() unless you have a system where you are running rfalWorker() from a different task. If you say you are detaching the ISR - what happens if an interrupt comes while it is detached? Please make sure the ISR gets called immediately after re-attaching.

I guess you need to proceed to 5.

Regards, Ulysses

View solution in original post

9 REPLIES 9
Brian TIDAL
ST Employee

Hi,

do you use your own PCB with the ST25R3911B, with your own matching circuit and with your own antenna or do you use an X-NUCLEO-NFC05A1 board connected to your MCU?

Rgds

BT

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Hi,

I used X-NUCLEO-NFC05A1.

even tried connecting to ST25R3911 directly via SPI pins of discovery board. Same issue.

Regards,

Ayush

Ulysses HERNIOSUS
ST Employee

Hi Ayush,

most likely a porting issue of interrupts:

  1. Which card are you using, does ST25R3911B-DISCO read it?
  2. Is the SELFTEST inside RFAL activated and does it work?
  3. Please check that the platform(Un)Protect...() macros are correctly adapted to your used interrupt line
  4. Check using a multimeter if you have an INT line stuck at high when running your app.
  5. Look using a logic analyzer (SPI+INT): INT should only be high for very short times (typically in the tens of us range), if you don't find anything you can share the traces here.

Regards, Ulysses

Hi Ulysses,

Here are my findings with the setup which is somewhat working:

This time, I've modified the IRQ Status and Com ( platform(Un)ProtectST25RComm() & platform(Un)ProtectST25RIrqStatus() ) macros to detach and reattach the IRQ line. It's set up to trigger `st25r3911Isr()` whenever the IRQ line goes high.

Now with the current setup, I am getting a lot of TIMEOUT_ERRs (4) from rfalNfcaPollerTechnologyDetection(). But after keeping the card on the antenna for 3~8 seconds it magically detects it and reads the UID of it. ( Not ideal, this still means that there is conflict in the logic of our code )

  1. ISO14443A
  2. Don't know about this. Can you provide any reference?
  3. I've setup platform(Un)ProtectST25RComm() and platform(Un)ProtectST25RIrqStatus() to detach and reattach interrupt routine accordingly. The platform(Un)ProtectWorker() macros are left empty. I've no idea what should be there. Any ideas?
  4. I am sure that INT is not stuck. It blinks for a fraction of a millisecond which makes me believe that it's getting processed.

I think my issue is around macros defined in the platform.h, What's the platformProtectWorker()... for?

Regards,

Ayush

Hi Ayush

ad 2. Look for ST25R_SELFTEST in st25r3911.c.

ad 3. I expect that you don't need anything for platform(Un)ProtectWorker() unless you have a system where you are running rfalWorker() from a different task. If you say you are detaching the ISR - what happens if an interrupt comes while it is detached? Please make sure the ISR gets called immediately after re-attaching.

I guess you need to proceed to 5.

Regards, Ulysses

You were correct. The ISR was not getting called immediately after re-attaching. So I added a couple of lines after re-attaching to detect the IRQ status and fire that interrupt anyhow.

Card detection and collision have been fixed. But timing is still an issue with the wakeup period timer set to 100ms ( Dropping it to 10ms made the board detect the card in around 1~2 seconds ). The same 100ms set on the discovery board via GUI returns the results immediately. Let me know if this behaviour is fine?

Hi Ayush,

I don't see a reason to observe reduced reactivity.

I think option 5 is the way to go to understand.

Regards, Ulysses

SPraj.1
Associate II

Hello

I am usinf ST25RU3993 UHF engine with STM32G473CETX HOST, I amm getting IRQ PIn error during ST25RU3993 Self Test. I am getting Pin interrupt but still debug log shhows this error and If i ignore this error and run code then tag is not detected.

Can you please update me on this as soon as possible?

Hi SPraj.1,

I think you should create an own question to get an answer from experts. I think you need to check your porting if the Selftest fails.

Regards, Ulysses