Comment lire les blocs d'un tag ISO/IEC 15693 ?

Comment se construit une requête

Une requête ISO/IEC 15693 est un octet de drapeaux, un code de commande, puis des paramètres. La référence de NfcV demande au code Android exactement ces trois parties et ajoute le CRC elle-même. Core NFC construit la requête pour chaque commande standard et prend les drapeaux comme un ensemble d'options, NFCISO15693RequestFlag.

Quatre drapeaux comptent pour la lecture, avec les valeurs que leur donnent les définitions de la pile NFC libre d'Android :

Sans le drapeau d'adressage ni celui de sélection, tout tag du champ qui reçoit la requête l'exécute, ce qui est sans conséquence avec un tag et ambigu avec deux. Core NFC pose le drapeau d'adressage par défaut et envoie l'identifiant du tag avec la commande, et poser le drapeau de sélection désactive l'adressage, selon la référence de readSingleBlock.

L'ordre des octets de l'identifiant est là où les portages cassent. Apple donne identifier dans l'ordre gros boutiste, si bien qu'il commence par 0xE0, l'octet par lequel commence tout identifiant ISO/IEC 15693 selon les définitions de la pile Android. Un code qui construit une requête adressée à la main, ou qui compare des identifiants lus sur les deux plateformes, vérifie de quel côté se trouve le 0xE0 avant de s'en servir.

Demander sa taille au tag d'abord

Get System Information, 0x2B, rend un octet de drapeaux d'information, l'identifiant, puis des champs facultatifs, dont la taille mémoire. Ce champ donne le nombre de blocs et la taille d'un bloc, tous deux encodés diminués de un, la taille du bloc dans ses cinq bits de poids faible ; la pile Android ajoute un à chacun avant de s'en servir.

Sur iOS, getSystemInfo rend les valeurs décodées, et depuis iOS 14 systemInfo(requestFlags:) les rend comme NFCISO15693SystemInfo, avec blockSize et totalBlocks.

La réponse varie avec la puce. La pile Android traite des blocs de 4, 8, 16 et 32 octets, et une ICODE SLIX2 a 80 blocs de quatre octets, le dernier portant un compteur, selon sa fiche sur wakdev.com. Certaines puces omettent la taille mémoire, et la pile Android se rabat alors sur des tailles qu'elle connaît pour certaines références, une table qu'une application devrait tenir elle aussi.

Un bloc ou plusieurs

Read Single Block, 0x20, prend un numéro de bloc, de 0 à 255 dans la forme standard, comme l'indique la référence d'Apple. Read Multiple Blocks, 0x23, prend le premier bloc et un compte encodé diminué de un, si bien que 0x00 lit un bloc.

Un tag de plus de 256 blocs demande les commandes étendues, dont les numéros de bloc prennent deux octets : Extended Read Single Block vaut 0x30, venu de la spécification NFC Forum Type 5 Tag selon la référence d'extendedReadSingleBlock d'Apple, et 0x33 en lit plusieurs.

Read Multiple Blocks est facultative. Sur un tag formaté pour le NDEF, le bit 0 du quatrième octet du conteneur de capacité, dans le bloc 0, dit si le tag la prend en charge, et la pile Android lit ce bit avant d'employer la commande. Sans elle, lisez un bloc à la fois.

Erreurs et commandes propriétaires

Un tag qui refuse une requête répond avec le bit d'erreur, 0x01, posé dans ses drapeaux de réponse, suivi d'un code d'erreur : 0x03 pour une option que le tag ne prend pas en charge, 0x13 pour un bloc qu'il n'a pas réussi à écrire, parmi les codes que nomme la pile Android. Core NFC rapporte une telle réponse comme une erreur dont les informations portent NFCISO15693TagResponseErrorKey et le code de la norme.

Les codes de commande 0xA0 à 0xDF sont des commandes propriétaires, définies par chaque fabricant de puces. La référence de customCommand d'Apple insère le code du fabricant après l'octet de commande, et les commandes elles-mêmes, comme celles qui gèrent les mots de passe d'une puce, viennent de la fiche de cette puce.