Soft framing error clarification

[DGabc.1]

Hello,

I am using ST25R3911B and trying to understand in what cases Soft Framing Error will be generated - this is bit I_err2 in register 0x19.

Based on the datasheet, it looks like this is only used when operating in NFCIP-1 mode, which is enabled by setting bt nfc_f0 in register 0x05. Is that correct?

With register 0x05 set to 0, and using Type B at 424 Kbs, I noticed occasional soft frame errors. Is there any other condition that would trigger that error?

[Brian TIDAL]

Hi,

can you share more information about your setup?

• which kind a tag do you use (manufacturer and model)? 
• do you use your own custom reader board or an X-NUCLEO-NFC05A1 or a ST25R3911B-DISCO?
• do you use your own implementation or the ST RFAL middleware from the X-CUBE-NFC5 package or from the ST25 embedded NFC library?

Soft framing error can occur with type B: for example if TR1 is longer than the maximum. 

I would recommand to use the RFAL middleware. If not using it, I would recommand to check the analog settings from the one provided inside the RFAL.

Rgds

BT

[DGabc.1]

Hi,

I do not have information about the tag that was used.

My setup is ISO-14443 Type B, ST25R3911B-DISCO, using the ST RFAL library.

I am trying to understand if the Soft Framing error will be raised in all cases or only when using NFCIP-1 mode. In the datasheet, the Soft Framing error is mentioned only in relation with the NFCIP-1 mode.

Will the Soft Framing error be raised in all modes supported by ST25R3911B?

Thank you,

D.

[Brian TIDAL]

Hi,

basically a Soft Framing error is a framing error which does not result in RX data being corrupted. The datasheet does not provide a comprehensive list of cases causing this error. It can be raised in type B. Can you provide more information on your application? When using the RFAL, the I_err2 is managed by the FW according to the rfalEHandling error handling mode. By default, this error is ignored.

Rgds

BT

[DGabc.1]

Hello,

Thank you for this clarification. It is good to know that the soft framing error can be triggered for other protocols, not just NFCIP-1.

To have common base for the discussion - I use the source code from ST25RFAL001_v2.4.0.

If you look in rfal_isoDep.c, line 2346 (handling of Type B activation) - it sets error handling to EMD, even though you have the NFC poller initialized with NFC error handling. The RFAL_ERRORHANDLING_EMD causes soft framing errors not to be discarded - look in rfal_rfst25r3911.c - lines 2253-54 - specifically:

/* Discard Soft Framing errors if not in EMVCo error handling */
else if( ((irqs & ST25R3911_IRQ_MASK_ERR2) != 0U) && (gRFAL.conf.eHandling == RFAL_ERRORHANDLING_EMD) )

Why does the soft framing error is not ignored when in EMD mode? Or is EMD a typo and instead it should have been EMVCo (NFCIP-1 compliance)?

Thank you,

D.

[Grégoire Poulain]

Hi,

As my colleague tried to explain Soft Framing "errors" are not necessarily events that are erroneous.
Soft framing indicates that the frame which ST25R3911B received is not exactly as it expected.
This can indicate for example that the ISO14443B TR1 , or the Felica preamble was of different length than it expected.
Nevertheless the data/payload was received correctly and may be used.

With that being said, this is not necessarily an erroneous usage and some types of cards do deviate from the default NFC configuration in certain parameters but are still to be accepted.
Particularly in ISO14443B, there are several configurations possible (SOF, EOF, number of ETU, etc) that although valid are not the default one.
ST25R3911B will signal the Soft framing error, but it is up to the host to be able to understand in which mode is, and if expected with a particular card. Therefore sometimes this is disregarded.

As for EMVCo, without going into details, due to the strictness on this standard/use case, framing deviations are to be treated as an error, and not accepted.

Hope it helps

Kind regards
GP

[DGabc.1]

Hi,

Regarding when the soft framing error could be raised - all clear. Thank you for explaining.

But I am still not clear regarding the ST RFAL source code - as mentioned in my previous post, the code in one place uses EMD and in another, for the same constant, the comment says EMVCo.

Is the EMD a typo, which should have been EMVCo? Or is the EMVCo (in the comment) a typo, which should have been EMD?

Thank you,

D.

[Grégoire Poulain · Accepted solution]

Hi,

Historically EMD suppression was first adopted by EMVCo standard, today is present in other NFC standards.
The EMD error handling is activated when ISO14443 Layer 4 is reached.
When this protocol is running (ISO-DEP / ISO14333-4) soft framing errors are treated as errors.

Kind regards
GP