Optimization Request: ST25R3920B NFC Startup and Card Detection Time

[Anithak]

Hi,

We are using the ST25R3920B NFC reader IC along with the NXP S32K312 MCU running an AUTOSAR OS for NFC card detection.

We have observed that, after the NFC wake-up event, the NFC initialization and polling sequence takes approximately 300 ms before a card is detected. This startup time is longer than expected and is impacting our application requirements.

Could you please suggest any configuration changes, RFAL optimizations, or best practices to reduce the NFC initialization and polling time? If there are any recommended settings for use with an AUTOSAR-based system or the ST25R3920B that can help improve startup performance, we would greatly appreciate your guidance.

Thanks,

Anitha

[Ulysses HERNIOSUS]

Hello Anitha,

hard to say why and how these 300ms are spent. Typically a polling loop should more be below 100ms (if all techs are enabled).

Factors influencing the timing are

1. When is the tag actually answering. Especially phones may take time to start answering. Also: I assume this is a dynamic test: Maybe the wakeup range is bigger than the communication range and some time is spent to move from the wake-up distance to the communication distance.
2. totalDuration: How long does it take between two pollings
3. Frequency of rfalWorker/rfalNfcWorker() calls. What is the period in your system?

Maybe you could do logic analyzer traces: SPI + IRQ + MCU pin which you trigger when executing rfalNfcWorker()rfalWorker(). And share them here.

 

BR, Ulysses

 

[Brian TIDAL]

Hi Anitha,

 

could you provide some information about your system:

• MCU - ST25R3920B communication interface: SPI or I2C? communication speed?
• scheduling model of the RFAL worker
• is RFAL High Layer being used (i.e. API from rfal_nfc.c) ?
• NFC technologies to be supported as part of your application requirements: NFC-A/NFC-B/NFC-F/NFC-V?
• NFC technologies currently enabled: AP2P?NFC-A?NFC-B?NFC-F?NFC-V?
• Is listen mode enabled?
• Is the wakeUp mode being use? how is it configurered (parameters)?

Could you connect a logic analyzer on the communication interface (including the ST25R3920B interrupt) and provide the raw log file?

Rgds

BT

[Anithak]

Hi, Ulysses HERNIOSUS. Thanks for the fast response. 
I’ll provide the current configuration that we are using for the RFAL stack.
Initialization for discovery parameters - 

  discParam.compMode = RFAL_COMPLIANCE_MODE_NFC;

  discParam.devLimit = 1U;

  discParam.nfcfBR = RFAL_BR_212;

  discParam.maxBR = RFAL_BR_KEEP;

  discParam.p2pNfcaPrio = false;

  discParam.wakeupEnabled = false;

  discParam.wakeupConfigDefault = false;

  discParam.wakeupNPolls = DISCOVERY_CNT;

  discParam.wakeupConfig.period = RFAL_WUM_PERIOD_100MS;

  discParam.wakeupConfig.irqTout = false;

  discParam.wakeupConfig.indAmp.enabled = true;

  discParam.wakeupConfig.indAmp.reference = RFAL_WUM_REFERENCE_AUTO;

  discParam.wakeupConfig.indAmp.delta = RFAL_WKPU_DELTA_TWO;

  discParam.wakeupConfig.indAmp.autoAvg = true; /**Changed to TRUE as per  HSI Requirement  */

  discParam.wakeupConfig.indAmp.aaWeight = RFAL_WUM_AA_WEIGHT_4; /**Added as per  HSI Requirement  */

  discParam.wakeupConfig.indPha.enabled = true;

  discParam.wakeupConfig.indPha.reference = RFAL_WUM_REFERENCE_AUTO;

  discParam.wakeupConfig.indPha.delta = RFAL_WKPU_DELTA_TWO;

  discParam.wakeupConfig.indPha.autoAvg = true;

  discParam.wakeupConfig.indPha.aaWeight = RFAL_WUM_AA_WEIGHT_4; 

  discParam.wakeupConfig.cap.enabled = false;

  #ifdef ST25R3916

  discParam.wakeupConfig.swTagDetect = true;

  #endif /* ST25R3916 */

  #ifdef SW_ALPCD

  discParam.wakeupEnabled = true;

  #endif /* SW_ALPCD */

  (void)ST_MEMSET(&discParam.propNfc, 0x00, sizeof(rfalNfcPropCallbacks));

  discParam.propNfc.rfalNfcpPollerInitialize = NULL;

  discParam.propNfc.rfalNfcpPollerTechnologyDetection = &PropNfcTechnologyDetection;

  discParam.notifyCb = &NFCNotif;

  discParam.totalDuration = RFAL_TOT_DUR_FIVE;

  discParam.techs2Find = (RFAL_NFC_POLL_TECH_A | RFAL_NFC_POLL_TECH_PROP);

  discParam.isoDepFS = RFAL_ISODEP_FSXI_256;

RFAL Stack API call:
1. rfalNfcWorker() is scheduled in 5ms task.
2. Type A and Prop tech features is enabled for detection, other techs are disabled.

Observation:
1. RFAL stack is staying in RFAL_NFC_STATE_POLL_TECHDETECT for 150ms around, before proceeding to next state.
2. ST wakeup feature (LPCD) is disabled in initialization but is being enabled after one cycle of polling activity is completed.

Note:
1. Due to project specific requirements, we have device type A, with proprietary data delivery through rfalNfcpCbPollerTechnologyDetection().
2. gNfcDev.isTechInit value update is disabled at NFC-A detection code, under rfalNfcPollTechDetetection() 

[Ulysses HERNIOSUS]

Hi Anitha,

 

RFAL_TOT_DUR_FIVE is a bit unexpected. As 5ms is already the first basic guard time. I would go here more in the range of maybe 60ms avoid constant carrier and strong heating which may influence also the wake-up/LPCD (depending on matching and components). But I don’t believe this to be the reason.

Technology detection should be rather fast. If it isn’t then I would suspect in your case an issue in the timer glue layer (platformStartTimer(), etc.).

 

Such would be best seen in a logic analyzer trace as described above.

 

Ulysses

 

[Brian TIDAL]

In addition to Ulysses' answer, enable the ST25R_SELFTEST_TIMER compilation flag to check the timer glue layer.

Rgds

BT