ST25R3911B errors when combination of two tags

[EBadi.2]

What I'm doing is to perform anticollision with 1 or 2 NFCA tags present.

When performing anticollision with just one tag, the function does never report an error and allways find 1 tag correctly.

When performing anticollisiion with two tags:

• There are combinations of two NFCA tags that allways work perfectly (ERR_NONE) and found all the tags.
• There are combinations of two NFCA tags that allways fails.

When a combination allways fails:

• If I have optimize for size (-Os) error is allways ERR_FRAMING (in the same place as PDe), and if I call anticollision function again, it just found 1 tag (but there are two!).
• If I have optimize most (-O3) error is allways ERR_INCOMPLETE_BYTE, if I call anticollision function again, error is ERR_TIMEOUT, if I call it again, ERR_INCOMPLETE_BYTE, ...
• All tags works fine, when just one is present.

-----------------------------------------------------------------------------------------------------------------------------------

Ulysses HERNIOSUS

Open Ulysses HERNIOSUS Preview

 (ST Employee)

Hi EBadi.2,

I propose you create a separate ticket for this behavior. I have some ideas but would also need some more information which you could post in this separate ticket:

• Which functions are you calling with which parameter?
• At which frames do yo observe this behavior? REQA/SENS_REQ or anticollision/SDD_REQ or SELECT/SEL_REQ? Our collision resolution functions are built to be able to cope with multiple tags.

-----------------------------------------------------------------------------------------------------------------------------------

err = rfalNfcaPollerInitialize();  /* Initialize for NFC-A */

err = rfalFieldOnAndStartGT();   /* Turns the Field On if not already and start GT timer

err = rfalNfcaPollerTechnologyDetection( RFAL_COMPLIANCE_MODE_NFC, &sensRes );

err = rfalNfcaPollerInitialize();

err = rfalFieldOnAndStartGT();   /* Turns the Field On if not already and start GT

err = rfalNfcaPollerFullCollisionResolution( RFAL_COMPLIANCE_MODE_NFC, (MAX_TAGS_TO_READ), nfcaDevList, &totalTags );

The errors I see are in this last call, is that what you were asking?

Where to find these: REQA/SENS_REQ or anticollision/SDD_REQ or SELECT/SEL_REQ?

[Ulysses HERNIOSUS]

Hi EBadi.2,

What is your value of MAX_TAGS_TO_READ?

The issues described in st25r3911b-error-framing-in-reception consistently explains the issues you observe with -Os. You may fall into this problematic timing. You may actually also be able to shift the problematic point by adding a small delay (few us) into the ISR instead of speeding up with -O3.

However I am a bit puzzled by the ERR_INCOMPLETE_BYTE - it should have received ST25R3911_IRQ_MASK_COL and return ERR_RF_COLLISION in these cases.

When you see this ERR_INCOMPLETE_BYTE: Can you tell me the stacktrace? Alternatively the values of gRFAL.TxRx.ctx.

I would also be interested in a logic analyzer trace in this case: MISO,MOSI,SCLK,/SS,INT.

In general there can always be positions of two cards where it gets tricky from an analog standpoint to correctly identify collisions between two cards. One card may be much stronger than the other one and then only one card is read. However in our experience this should be working well with our readers in most positions.

Best Regards, Ulysses

[EBadi.2]

Hi Ulysses HERNIOSUS,

MAX_TAGS_TO_READ is set to 2.

Issue get not fixed adding a delay on the ISR.

With -Os, when I get ERR_INCOMPLETE_BYTE, the value of gRFAL.TxRx.ctx is allways: 536872912.

Unfortunatelly I do not have a logic analyzer.

When I found a combination of two tags, they never work, in any position on the antena. But they can work with other tags with no problem.

[Ulysses HERNIOSUS]

Hi,

Sorry I wasn't clear about the details: I would be interested in the content of gRFAL.TxRx.ctx. Especially in the fields:

gRFAL.TxRx.ctx.txBufLen and gRFAL.TxRx.ctx.txBuf[0..(gRFAL.TxRx.ctx.txBufLen+7)/8].

This would tell me where in the sequence the error happens and if a collision error would be expected at this frame.

Also can you give me details about the 2 tags which you have in the field: ATQA and UID? Please provide also the content of gRFAL.fifo.status[] when this happened.

Best Regards, Ulysses

[EBadi.2]

Hi again,

This is what I've implemented:

 

And this is the result (allways the same:

gRFAL.TxRx.ctx.flags =  11 
 
gRFAL.TxRx.ctx.fwt =  2196 
 
gRFAL.TxRx.ctx.txbufLen =  16 
 
gRFAL.TxRx.ctx.txbuf =  
 
   [0] 0x93  
 
   [1] 0x20  
 
   [2] 0x00  
 
   [3] 0x00  
 
   [4] 0x00  
 
   [5] 0x00  
 
   [6] 0x00  
 
   [7] 0x00  
 
   [8] 0x67  
 
   [9] 0x3C  
 
   [10] 0x03  
 
   [11] 0x20  
 
   [12] 0x69  
 
   [13] 0x3C  
 
   [14] 0x03  
 
   [15] 0x20  
 
   [16] 0x68  
 
gRFAL.TxRx.ctx.rxbufLen =  40 
 
gRFAL.TxRx.ctx.rxbuf =     [0] 0x00  
 
   [1] 0x00  
 
   [2] 0x00  
 
   [3] 0x00  
 
   [4] 0x00  
 
   [5] 0x00  
 
   [6] 0x67  
 
   [7] 0x3C  
 
   [8] 0x03  
 
   [9] 0x20  
 
   [10] 0x69  
 
   [11] 0x3C  
 
   [12] 0x03  
 
   [13] 0x20  
 
   [14] 0x68  
 
   [15] 0x3C  
 
   [16] 0x03  
 
   [17] 0x20  
 
   [18] 0x00  
 
   [19] 0x02  
 
   [20] 0x02  
 
   [21] 0x00  
 
   [22] 0x00  
 
   [23] 0x00  
 
   [24] 0x00  
 
   [25] 0x00  
 
   [26] 0x00  
 
   [27] 0x00  
 
   [28] 0x00  
 
   [29] 0x00  
 
   [30] 0x02  
 
   [31] 0x03  
 
   [32] 0x00  
 
   [33] 0x00  
 
   [34] 0x03  
 
   [35] 0x01  
 
   [36] 0x00  
 
   [37] 0x00  
 
   [38] 0x01  
 
   [39] 0x00  
 
   [40] 0x00  
 
 gRFAL.fifo.expWL = 64 
 
 gRFAL.fifo.bytesTotal = 0 
 
 gRFAL.fifo.bytesWritten = 0 
 
 gRFAL.fifo.status [0] = 3 
 
 gRFAL.fifo.status [1] = 22

A problematic combination of tags have:

(1)

[00] 0x04 0xEC 0xBC 0xDC

[01] 0xB2 0xEE 0x55 0x80

UID: 0x04 0xEC 0xBC 0xB2 0xEE 0x55 0x80

(2)

[00] 0x04 0xF4 0x0D 0x75

[01] 0xD2 0x67 0x60 0x80

UID: 0x04 0xF4 0x0D 0xD2 0x67 0x60 0x80

But (1) works fine with

(3)

[00] 0x04 0xB8 0x0E 0x3A

[01] 0xD2 0x67 0x60 0x80

UID: 0x04 0xB8 0x0E 0xD2 0x67 0x60 0x80

All tags used are NTAG210u, so ATQA is allways "00 44h".

[Ulysses HERNIOSUS]

Hi,

reading this I find:

• gRFAL.TxRx.ctx.txbufLen = 16 : 16 bits = 2 bytes to be sent
• gRFAL.TxRx.ctx.txbuf = 0x93 0x20 : Anticollision command of first Cascade Level
• gRFAL.fifo.status [0] = 3 = 0x3 : FIFO status register 1, denoting 3 bytes not yet read from the FIFO
• gRFAL.fifo.status [1] = 22 = 0x16 : : FIFO status register 2, last byte not complete, 3 bits valid

IMO this 2 bytes 3 bits are the bits which are in common for both of the tags (Cascade Tag 0x88 then 0x04 and the the three 1 bits from 0xEC and 0xF4.

I have the feeling that by increasing the speed of the code you shifted the point of timing issues to somewhere else.

Can you check your interrupt handling and possibly speed it further up? What is your SPI speed? Did you look at the SPI stream to verify its throughput and latency ?

Best Regards, Ulysses

[EBadi.2 · Accepted solution]

Hi Ulysses HERNIOSUS ,

I finally find out where the issue was. There were a few items to fix, mostly related to configuration GPIO and SPI:

• SPI was set on 80MHz/128 and now 80MHz/16
• SPI GPIO's were set FREQ_LOW, now FREQ_VERY_HIGH
• SPI interrupt has now more priority
• RFID Interrupt GPIO didn't have any pulldown, now is configured internally in the microcontroller.

Thanks for your support.