ST25R3911B RFAL Library - i_err bit remains high - infinite loop

[fredj0207]

Hello,

I'm using RFAL v2.6.0 and ST25R3911B and I get an issue with the IRQ management.

Using ISO14443 Type-A tag,  the IRQ remains high causing the while loop not to exit. 

In this condition, the i_err bit of the main interrupt register is '1' while the two  interrupt registers (Timer and NFC interrupt register and Error and wake-up interrupt register) have all of their bits to '0'. 

 

Reading these register in a loop cannot clear the i_err bit. 

 

The last content prior the lock state is:

- Main interrupt register: 0x33 -> i_rxs, i_rxe, i_tim, i_err

- Timer and NFC interrupt register: 0x20 

 - Error and wake-up interrupt register: 00  (Should be different from 0)

[Brian TIDAL]

Hi Frederic,

what is your hardware setup:

• X-NUCLEO-NFC05A1 + NUCLEO MCU board (which one?)
• or a custom board? Feel free to share details (MCU, etc.)

Do you use the X-CUBE-NFC5 package or the RFAL for ST25R3911B package? Do you use a bare metal implementation or running inside and RTOS?

" the IRQ remains high causing the while loop not to exit". Do you refer to the while loop inside st25r3911CheckForReceivedInterrupts:

Can you connect a logic analyzer on the SPI (CLK/MISO/MOSI/CS) + ST25R3911B_IRQ and provide the trace  from the analyzer?

Rgds

BT

 

[fredj0207]

Hi Brian,

This is a custom board using an ESP32-WROOM-32E as MCU (OS is ESP-IDF based)
SPI communication is 5MHz.

Yes I refer to the while loop inside st25r3911CheckForReceivedInterrupts.

In our implementation, the function is called from a high priority task which is notified by the GPIO ISR as it is not possible to execute the full st25r3911CheckForReceivedInterrupts in an IRQ routine (too long for a multi-task, multi-core OS).

Please also note, that I have absolutely no problem using ISO15693 tag.  The problem occurs only with ISO 14443-A configuration. It looks like the i_err is raising without having other bits set and so in this condition it is not possible to clear it just by reading the registers as they are already cleared.

And the RFAL is working well if I remove the while condition.

Unfortunately for now, I do not have the material to scope any signals.

Regards,

 

[Ulysses HERNIOSUS]

Hi, 

 

are you reading all three interrupt registers in one frame (DS: in one attempt)? We are no aware of this specific issue. 

You might try to detect this condition and then issue a Clear command in this case - maybe it helps.

 

BR, Ulysses

[Brian TIDAL]

Hi Frederic,

can you elaborate on how platformProtectST25RComm and platformUnprotectST25RComm has been implemented in your application?

See for example the FreeRTOS_polling demo inside the ST25 embedded NFC library for ST25R3916 for an example of the RFAL running inside an RTOS. The software architecture is probably similar to yours i.e. the ST25R39xx ISR runs inside a critical task triggered by the interrupt and the NFC loop runs in the main task.

Rgds

BT

[fredj0207]

Hi Brian,

Our software is not using critical section as it is too restrictive. We only use binary mutexes to protect SPI communication and status register accesses. 

However, I do not think the problem is about OS our SPI communication. 

I log the contents of the three interrupt registers in the function and the status is clear:

Every thing is working as expected until we get i_err=1 in main register with a null register 19 h (that should be impossible). After this I read in an infinite loop the three registers to:  0x01 0x00 0x00 

If it was something about SPI communication, reading again and again should clear all the bits at one time.  Am I wrong ?

 

Regards

Fred

[Brian TIDAL]

Hi Frederic,

as explained by @Ulysses HERNIOSUS, we are not aware of this specific issue in spite of a lot of testing in different environments (bare metal, RTOS, Linux, ...). I've prepared a setup with tags being at the limit of the operating volume to create communication errors but so far I do not see any issues. Having a logic analyzer trace would help to analyze this issue. You can contact @Ulysses HERNIOSUS and me in private as soon as you can connect a logic analyzer and provide a trace file.

Rgds

BT

[fredj0207]

Hi Brian,

I have test the solution propose by Ulysses and it works. 

No I have the following code:

 while( platformGpioIsHigh( ST25R_INT_PORT, ST25R_INT_PIN ) )
 {
 st25r3911ReadMultipleRegisters(ST25R3911_REG_IRQ_MAIN, iregs, sizeof(iregs));

 irqStatus |= (uint32_t)iregs[0];
 irqStatus |= (uint32_t)iregs[1]<<8;
 irqStatus |= (uint32_t)iregs[2]<<16;

 if( iregs[0] & 0x01 )
 {
 st25r3911ExecuteCommand(ST25R3911_CMD_CLEAR_FIFO);
 }
 }

This is the only way to clear i_err bit in main interrupt register (whatever other registers values are).

 

[Ulysses HERNIOSUS]

Hi,

we are still puzzled why this would be happening. We have seen weird issues also when the SPI driver was not doing what it was supposed to be. So I would really like to see a logic analyzer trace of the communication in this case.

Also for your workaround implementation: I would likely make it more specific by moving to 

 if( (iregs[0] & 0x01) && (0 == iregs[2]) )

 

 BR, Ulysses

[Brian TIDAL]

Hi Frederic,

the 4-bits ACK/NACK in type 2 causes an I_crc and/or an I_par interrupt that is internally converted into an RFAL_ERR_INCOMPLETE_BYTE return code. The rfalT2TPollerWrite function then checks that this incomplete byte is an ACK. Thus, having an I_crc is an expected behavior in case of 4 bits ACK/NACK reception.

It would really be helpful to have an SPI trace (CLK/MISO/MOSI/CS+ ST25R3911B_IRQ) to better understand your issue.

Some additional questions:

• have you tried on different boards?
• what are the Vdd and Vdd_io values on your custom board?
• is your custom board powered by a battery or by the mains?

Rgds

BT

[fredj0207]

Hello Brian,

As I said before unfortunately I do not have any advanced scope to get the SPI trace. And there is no test point on the custom board. I only have total Phase beagle. If I have time I will try to get data.

- We are using ST25R3911B or ST253916 for 3 years now on different custom board versions. 

We always had a problem with the while loop in the RFAL (for NFC Type 2 tags).  The only way to get the library worked was to remove the while loop. 

On the last firmware version I decided to remove the IRQ management that can be problematic on espressif and use polling. I still have the same issue with NFC Type 2 tags.

- Vdd is 5V.

- Vdd_io is 3.3V.

- The board is powered by the mains (12V then two stages regularor, plus CMCC filter). 

Regards,

Fred

[Grégoire Poulain]

Dear Fred,

This behavior is not known and the only efficient way to proceed is to retrieve a SPI trace (incl IRQ line) of the occurrence, so that we can perform technical analysis.

 

Meanwhile let me share some additional details:

• Loop inside the RFAL
  The loop is intended to cope with limitations of certain MCUs.
  Depending on configuration (Level-trigger vs Edge-trigger), in case one IRQ occurs while reading the previous one, the ISR may not be called ever again. 
  This matter is covered in detail on RFAL User Manual (UM2890) Section 6.9
  
  Can your system have the ST25R3911B IRQ configured to level-triggered ?
  
  
  
• HW vs SW Chip Select
  Also covered on the RFAL User Manual (UM2890) Section 6.8, usage of HW chip select can be problematic.
  Can you confirm that the right configuration is deployed?
   "set ST25R_COM_SINGLETXRX configuration and clear the APIs: platformSpiSelect() and platformSpiDeselect()"
  
  Also when chip select is handled by the HW it may violate the required SPI timings (tNCSL / tNCSH).
  Only with a SPI trace we'll be able to verify the timings.
  
  

Hope it helps
We look forward for a SPI trace of the occurrence.

Kind regards
GP

[fredj0207]

Hi Gregory,

Thanks for the information.

• HW vs SW Chip Select:

Yes we are using the right configuration. And CS is hardware managed.

 

As I discussed with Brian in private message, I can imagine we have some violation in SPI. Why not ?

But it cannot explain why we are not able to recover by sending another read. 

Because how can you explain that the read operations works 95% of time and when the issue occured, it was impossible to clear the status by reading the register for ever. And at the same time sending other commands through SPI (such as clear command) works fine. It means SPI is not stuck and so one of the reading operation should succeed to clear the register. 

My feeling (maybe I'm wrong) is we are not looking on the right point.  I have been working in ST, Atmel, Inside and Starchip companies for a long time and it looks more at a rare timing race issue in HW. 

Whatever, I will send SPI traces as soon as possible.

Regards,

Frederic

[Ulysses HERNIOSUS]

Hi,

I am reading down there about TotalPhase Beagle. It looks like only providing the data packets plus timings not no waveforms.

We have often seen issues only in the waveforms so a logic analyzer is typically superior for this use case. If possible try to get one as well.

 

BR, Ulysses