When using `pn53x` chip with target not compatible with `InListPassiveTarget` (like `NMT_ISO14443BICLASS`, `NMT_ISO14443B2CT` & `NMT_ISO14443B2SR` by eg.), the logic behind `nfc_initiator_select_passive_target` to return target count seems to be buggy
`nfc_initiator_select_passive_target`:
> Returns:
> Returns selected passive target count on success, otherwise returns libnfc's error code (negative value)
In `pn53x_initiator_select_passive_target_ext`, the return value in success is always `abtTargetsData[0]`. This is correct when using `InListPassiveTarget` as the first byte is `NbTg`, but it can be problematic for other cases.
- Example with a Mifare:
```
gentilkiwi@pi5:~/libnfc-dev $ ./utils/nfc-list -t 1
NFC device: Elechouse NFC Module V3 (SPI) opened
## End of function 'pn53x_initiator_select_passive_target_ext'...
## abtTargetsData content is : 01 01 00 04 08 04 1a da 74 44
## return will be: 0x01 (?)
1 ISO14443A passive target(s) found:
ISO/IEC 14443A (106 kbps) target:
ATQA (SENS_RES): 00 04
UID (NFCID1): 1a da 74 44
SAK (SEL_RES): 08
```
- Example with 2x ST25TB:
```
gentilkiwi@pi5:~/libnfc-dev $ ./utils/nfc-list -t 32
NFC device: Elechouse NFC Module V3 (SPI) opened
## End of function 'pn53x_initiator_select_passive_target_ext'...
## abtTargetsData content is : 35 a5 f2 a4 68 1f 02 d0
## return will be: 0x35 (?)
1 ISO14443B-2 ST SRx passive target(s) found:
ISO/IEC 14443-2B ST SRx (106 kbps) target:
UID: 35 a5 f2 a4 68 1f 02 d0
```
```
gentilkiwi@pi5:~/libnfc-dev $ ./utils/nfc-list -t 32
NFC device: Elechouse NFC Module V3 (SPI) opened
## End of function 'pn53x_initiator_select_passive_target_ext'...
## abtTargetsData content is : 00 92 f0 a4 68 1f 02 d0
## return will be: 0x00 (?)
0 ISO14443B-2 ST SRx passive target(s) found.
```
The proposed PR will fix the target count to 1 when not using `InListPassiveTarget`, since current versions of target initialisation do not support for more.
- Results:
```
gentilkiwi@pi5:~/libnfc-dev $ ./utils/nfc-list -t 32
NFC device: Elechouse NFC Module V3 (SPI) opened
1 ISO14443B-2 ST SRx passive target(s) found:
ISO/IEC 14443-2B ST SRx (106 kbps) target:
UID: 00 92 f0 a4 68 1f 02 d0
gentilkiwi@pi5:~/libnfc-dev $ ./examples/nfc-st25tb
|mode : info
Reader : Elechouse NFC Module V3 (SPI) - via pn532_spi:/dev/spidev0.0:500000
...wait for card...
Target : ISO/IEC 14443-2B ST SRx (106 kbps)
UID : 00 92 f0 a4 68 1f 02 d0
Manuf : 0x02 - STMicroelectronics
ChipId : 0x1f - ST25TB04K
Serial : 0x68a4f09200
|blk sz : 32 bits
|nb blks: 128
|sys idx: 255
```
(also checked for non-regression with `InListPassiveTarget`, including multiples `A` targets)
Modification to set PN53X_REG_CIU_TxAuto, PN53X_REG_CIU_CWGsP & PN53X_REG_CIU_ModGsP registers values before init.
Avoids a dummy scan in B mode before
pn53x.c:1746:15: warning: Function call argument is an uninitialized value
*cycles = __pn53x_get_timer(pnd, pbtTxRaw[szTx + 1]);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The pn532 documentation differs slightly from the included ascii art
documentation on how a packet looks like. The preamble was omitted
however the postamble is mentioned. This patch adds the Preamble to the
ascii frame documentation.
The code later refers incorrectly to the start byte as the preamble.
This variable was renamed to more descriptively state that it is the
preambe and the start bytes.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
When there is no tag on PN532 reader, the library
incorrectly processed call result and returned
NFC_ECHIP (chip error) instead of 0 (no targets
found).
Goal is to implement "ping" on MFC the same as PN533 does. This patch implements MFC re-selection, but do not take care about authentication; this means this will have side effect while you are authenticated on a MFC block.