¿Por qué el código escrito para un chip se rompe en otro del mismo tipo?
Porque el tipo de etiqueta fija los comandos y no el mapa de memoria. Dos etiquetas de tipo 2 responden al mismo READ y ponen su configuración en páginas distintas, y una dirección fijada en el código que funcionaba en una cae en la memoria de usuario de la otra. Lee lo que informa la etiqueta.
Lo que fija el tipo
Un tipo de etiqueta del NFC Forum es un contrato sobre comandos: cuáles puede enviar un lector, cómo se direcciona la memoria, cómo se encuentra un mensaje NDEF. La página del tipo 2 y la página del tipo 4 exponen esos dos contratos.
Lo que no fija es todo lo que añade un chip: cuántas páginas existen, dónde vive la configuración, si hay un contador, un reflejo o una contraseña, y qué comandos de más responden. Eso pertenece al chip, y este sitio lo deja a las fichas de chips, como hace la página de la configuración con las páginas posteriores al área de datos.
Lo que informa la etiqueta
Casi todo lo que el código necesita se puede leer en vez de suponer. En Android, Ndef responde a tres preguntas sin tocar la radio: getType() devuelve el tipo del NFC Forum, getMaxSize() el mensaje más grande que acepta la etiqueta, e isWritable() si todavía admite una escritura. MifareUltralight.getType() distingue una Ultralight de una Ultralight C, y devuelve desconocido cuando no puede saberlo.
Por debajo, responde la etiqueta misma. El contenedor de capacidad de una etiqueta de tipo 2 da el tamaño del área de datos y su condición de acceso, y Get System Information en una etiqueta ISO/IEC 15693 da el tamaño de bloque y el número de bloques, que la página de la 15693 lee antes que nada. A un programa que pregunta a esas tres fuentes le queda muy poco que suponer.
La misma familia, dos mapas
El caso más claro es el de una familia. Una NTAG213 tiene 45 páginas, sus bits de bloqueo dinámicos en la página 40 y su configuración en las páginas 41 a 44; una NTAG215 tiene 135 páginas y guarda los mismos ajustes en las páginas 130 a 134, como describen sus fichas en wakdev.com. La página 41 es configuración en una y memoria de usuario corriente en la otra.
Un código que escribe una configuración por número de página corrompe entonces contenido en el chip equivocado, en silencio, y la etiqueta sigue leyéndose como si no hubiera pasado nada. Por eso la página de la configuración pide identificar el chip antes de ejecutar la secuencia.
Leer primero, escribir después
Detecta funciones en vez de modelos. Pregúntale a la etiqueta qué es y qué ofrece, ajústate, y niégate a seguir cuando la respuesta no sea una que tu código conozca: una negativa explícita es un informe de fallo, una escritura silenciosa es un lote corrompido.
Y guarda una etiqueta de cada chip en el juego de pruebas, que la página del juego de etiquetas pide de todas formas. Una etiqueta de un segundo tamaño de la misma familia encuentra esta clase de fallo en un minuto, y nada más lo encuentra antes que la producción.
Preguntas frecuentes
¿No basta el tipo de etiqueta para escribir código portable?
Para el NDEF sí. Para lo que hay por debajo no: las páginas, los tamaños y las direcciones de configuración pertenecen al chip y no al tipo.
¿Qué puedo leer en vez de suponer?
El tipo, el tamaño máximo y si se puede escribir, desde la plataforma; el contenedor de capacidad en una etiqueta de tipo 2, y la información del sistema en una ISO/IEC 15693.
¿Por qué mi escritura de configuración corrompió el contenido?
El número de página pertenecía a otro chip de la misma familia. En un chip más grande esa dirección es memoria de usuario.
¿Cómo cazo esto antes de la producción?
Guarda dos chips del mismo tipo y de tamaños distintos en el juego de pruebas, y ejecuta la secuencia en los dos.