RFAL Infinite Loop While Checking for Interrupt - ST25R3911b

[KRauccio]

Hi,

 

I have been working on a project that is based on the ST25R3911b Discovery Board including building prototype firmware from the discovery kit's firmware. I have made sure not to edit any of the RFAL or HAL library files.

Recently I had brought this prototype to be pre-scanned for radiated immunity. During this testing, I discovered a bug that I have not seen before.

The process gets stuck in an infinite loop in the rfalTransceiveRunBlockingTx() function (found in rfal_st25r3911b.c).
Specifically on line 1267, while( (rfalIsTransceiveInTx() && (ret == ERR_BUSY)) );

In the rfalTransceiveTx() function, the process enters the RFAL_TXRX_STATE_TX_WAIT_TXE case and checks for interrupts. However, there will not be any interrupts to process, and so the process breaks without updating the gRFAL.TxRx.state.
This appears to me like the interrupt from the NFC chip was either not sent or was not received correctly, so when that Do while loop checks "(ret == ERR_BUSY)", it will always be busy because the no interrupts are received and the state isn't changed.

It looks like a sanity timer was added in newer versions of RFAL, but I am mainly interested to know if this issue was seen before. It is unclear to me whether or not this could potentially be a hardware issue or if it's just firmware.

 

Some extra notes:

The system works most of the time, so I am confident that an additional system is not causing the problem.
The problem is intermittent and I have no way to consistently reproduce it. 

I can step out of the loop just fine and things work properly from there on.

 

Would anyone be able to shed some light on this?

 

Thank you,

Kaitlyn

[Brian TIDAL]

Hi,

could you provide the RFAL version being used (see RFAL_VERSION in rfal_rf.h)?

Rgds

BT

[Ulysses HERNIOSUS]

Hi Kaitlyn,

1. the sanity timer is specifically meant to catching missing receive interrupts which could be happening under mentioned conditions.
2. I am expecting a missing I_txe only in case the tx_en=0. To my knowledge software is checking this before triggering a transmit. Could you do a logic analyzer trace of the is behavior and share it here. Also interesting would be a dump of all the registers of ST25R3911B when this hang has happened.

BR, Ulysses

[KRauccio]

Hi,

I apologize for the delayed response. I am struggling to reproduce the issue after setting up a logic analyzer. I will add an update later when I am able to provide the data.

I did get a chance to test a unit that was not used for immunity testing and I see the same issue there, so I doubt that those tests caused any issue.

 

@Brian TIDAL The RFAL version is stated to be v2.0.2. The RFAL files were ported from the ST25R3911b firmware.

 

 

[Ulysses HERNIOSUS]

Hi,

RFAL v2.0.2 is rather old but looking through the ReleaseNotes from latest v4.0.0 I didn't spot any bugs being fixed which sound like you are encountering. You could try to update to latest RFAL and see if it gets fixed. But my hopes are limited and for sure some APIs have changed since then.

Best to analyze based on a trace.

Ulysses