Pourquoi un code écrit pour une puce casse-t-il sur une autre du même type ?
Parce que le type de tag fixe les commandes, pas la carte mémoire. Deux tags de type 2 répondent au même READ et placent leur configuration dans des pages différentes, et une adresse figée dans le code qui marchait sur l'un atterrit dans la mémoire utilisateur de l'autre. Lisez plutôt ce que le tag annonce.
Ce que le type fixe
Un type de tag du NFC Forum est un contrat sur les commandes : lesquelles un lecteur peut envoyer, comment la mémoire s'adresse, comment un message NDEF se trouve. La page du type 2 et la page du type 4 exposent ces deux contrats.
Ce qu'il ne fixe pas est tout ce qu'une puce ajoute : combien de pages existent, où vit la configuration, s'il y a un compteur, un miroir ou un mot de passe, et quelles commandes supplémentaires répondent. Cela appartient à la puce, et ce site le laisse aux fiches de puces, comme le fait la page de la configuration pour les pages qui suivent la zone de données.
Ce que le tag annonce
L'essentiel de ce dont le code a besoin se lit plutôt qu'il ne se suppose. Sur Android, Ndef répond à trois questions sans toucher la radio : getType() rend le type du NFC Forum, getMaxSize() le plus grand message que le tag accepte, et isWritable() s'il prend encore une écriture. MifareUltralight.getType() distingue une Ultralight d'une Ultralight C, et rend inconnu quand elle ne sait pas trancher.
En dessous, c'est le tag lui-même qui répond. Le conteneur de capacité d'un tag de type 2 donne la taille de la zone de données et sa condition d'accès, et Get System Information sur un tag ISO/IEC 15693 donne la taille et le nombre de blocs, ce que la page ISO 15693 lit avant toute chose. Un programme qui interroge ces trois sources n'a plus grand-chose à supposer.
La même famille, deux cartes
Le cas le plus net tient dans une seule famille. Un NTAG213 a 45 pages, ses bits de verrouillage dynamiques en page 40 et sa configuration en pages 41 à 44 ; un NTAG215 a 135 pages et garde les mêmes réglages en pages 130 à 134, comme le décrivent leurs fiches sur wakdev.com. La page 41 est de la configuration sur l'un et de la mémoire utilisateur ordinaire sur l'autre.
Un code qui écrit une configuration par numéro de page corrompt donc du contenu sur la mauvaise puce, en silence, et le tag continue de se lire comme si de rien n'était. C'est pourquoi la page de la configuration demande d'identifier la puce avant de dérouler la séquence.
Lire d'abord, écrire ensuite
Détectez des fonctions plutôt que des modèles. Demandez au tag ce qu'il est et ce qu'il offre, ajustez, et refusez de continuer quand la réponse n'est pas une que votre code connaît : un refus explicite est un rapport de bug, une écriture silencieuse est une série corrompue.
Et gardez un tag de chaque puce dans le jeu de test, ce que la page du jeu de tags demande de toute façon. Un tag d'une seconde taille dans la même famille trouve cette classe de défaut en une minute, et rien d'autre ne la trouve avant la production.
Questions fréquentes
Le type de tag ne suffit-il pas à écrire du code portable ?
Pour le NDEF, si. Pour tout ce qui est en dessous, non : pages, tailles et adresses de configuration appartiennent à la puce et non au type.
Que puis-je lire au lieu de supposer ?
Le type, la taille maximale et la possibilité d'écrire depuis la plateforme, le conteneur de capacité sur un tag de type 2, et les informations système sur un tag ISO/IEC 15693.
Pourquoi mon écriture de configuration a-t-elle corrompu le contenu ?
Le numéro de page appartenait à une autre puce de la même famille. Sur une puce plus grande, cette adresse est de la mémoire utilisateur.
Comment attraper cela avant la production ?
Gardez deux puces du même type et de tailles différentes dans le jeu de test, et déroulez la séquence sur les deux.