NF C Тег становится "поврежденным" после того, как writeNdefMessage прервал ввод-вывод - PullRequest
Новая
       55

NF C Тег становится "поврежденным" после того, как writeNdefMessage прервал ввод-вывод

5 голосов
/ 28 мая 2020

У нас есть приложение Android, которое взаимодействует с тегом NF C на настраиваемом аппаратном устройстве. Аппаратное устройство также может связываться и выполнять операции с тегом, установленным на нем.

Приложение Android взаимодействует с тегом NF C двумя способами:

  1. IsoDep#transceive(byte[]) для запуска цикла включения питания аппаратного устройства.
  2. Ndef#writeNdefMessage(NdefMessage) для записи NdefMessage / NdefRecord с некоторыми пользовательскими данными.

Функционально эти операции выглядят примерно так: 

private static final byte[] NDEF_SELECT_APP_FRAME = new byte[] {
    (byte) 0x00, (byte) 0xA4, (byte) 0x04,                  
    (byte) 0x00, (byte) 0x07, (byte) 0xD2,                  
    (byte) 0x76, (byte) 0x00, (byte) 0x00,                  
    (byte) 0x85, (byte) 0x01, (byte) 0x01                   
}; 

private static final byte[] SYSTEM_FILE_SELECT = new byte[] {   
    (byte) 0x00, (byte) 0xA4, (byte) 0x00,                  
    (byte) 0x0C, (byte) 0x02, (byte) 0xE1,                  
    (byte) 0x01                                             
};                                                              

private static final byte[] TOGGLE_GPO = new byte[] {           
    (byte) 0xA2, (byte) 0xD6, (byte) 0x00,                  
    (byte) 0x1F, (byte) 0x01, (byte) 0x00                   
}; 

boolean recordSuccess = writeRecord(tag, intent, context);
if (recordSuccess) {
    boolean success = transceive(NDEF_SELECT_APP_FRAME, tag, context)
            && transceive(SYSTEM_FILE_SELECT, tag, context)
            && transceive(TOGGLE_GPO, tag, context);
    if (success) {
        // Success!
    } else {
        // Error!
    }
}

Мы обнаружили, что очень иногда кажется возможным, что ввод-вывод может быть прерван во время записи данных Ndef (мы не уверены, почему, но мы предполагаем, что телефон отодвигается от тег в нужное время является причиной). Похоже, это приводит к тому, что тег находится в «поврежденном» состоянии, когда предыдущие данные Ndef больше не могут быть найдены в теге. Фактически, tag.getTechList() даже не будет указывать Ndef как доступную технологию в теге, хотя изначально она была доступна.

Все дальнейшие попытки записать данные Ndef в тег потерпят неудачу, потому что Ndef.get(tag) вернет null.

Насколько мне известно, обычной процедурой с этого момента было бы переформатирование тега с использованием NdefFormatable. Однако NdefFormatable не указан как тип технологии в tag.getTechList(), поэтому NdefFormatable.get(tag) также возвращает null.

Вопросы:

  1. Почему тег кажется поврежденным / стираемым?
  2. Почему Ndef не указан как технология тегов после повреждения, даже если тег изначально его поддерживал?
  3. Как мы можем выйти из этого состояния , учитывая, что NdefFormatable.get(tag), похоже, возвращает null?

EDIT: Чип NF C выглядит как M24SR04-Y. Таблицу спецификаций можно найти здесь: https://www.st.com/resource/en/datasheet/m24sr04-g.pdf.

Возможности Содержимое контейнера, отображаемое приложением TagInfo: 

# Capability Container (CC) file content:
Mapping version 2.0
CC length: 15 bytes
Maximum Le value: 246 bytes
Maximum Lc value: 246 bytes
NDEF File Control TLV:
* Length: 6 bytes
* NDEF file ID: 0x0001
* Maximum NDEF data size: 512 bytes
* NDEF access: Read & Write
[0] 00 0F 20 00 F6 00 F6 04 06 00 01 02 00 00 00    |.. ............ |

Ответы [ 2 ]

2 голосов
/ 01 июня 2020

После того, как я взглянул на предоставленную вами таблицу данных, следующие мои наблюдения:

  • 0xE103: CC Файл
  • 0x0001: Файл NDEF
  • CC Файл доступен только для чтения из RF и I2 C
  • Максимальный размер файла NDEF: 512 байт
  • Чтение и запись: свободный доступ
  • Максимальное количество байты могут быть прочитаны или записаны за одну операцию: 246 байтов
  • Предполагая, что CC содержимое никогда не менялось: 00 0F 20 00 F6 00 F6 04 06 00 01 02 00 00 00: 15 байтов

Что касается фрагмента кода операций, которым вы предоставили доступ:

  1. Что вы делаете в TOGGLE_GPO? Сессия открыта, WIP или MIP?
  2. Я подозреваю, что карта переходит в состояние, подобное повреждению, когда она прерывается на этом этапе
  3. Предполагается, что вы не изменяете содержимое файла CC в writeRecord ().
  4. Если возможно, поделитесь низкоуровневой информацией о каждом шаге, который вы выполняете, что поможет лучше понять.

Обновление:

  • Теперь, когда возможность испорченного CC исключена, следующим шагом будет то же самое для NDEF TLV, особенно для блока V, где идентификатор файла NDEF, макс. Размер NDEF и доступ для чтения / записи файла NDEF сохраняются путем сравнения значений рабочего и поврежденного состояний.
  • Определите шаг, на котором при возникновении ошибки карта переходит в поврежденное состояние. Этого можно добиться, регистрируя каждый шаг. Если карта повреждается при прерывании на определенном c шаге последовательно, то это сузит поиск.
  • Попробуйте УСТАНОВИТЬ StateControl, когда карта находится в поврежденном состоянии. Это всего лишь случайная мысль, но она может помочь.

Ура!

2 голосов
/ 28 мая 2020

На этот вопрос очень сложно ответить, не зная, какой это тип карты и какой спецификации NF C она соответствует.

Первый шаг к пониманию этого - получить таблицу данных для NF C открытка. Возможно, стоит использовать приложение Android, такое как nxpinfo, чтобы попытаться определить тип чипа и тип спецификации NF C на карте, что затем может привести к использованию спецификации datasheet / nf c.

Ответы
2) Поддержка NDEF на карте определяется тем, что в большинстве спецификаций называется «Контейнером возможностей». Он может храниться по указанному адресу блока c или другим способом его чтения.

Если не существует «контейнера возможностей», который можно прочитать определенным методом для используемой спецификации NF C, то карта не будет считаться поддерживающей NDEF и форматируемой.

Возможно, это Пользовательская карта и «Контейнер возможностей» также были повреждены.

1) Неизвестно без дополнительных сведений о типе карты, но другая причина может заключаться в том, что 2 устройства чтения / записи пытаются получить доступ к карте одновременно время (один с аппаратного устройства и один из приложения). Нормальная запись / чтение NDEF не должно вызывать проблем, но может быть аппаратное устройство использует какой-то специальный метод доступа к карте.

Надеюсь, когда вы используете приложение для доступа к карте, оборудование отключено, поэтому это невозможно для этого типа CLA sh.

Если нет, можно сделать простую катушку провода, подключенного к светодиоду, чтобы сделать базовый детектор поля c NF C, чтобы проверить, периодически ли делать с картой вещи, которые могут вызвать cla sh.

3) Снова трудно ответить, зная больше о карте, НО может быть возможно переписать то, что, вероятно, является пользовательским типом карты «Контейнер возможностей» на низком уровне, чтобы сделать его снова форматируемым, если это было причиной проблемы.

Обновление

Как представляется, это NF C Микросхема типа 4, но также имеет интерфейс I2 C. В нем также есть несколько расширенных нестандартных команд

Вопрос

Я думаю, что оборудование подключено через i2 C?

Чтение SPE c похоже, что на карте есть 2 уровня безопасности, которые не входят в NDEF spe c (я не уверен, что приложение nxpinfo поймет значения, но может их показать).

Итак, это Возможно, файл NDEF защищен паролем или доступен только для чтения.

Если файл NDEF имеет пароль записи, обычное форматирование NDEF не сможет его отформатировать.
Вам потребуется нестандартный Verify command и пароль для авторизации перед форматированием.

Если файл NDEF был навсегда заблокирован (только для чтения), то только соединение I2 C может разблокировать файл NDEF. Карту в этом состоянии нельзя отформатировать через какое-либо приложение Android.

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

Обновление 2

Хорошо, значит, карта не защищена паролем и не заблокирована, потому что последние 2 байта файла CC равны 00

И как Адар sh более качественное ведение журнала может помочь определить причину, надеюсь, ваши методы transceive проверяют массив байтов ответа из IsoDep.tranceive и регистрируют все неуспешные коды, а также любые исключения, такие как TagLostException, IOException, et c, также

Хотя вы утверждаете, что повреждение может быть вызвано выходом телефона за пределы диапазона, в таблице данных также показано, что соединение I2 C может иметь приоритет над соединением RF с телефона, убивая ВЧ-соединения это также может вызвать повреждение данных NDEF.

Если РЧ-соединение было прервано соединением I2 C, то телефон, вероятно, не сможет ничего сделать с РЧ-соединением, пока оно не будет удалено из зоны действия и снова не возвращено.

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

Но, поскольку эта карта updates карты (может писать в начале карты или в любом смещении), я бы ожидал Android всегда начинать с начала при записи сообщения NDEF, поэтому не имеет значения, были ли байтовые маркеры TLV повреждены в результате усеченной записи для нового writeNdefMessage. Повреждение TLV может помешать Android читать сообщения NDEF из файла. (Необходимо проверить Android исходный код ОС, чтобы подтвердить, что она делает)

...