TI RF430FRL152HEVM NFC NDEF форматирование

Мы разработали плату на основе оценочного модуля TI RF430FRL152HEVM с возможностью NFC. Когда телефон Android приближается к антенне платы, NFC позволяет процессору загрузиться и начать считывание данных. Он помещает данные, которые он читает, в память.

Затем телефон должен извлечь эти данные из устройства с помощью NFC (или, скорее, ISO 15693).

Единственный способ, которым мы знаем, как сделать это на данный момент, - это записать его в стандартные блоки памяти NFC.

Мы загрузили приложение для Android под названием NFC TagInfo, и это позволяет нам сканировать наш датчик и собирать все данные в памяти датчика, то есть все блоки.

Мы записываем это в то, что производитель чипов называет областью сообщений NDEF во FRAM. Я написал приложение для чтения / записи NFC для другого проекта, которое работает хорошо, но оно отказывается читать данные здесь, хотя NFC TagInfo действительно читает данные.

Мы предполагали, что микросхема TI была отформатирована в формате NDEF, но вся найденная нами документация о том, как это сделать, очень неясна. Таким образом, мы предполагаем, что это не было.

Может кто-нибудь объяснить, как правильно подготовить содержимое памяти, чтобы сообщение NDEF могло быть прочитано телефоном?

Дополнительная информация

Мы записываем данные в FRAM, начиная с блока 0 и далее, и пытались имитировать данные, которые можно увидеть в типичном теге, содержащем очень простое сообщение NDEF. Например, мы сохранили сообщение "ABCD" и, используя NFC TagInfo, вы видите это в первых нескольких блоках:

04 5c d8 08 4a 62 3e 80
96 48 00 00 e1 10 12 00
01 03 a0 0c 34 03 21 d1
01 1d 54 02 65 6e 41 42
43 44 20 20  ...

куда 41 42 43 44 это "ABCD" в UTF-8.

Мы взяли эти данные (формат NDEF + заголовки) из другого тега (прочитанного с использованием NFC TagInfo) и скопировали эти данные в блоки FRAM нашего чипа тега. Мы остановились в конце сообщения NDEF, а остальная часть FRAM 0x00 или же 0xff,

Очевидно, что тег, из которого мы скопировали данные (NXP), и наш чип-тег (TI) от разных производителей, поэтому некоторые данные в первых нескольких блоках недопустимы для нашего чипа TI, но предполагается, что Android это не должно волновать.

Однако, когда мы читаем наш тег TI с помощью NFC TagInfo, он может читать необработанные блоки данных, но не распознает тег как тег, отформатированный в NDEF.

  • Не является ли форматирование NDEF, скопированное из другого тега, недопустимым для нашего тега, поскольку мы не используем одинаковые размеры памяти тегов и т. Д.?

  • Если кто-то просто записывает правильные байты в правильные блоки, то может ли что-нибудь быть воспринято как NDEF, в конце концов, на низком уровне, в чем разница?

  • Если это так, то какой будет наиболее разумный контрольный пример использования байтов, в каких блоках, есть ли лучший способ проверить концепцию?

  • Блокировка блоков имеет какое-то значение? Как мы видим, некоторые блоки заблокированы в реальном теге.

  • Почему NFC TagInfo иногда видит блоки, а затем страницы, когда обнаруживается NDEF? Являются ли блоки и страницы одинаковыми?

  • В противном случае, как мы можем кодифицировать в Android простое чтение блоков так же, как NFC TagInfo выполняет шестнадцатеричный дамп? Если мы можем сделать это, тогда NDEF на самом деле не нужен.

Дополнительная информация 2

Я изменил прошивку таким образом, чтобы FRAM, начиная с блока 0, содержал упомянутые вами данные:

E1 40 F2 09 03 0B D1 01
07 54 02 65 6E 41 42 43
44 FE 00 00 00 00 00 00

Однако я не могу поставить чип TI в режиме 8-байтового блока. Похоже, что нет контрольного регистра, связанного с этим.

С моей точки зрения низкого уровня, запись блоков в 4 или 8 байтов не является проблемой, то есть, я побайтно записываю вышеупомянутые данные последовательно в память FRAM.

Когда я запускаю NFC TagInfo, он делает две вещи, но не обнаруживает сообщение NDEF:

  • Он правильно определяет UID, и тот факт, что RF Tech является Типом 5 (ISO 15693 / Vicinity)
  • Он также правильно читает блоки, и при выборе отображения данных в шестнадцатеричном формате я точно вижу вышеуказанные данные в блоках, начиная с блока 0 .

Я ознакомился со спецификацией NFC Tag Type 5, которую я получил по http://open-nfc.org/documents/STS_NFC_0707-001%20NFC%20Tag%20Type%205%20Specification.pdf

Поэтому я попытался записать больше данных в TAG из блока 0, чтобы попытаться эмулировать блоки SERIAL NUMBER, CONFIGURATION, Issuer area. А затем я поместил сообщение NCDF ABCD после разделов:

01 02 03 04 05 06 07 08 // серийный номер
00 00 00 80   00 10 00 00   // конфигурация...

Я использовал NFC TagInfo, но я также не смог обнаружить сообщение NDEF. Тем не менее, используя дисплей шестнадцатеричных данных, я мог убедиться, что данные были правильно считаны, как указано выше.

Итак, мои вопросы:

  • Уместно ли настраивать режим блока 4 или 8 байтов и где, скорее всего, этот режим определен? Могу ли я все равно работать в режиме 4-байтового блока?
  • Соответствует ли серийный номер TAG 5? Кажется, не влияет на проверку NDEF в соответствии со спецификацией.
  • Актуален ли эмитент области применения TAG 5? Кажется, не имеет отношения к проверке NDEF.
  • Находится ли сообщение NDEF, которое я поместил в правильную область?
  • Для 16-битных значений это старшие байты младшие байты или младшие байты старшие байты?
  • Есть идеи, что не так?

Дополнительная информация 3

Оказалось, что TI необходимо предоставить патч, чтобы заставить NDEF работать с этим чипом (FRL152H). По сути, микросхема предназначена для поддержки высокоуровневого управления функциями сенсора через NFC с использованием внутреннего встроенного программного обеспечения. Это приложение нужно было отключить и некоторые настройки изменились.

Получилась следующая конфигурация памяти:

Блок 0: Е1 40 79 00
Блок 1:  03 0B D1 01
Блок 2:  07 54 02 65
Блок 3:  6е 41 42 43
Блок 4:  44 FE 00 00
Источник

1 ответ

Решение

Неужели форматирование NDEF, скопированное из другого тега, недопустимо для нашего тега?

Это именно проблема. Глядя на первые 12 байтов дампа памяти, вы явно скопировали блоки данных из NXP NTAG203 (или аналогичного), как указано в коде производителя (байт 0: 0x04) и объем памяти в контейнере возможностей (байт 13: 0x12). Серии NXP NTAG и MIFARE Ultralight соответствуют спецификации NFC Forum Type 2 Tag Operation. Однако ваша микросхема TI (RF430FRL152H) основана на стандарте ИСО / МЭК 15693 и, следовательно, соответствует спецификации работы с тегами типа 5 форума NFC. Спецификации операции с тегами определяют форматы данных и наборы команд, которые превращают тег NFC в тег NDEF. Существует несколько (в настоящее время 5) различных таких спецификаций, потому что технология NFC объединяет несколько различных стандартов RF (ISO/IEC 14443, FeliCa, ISO/IEC 15693) и использует оборудование тегов, которое уже существовало для этих стандартов до NFC.

Почему NFC TagInfo иногда видит блоки, а затем страницы, когда обнаруживается NDEF? Являются ли блоки и страницы одинаковыми?

В этом случае блоки и страницы эквивалентны. Другая формулировка просто происходит от терминологии, используемой производителями микросхем. Обратите внимание, что чип RF430FRL152H использует термин "страницы" для группировки нескольких блоков и, следовательно, с другим значением.

Если кто-то просто записывает правильные байты в правильные блоки, то может ли что-нибудь быть воспринято как NDEF, в конце концов, на низком уровне, в чем разница?

Разница заключается в том, что вашему чипу тега TI RF430FRL152H необходимо использовать другое кодирование для области памяти NDEF, чем тег NXP. Это просто потому, что он использует другую низкоуровневую коммуникационную технологию (модуляция, кодирование, кадрирование, набор команд) и, следовательно, следует другой спецификации операции тегов форума NFC.

Чтобы сделать ваш чип тега тегом NDEF, вам необходимо использовать следующее кодирование для области памяти NDEF, начиная с блока 0: обратите внимание, что контейнер возможностей был заполнен значениями, которые предполагают размер блока 8 байтов. Вы можете изменить параметр размера блока ISO, используя флаг ISOBlockSize в Регистре управления встроенным программным обеспечением (см. Раздел 7.54 "Регистр управления системным программным обеспечением" в Руководстве пользователя встроенного программного обеспечения RF430FRL15xH).

E1 40 F2 09 03 0B D1 01
07 54 02 65 6E 41 42 43
44 FE 00 00 00 00 00 00

Это приведет к сообщению NDEF, содержащему одну текстовую запись с сообщением "ABCD".

Первые 4 байта (E1 40 F2 09) являются контейнером возможностей:

  • 0xE1 это магическое число, идентифицирующее контейнер возможностей для тега, где вся область памяти может быть адресована однобайтовыми адресами блоков.
  • 0x40 кодирует версию 1.0 отображения памяти тега типа 5 и указывает свободный доступ для чтения / записи в память.
  • 0xF2 определяет общую область памяти NDEF (за исключением байтов CC), чтобы иметь длину 242 (0xF2) умножить на 8 байт (= 1936 байт). Смотрите раздел " Теория против практики " ниже!
  • 0x09 указывает, что ваш тег поддерживает команду READ_MULTIPLE_BLOCKS (установлен бит 0) и команду LOCK_BLOCK (установлен бит 3).

Следующие 2 байта (03 0B) являются заголовком сообщения NDEF TLV (структура данных, кодированных по длине тега):

  • 0x03: Байт заголовка, указывающий сообщение NDEF TLV.
  • 0x0B: Длина сообщения NDEF TLV = 11 байтов.

Следующие 11 байт (D1 01 07 54 02 656E 41424344) являются сообщением NDEF:

  • 0xD1: Запись заголовка байта:
    • Биты 7 и 6: это единственная запись сообщения NDEF.
    • Бит 4: это короткая запись (т.е. длина полезной нагрузки кодируется одним байтом).
    • Биты 2..0: Тип записи кодирует общеизвестный тип NFC Forum.
  • 0x01: Поле имени типа имеет длину 1 байт.
  • 0x07: Поле полезной нагрузки имеет длину 7 байтов.
  • 0x54: Имя типа (в ASCII: "T"), указывающее общеизвестный тип текстовой записи NFC Forum (Text RTD).
  • 0x02.. 0x44: Поле полезной нагрузки текстовой записи:
    • 0x02: Текст кодируется в UTF-8, поле языка состоит из 2 байтов.
    • 0x65 0x6E: Поле языка (в ASCII: "en"), указывающее язык английский.
    • 0x41 0x42 0x43 0x44: Текст полезной нагрузки (в UTF-8: "ABCD").

Следующий байт (FE) - терминатор TLV, указывающий конец используемой области данных. Остальные байты этого блока должны быть заполнены нулями (0x00), чтобы избежать проблем с некоторыми устройствами Android.

Блокировка блоков имеет какое-то значение?

Нет, блокировка блока не меняет способ обнаружения вашего тега. Это только меняет способ доступа к нему с устройства чтения (Android): доступ для чтения / записи или доступ только для чтения.

Будет ли этот тег обнаруживаться на всех устройствах Android?

К сожалению нет. Спецификация работы с тегами типа 5 форума NFC была завершена только в июле 2015 года. Хотя некоторые устройства Android реализовали NDEF для тегов ISO/IEC 15693 (NFC-V) до этой даты, не ожидайте, что это относится ко всем устройствам Android. Это должно работать на большинстве устройств, начиная с Android 5.0, хотя. Некоторые устройства Android должны поддерживать NDEF для некоторых тегов NFC-V даже в Android 4.3.

Теория против практики

После некоторого дальнейшего тестирования я обнаружил, что даже устройства, которые поддерживают NDEF для тегов типа 5 (NFC-V), по-видимому, имеют существенные ограничения (ошибки???) в реализациях своего стека NFC. Я тестировал Samsung Galaxy S6 (Android 5.1.1) с двумя типами тегов из серии TI Tag-it HF-I:

  1. Tag-it HF-I Plus (пользовательская память 2048 бит, в блоках 64 x 4 байта)
  2. Tag-it HF-I Standard (256-битная пользовательская память, в блоках 8 x 4 байта)

К сожалению, никто из них не работал с Galaxy S6, используя контейнер возможностей, который я описал выше. Проблема заключалась в размере области памяти NDEF (MLEN, хранящейся в третьем байте CC). Очевидно, что использованный выше размер слишком велик для этих двух тегов. Следовательно, я уменьшил его, чтобы он соответствовал размеру памяти тегов для каждого тега:

  1. Tag-it HF-I Plus:
    • 64 х 4 байта = 256 байтов
    • 256 байт / 8 = 32 (MLEN всегда рассчитывается как кратное 8 байтам)
    • минус 1 блок, поскольку CC не считается частью области данных (в соответствии со спецификацией операции с тегами типа 5)
    • MLEN = 31 = 0x1F
    • CC: E1 40 1F 09
  2. Tag-it HF-I Standard:
    • 8 х 4 байта = 32 байта
    • 32 байта / 8 = 4 (MLEN всегда рассчитывается как кратное 8 байтов)
    • минус 1 блок, поскольку CC не считается частью области данных (в соответствии со спецификацией операции с тегами типа 5)
    • MLEN = 3 = 0x03
    • CC: E1 40 03 09

Тем не менее, это не сработало. Теги не были обнаружены как теги NDEF (только как NdefFormatable). Наконец, я обнаружил, что Galaxy S6 обнаруживает эти теги, только если байт MLEN точно отражает размер всей области памяти (включая байты CC). Таким образом, работали только следующие значения:

  1. Tag-it HF-I Plus:
    • CC: E1 40 20 09
  2. Tag-it HF-I Standard:
    • CC: E1 40 04 09

Еще хуже, пока ЦК E1 40 04 09 работал с тегом Tag-it HF-I Standard, он не работал с тегом Tag-it HF-I Plus. Таким образом, стек NFC Galaxy S6, по-видимому, ожидает очень специфических значений для CC для разных продуктов-тегов.

Исходя из этого, следующие значения CC должны работать для RF430FRL152H:

  1. когда размер блока установлен в 8 байтов: E1 40 F3 09
  2. когда размер блока установлен в 4 байта: E1 40 79 09

"должен", так как неясно, как теги идентифицируются и сопоставляются с их ожидаемыми значениями CC. Более того, неясно, знает ли Galaxy S6 какое-либо ожидаемое значение CC для этого конкретного чипа.

Другой способ найти "правильные" (= ожидаемые) значения для байтов CC состоит в том, чтобы записать сообщение NDEF в тег, используя NdefFormatable технологии, а затем чтение байтов CC с помощью приложения для чтения тегов, такого как NFC TagInfo:

Tag tag = intent.getParcelableExtra(NfcAdapter.EXTRA_TAG);
NdefFormatable ndefFormatable = NdefFormatable.get(tag);

if (ndefFormatable != null) {
    try {
        ndefFormatable.connect();
        ndefFormatable.format(new NdefMessage(NdefRecord.createTextRecord("en", "ABCD")));
    } catch (Exception e) {
    } finally {
        try {
            ndefFormatable.close();
        } catch (Exception e) {
        }
    }
}

То же самое можно сделать с помощью какого-либо универсального приложения для записи тегов (за исключением NXP TagWriter, который, похоже, не может записать в тег).

В противном случае, как мы можем реализовать простое чтение блоков в Android так же, как NFC TagInfo выполняет свой шестнадцатеричный дамп?

RF430FRL152H должен быть обнаружен Android как тег NFC-V (ISO/IEC 15693 в терминологии NFC). Поэтому, как только вы получите намерение NFC, вы можете получить дескриптор тега и получить экземпляр NfcV класс для него:

Tag tag = intent.getParcelableExtra(NfcAdapter.EXTRA_TAG);
NfcV nfcV = NfcV.get(tag);

Вы можете подключиться к тегу и обмениваться низкоуровневыми командами (например, READ_SINGLE_BLOCK), используя метод transceive:

nfcV.connect();
byte[] tagUid = tag.getId();  // store tag UID for use in addressed commands

int blockAddress = 0;
byte[] cmd = new byte[] {
    (byte)0x60,  // FLAGS
    (byte)0x20,  // READ_SINGLE_BLOCK
    0, 0, 0, 0, 0, 0, 0, 0,
    (byte)(blockAddress & 0x0ff)
};
System.arraycopy(tagUid, 0, cmd, 2, 8);

byte[] response = nfcV.transceive(cmd);

nfcV.close();

Где я могу получить дополнительную информацию о форматировании тегов, командах NDEF и низкоуровневых командах?

  • Спецификация работы тега NFC Forum Type 5: с веб-сайта NFC Forum (к сожалению, спецификации NFC Forum больше не доступны бесплатно).

    ВАЖНО: будьте осторожны, чтобы не смешивать это с "Спецификацией NFC Tag Type 5", предлагаемой open-nfc.org. Хотя в обеих спецификациях говорится о теге " Тип 5 ", они относятся к совершенно другой платформе тегов. Спецификация open-nfc.org не совместима с чипом RF430FRL15xH.

  • Общедоступным документом, который очень близок к окончательной спецификации операции тега типа 5 форума NFC, является примечание к приложению NXP AN11032 Операция тега типа ICODE типа NXP. Однако существуют некоторые существенные различия между спецификацией операции тега типа 5 форума NFC и примечанием к приложению (особенно в отношении формата контейнера возможностей).
  • Спецификация формата обмена данными NFC (NDEF): также с веб-сайта NFC Forum или отсюда.
  • Спецификация определения типа записи (RTD) NFC: также с веб-сайта NFC Forum или отсюда.
  • Спецификация определения типа текстовой записи: также с сайта NFC Forum или отсюда.
  • NFC-V в спецификации цифрового протокола: также с веб-сайта NFC Forum.
  • ИСО / МЭК 15693: Этот стандарт определяет стандартные команды низкого уровня.
  • RF430FRL15xH Руководство пользователя: Пользовательские команды для доступа к области памяти RAM можно найти в разделах 4.6ff.
Источник
Другие вопросы по тегам