Отправьте команду TgInitAsTarget в PN532 (модуль ELEHOUSE), верните ACK-кадр назад, но потеряли нормальный информационный фрейм.

Question

В последнее время я начинаю работу с модуля PN532 NFC. Я могу успешно читать/писать карты M1 и S50.

Теперь я пытаюсь узнать, как использовать P2P-связь. Однако, , когда я отправляю команду TgInitAsTarget в модуль PN532 (модуль ELEHOUSE), я получаю кадр ACK, но я никогда не получаю нормальный информационный кадр, который должен последовать за ним.

Вот мои шаги:

1. Get PN532 в целевом режиме, посылая команду TgInitAsTarget:

   TgInitAsTarget: 
   { 00 00 ff 0x27 0xd9 
       d4 8c 04 
       08 00 12 34 56 40 
       01 fe a2 a3 a4 a5 a6 a7 c0 c1 c2 c3 c4 c5 c6 c7 ff ff 
       aa 99 88 77 66 55 44 33 22 11 
       00 
       00 
       fd 00 } 
   

2. Получить второе PN532 в режиме инициатора путем отправки команды InJumpForDEP:

   InJumpForDEP: 
   { 00 00 ff 0a f6 
       d4 56 01 02 
       01 00 ff ff 00 00 
       d4 00 } 
   

3. Положить инициатора над мишенью.

4. Когда я прочитал информацию, полученную от цели через UART, я получаю следующее:

   target->pc: 
   { 01 
       00 00 ff 00 ff 00 } 
   

   Это, как представляется, кадр АСК указывает на то, что команда TgInitAsTarget была обработана правильно. Но после этого PN532 не отправляет нормальный информационный кадр, содержащий результат команды TgInitAsTarget, и цель всегда находится в состоянии занятости.

0 Короткая фотография

Answer 1

Некоторые вещи кажутся неправильными с вашими командами.

1. Прежде всего, команда InJumpForDEP, по-видимому, искажена. Эта команда декодирует следующее:

    
   d4 56 InJumpForDEP 
       01 ActPass = Active Mode 
       02 Baud Rate = 424 kbps 
       01 Next = NFCID3i 
       00 ff ff 00 00 NFCID3i ? (HERE is the problem) 
   

   Поле NFCID3i этой команды недействительно. NFCID3i должен состоять из 10 байтов (например, 11 22 33 44 55 66 77 88 99 AA). Проще всего было бы позволить PN532 автоматически генерировать случайные NFCID3i, не определяя поле NFCID3i на всех:

    
   d4 56 InJumpForDEP 
       01 ActPass = Active Mode 
       02 Baud Rate = 424 kbps 
       00 Next = none 
   

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

2. Инициатор проводит опрос в активном режиме со скоростью передачи данных 424 кбит/с. Тем не менее, с помощью команды TgInitAsTarget, вы указываете цель, чтобы слушать в режиме PICC только:

    
   d4 8c TgInitAsTarget 
       04 Mode = PICC only ! (HERE is the problem) 
       08 00 12 34 56 40 MifareParams 
       01 fe a2 a3 a4 a5 a6 a7 c0 c1 c2 c3 c4 c5 c6 c7 ff ff FelicaParams 
       aa 99 88 77 66 55 44 33 22 11 NFCID3t 
       00 no Gt 
       00 no Tk 
   

   Следовательно, цель будет работать только в качестве стандарта ISO/IEC 14443-4 PICC (который похож на пассивном режиме при 106 кбит). Поэтому инициатор и целевая аудитория настроены на использование двух совершенно разных протоколов и, следовательно, не понимают друг друга. В результате, PN532 в целевом режиме никогда не будет вызываться PN532 в режиме инициатора и, следовательно, никогда не будет возвращаться из команды TgInitAsTarget.

   Для того, чтобы настроить цель таким образом, который совместим с конфигурацией инициатора, вы могли бы использовать это:

    
   d4 8c TgInitAsTarget 
       02 Mode = DEP only 
       08 00 12 34 56 40 MifareParams (not used in active mode) 
       01 fe a2 a3 a4 a5 a6 a7 c0 c1 c2 c3 c4 c5 c6 c7 ff ff FelicaParams (not used in active mode) 
       aa 99 88 77 66 55 44 33 22 11 NFCID3t 
       00 no Gt 
       00 no Tk (not used in active mode) 
   

Answer 2

Наконец, я решил проблему, это аппаратная проблема, и Я покупаю новый модуль PN532. Нормальный информационный кадр возвращается успешно. Спасибо в любом случае @ Майкл Роланд.