I can not reliably get the PN532 to respond to commands, other than the firmware info command. I am using HSU on Windows with a FTDI cable obtained from Adafruit as well as the v1.6 of their dev board.
The black reads are from the ReadFile call timing out, it is set to 20 with all the flow control stuff disabled.
I do not think it is the cable, as the wake up and firmware version stuff is valid and works every single time.
Serial port opening code:
// Open the COM port
HANDLE commHandle = CreateFile(
"\\\\.\\COM5",
GENERIC_READ | GENERIC_WRITE,
0,
null,
OPEN_EXISTING,
0,
null
);
// Get the existing settings
DCB serialSettings;
GetCommState(
commHandle,
&serialSettings
);
// Page 26 of the User Manual specifies these settings
serialSettings.BaudRate = CBR_115200;
serialSettings.ByteSize = 8;
serialSettings.StopBits = ONESTOPBIT;
serialSettings.Parity = NOPARITY;
// These did not make it any better or worse
serialSettings.fParity = false;
serialSettings.fOutxCtsFlow = false;
serialSettings.fOutxDsrFlow = false;
serialSettings.fDtrControl = DTR_CONTROL_DISABLE;
serialSettings.fDsrSensitivity = false;
serialSettings.fTXContinueOnXoff = true;
serialSettings.fOutX = false;
serialSettings.fInX = false;
serialSettings.fErrorChar = false;
serialSettings.fNull = false;
serialSettings.fRtsControl = RTS_CONTROL_DISABLE;
serialSettings.fAbortOnError = false;
// Setup the state
SetCommState(
commHandle,
&serialSettings
);
// Clean out any buffers or flags
PurgeComm(
commHandle,
PURGE_RXCLEAR | PURGE_RXCLEAR | PURGE_TXABORT | PURGE_TXCLEAR
);
Data that is written to and read from the HANDLE, using the sizes that where obtained from the output param.
Write: 55 55 00 00 00 00 00 00 00 00 FF 02 FE D4 02 2A 00
Read: 00 00 FF 00 FF 00 00 00 FF 06 FA D5 03 32 01 06 07 E8 00
Write: 00 00 FF 00 FF 00
Write: 00 00 FF 05 FB D4 14 01 14 01 02 00
Read:
Write: 00 00 FF 05 FB D4 14 01 14 01 02 00
Read:
Write: 00 00 FF 05 FB D4 14 01 14 01 02 00
Read:
Write: 00 00 FF 05 FB D4 14 01 14 01 02 00
Read:
Write: 00 00 FF 05 FB D4 14 01 14 01 02 00
Read:
Write: 00 00 FF 05 FB D4 14 01 14 01 02 00
Read:
Write: 00 00 FF 05 FB D4 14 01 14 01 02 00
Read:
Write: 00 00 FF 05 FB D4 14 01 14 01 02 00
Read:
Read:
Edit:
This appears to only happen on Windows, I tried the same process on Debian and it worked fine. I am using Java for this so I just had to rewrite the natives, so the communications itself seem functional. This is quite strange to me.
Related
currently I try to reimplement a C application in go. Part of the C application is to send a string to a multicast group. This produces the following packet captured via tcpdump:
00000000 d4 c3 b2 a1 02 00 04 00 00 00 00 00 00 00 00 00 |................|
00000010 ff ff 00 00 01 00 00 00 14 81 06 56 47 2c 01 00 |...........VG,..|
00000020 46 00 00 00 46 00 00 00 33 33 00 02 10 01 04 ce |F...F...33......|
00000030 ef ca fe 1a 86 dd 60 00 00 00 00 10 11 01 fe 80 |......`.........|
00000040 00 00 00 00 00 00 06 ce ef ff fe ca fe 1a ff 02 |................|
00000050 00 00 00 00 00 00 00 00 00 00 00 02 10 01 be 8f |................|
00000060 03 e9 00 10 99 68 6e 6f 64 65 69 6e 66 6f |.....hnodeinfo|
I tried to replicate the behavior with the following code:
const MultiCastGroup string = "ff02:0:0:0:0:0:2:1001"
const Port int = 1001
const Proto string = "udp6"
const MaxDataGramSize int = 8192
var announcedAddr = &net.UDPAddr{IP: net.ParseIP(MultiCastGroup), Port: Port}
buf := []byte("nodeinfo")
unicastConn, _ := net.ListenUDP(Proto, &net.UDPAddr{IP: net.IPv6zero, Port: 0})
unicastConn.WriteToUDP(buf, announcedAddr)
But the I don't think that it is working, because all I can capture from this via tcpdump is:
00000000 d4 c3 b2 a1 02 00 04 00 00 00 00 00 00 00 00 00 |................|
00000010 ff ff 00 00 01 00 00 00 |........|
00000018
It doesn't seem that the packet is even send. I tried this on a Debian Wheezy machine. Did anyone if you encounter a similar problem with golang and UDP?
Thanks in advance
Did you try to listen for it on another host?
Go (at least in 1.4) had a hard coded disable of loopback on multicast. Which means that, you can't see your own packets.
You can override this by calling setsockopt on the socket FD itself, or:
The golang.org/x/net/ipv6 library can do this for you.
Or you can take the code from Here (have to poke around to find it)
I am trying to use a PN532(NFC controller). Lately something in my SPI-communication is off. I start comunication by asking for the firmewareversion (D4 02). Next I try to set the SAM-Config. But the PN532 wont give an ACK nor an response.
What I observed is this. (all in hex)
GetFirmewareversion --- ACK<br>
MOSI: 01 00 00 FF 02 FE D4 02 2A 00 --- 02 00 03 00 00 00 00 00 00<br>
MISO: 00 FF FF FF FF FF FF FF FF FF --- FF 01 01 00 00 FF 00 FF 00
Receive Firmewareversion after ACK<br>
MOSI: 02 00 03 00 00 00 00 00 00 00 00 00 00 00 00<br>
MISO: 00 01 01 00 FF 06 FA D5 03 32 01 06 07 E8 00
Set SAMConfig --- see if ready(endless)<br>
MOSI: 01 00 00 FF 05 FB D4 14 01 14 01 02 00 --- 02 00 --- 02 00 --- 02 00<br>
MISO: AA AA AA AA AA AA AA AA AA FF FF FF FF --- FF 00 --- 00 00 --- 00 00
When I write my getFiremware he responds 0xFF, but when i try to set SAM he always responds with 0xAA. He also never replies an ACK or response to setSAMConfig.
Where is my Mistake? where is this Coming from? How to fix it?
THX in advance.
Insert some delay after asserting the PN532 chip select.
Had the same problem, this works for me:
void pn532_select (void)
{
FIO2CLR = PN532_CS; // assert CS
msleep (1); // relax a bit
}
I have problem with use direct command for mifare 1k via ACR122U. I use original SDK for Windows (including for delphi), and I sent these commands in one session:
FF 00 00 00 means pseudo-apdu. It is used to send direct commands to tag or to device (ACR).
<< FF 00 00 00 02 D4 02 // GET FIRMWARE
>> D5 03 32 01 06 07 90 00
<< FF 00 00 00 03 D4 12 24 // SET PARAMETERS (I want to disable not suported ISO 14443-4)
// (I also tried D2 12 14 without success)
>> D5 13 90 00
<< FF 00 00 00 0F D4 40 01 60 00 FF FF FF FF FF FF xx xx xx xx // auth with key A (tag UID hidden)
>> D5 41 00 90 00 // OK
<< FF 00 00 00 05 D4 40 01 30 00 // direct mifare read (30) block 00
>> D5 41 13 90 00 // ERROR 13 (incorrect value of PCB or PFB, invalid or unexpected received frame, NAD or DID incoherence, bad length of received RF frame).
I cannot read any card (i have three). All cards can be read with command FF B0 00 00 10...
Can you please tell me, what command(s) shall be sent before and after authentification to correctly communicate with the card? Please also send links to specification of commands Read register (D4 06) and write register (D4 08). I don't know what means register "63 05" (D4 06 63 05) for example.
BTW. What mean abbreviations (in context): NAD, DID, PFB, PCB?
I have problems with writing data to serial port with boost.
I use slightly modified minicom_client class from here:
https://code.google.com/p/vkbrd/source/browse/trunk/src/Dg5Emulator/MiniComClient.h
https://code.google.com/p/vkbrd/source/browse/trunk/src/Dg5Emulator/MiniComClient.cpp
First 17 bytes in message are sent good, but rest is substituted by:
FD FD FD FD AB AB AB AB AB AB AB AB EE FE EE FE 00 00 00 etc
Message length is correct.
When I call
for (int i = 0; i < 128; ++i)
miniComClient.do_write(i);
I receive this on the second side:
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F FD FD FD FD AB AB AB AB
AB AB AB AB EE FE EE FE 00 00 00 00 00 00 00 00 2E F1 5C 42 BD 8B 07 18
40 6D C1 03 E8 9E 40 02 00 00 00 00 00 00 00 00 04 00 00 00 01 00 00 00
F4 62 00 00 FD FD FD FD 40 54 40 02 FD FD FD FD AB AB AB AB AB AB AB AB
00 00 00 00 00 00 00 00 2F F1 5C 43 BF 8B 07 18 A0 A3 3B 02 38 A5 3B 02
00 00 00 00 00 00 00 00 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
FD FD FD FD AB AB AB AB AB AB AB AB EE FE EE FE 00 00 00 00 00 00 00 00
2E F1 5C 42 BD 8B 07 18 40 6D C1 03 E8 9E 40 02 00 00 00 00 00 00 00 00
04 00 00 00 01 00 00 00 F4 62 00 00 FD FD FD FD 40 54 40 02 FD FD FD FD
AB AB AB AB AB AB AB AB 00 00 00 00 00 00 00 00 2F F1 5C 43 BF 8B 07 18
A0 A3 3B 02 38 A5 3B 02 00 00 00 00 00 00 00 00
I have triple checked baud rate, stop bits and parity.
Is there some way to change send buffer size? Maybe this is some other problem.
Values like 0xfdfdfdfd, 0xabababab and 0xfeeefeee are magic numbers.
In other words, you are looking at uninitialized memory allocated from the heap. It is a pretty standard bug in serial port programming to assume that you get the entire message with one read. That only ever happens when you debug your program, slowing it down enough. Never when it runs at full speed, serial ports are very slow devices. You must pay attention to bytes_transferred in the read_complete() function and not interpret received data until you received all the bytes. This requires keeping track of the total, buffering partial data and having a good idea when the full response was received.
The byte value where the data turns into garbage is a magic number as well. 0x10 is the ASCII code for the Line Feed control character. Which is very often used as the End-Of-Message indicator. Be sure to configure whatever software you use on the other end of the wire to not check for a line terminator and only display the bytes it actually receives.
The reason of this problem is my "slight" modification to original code.
I wanted to make writing whole byte array simpler (instead of calling do_write() in loop), so I've added method:
void miniComClient::do_write_buffer( QByteArray msg )
bool write_in_progress = !writeMsgs.empty(); // is there anything currently being written?
for(int i = 0; i < msg.size(); ++i)
writeMsgs.push_back(msg[i]); // store in write buffer
if (!write_in_progress) // if nothing is currently being written, then start
write_start();
}
But the worst thing was my try to optimize things, so I've modified write_start() to something like this (send everything in buffer instead of just next byte):
void miniComClient::write_start( void )
{
// Start an asynchronous write and call write_complete when it completes or fails
boost::asio::async_write(serialPort,
boost::asio::buffer(&writeMsgs.front(), writeMsgs.size()),
boost::bind(&miniComClient::write_complete,
this,
boost::asio::placeholders::error));
}
This was a terrible mistake, because writeMsgs is of type std:deque so it is not stored continuously in memory, so it sends some bytes from the point I wanted, and garbage after that.
Please help me how to access Mi-fare ultralight 1k tag.
I tried the commands
ff 82 00 01 06 ff ff ff ff ff ff and ff 82 00 01 06 A1 A2 A3 A4 A5 A6
which load successfully on reader.
But When I try command
ff 88 00 01 60 00
which is use to authentication with tag
status words 63 00 (operation failed)
Log is listed below
[ACS ACR122 0] : Running script
[1] > ff 82 00 01 06 FF FF FF FF FF FF
< 90 00
[2] > ff 88 00 01 60 00
< 63 00
[ACS ACR122 0] : Running script
[1] > ff 82 00 01 06 A1 A2 A3 A4 A5 A6
< 90 00
[2] > ff 88 00 01 60 00
< 63 00
ATR of MIFARE 1K tag Which is I am using
3B 8F 80 01 80 4F 0C A0 00 00 03 06 03 00 01 00 00 00 00 6A
Below give script which is came with ACR122U reader for MIFARE 1K tag.
Which is also unsuccessful
Demo script for MIFARE 1K card and ACR122U PC/SC reader
(c) 2008, Advanced Card Systems Ltd.
[1] Load (Mifare Default) key in reader (key location 0)
FF 82 00 00 06 FF FF FF FF FF FF (9000)
; [2] Authenticate sector 0, Block 0 with key at location 0
FF 86 00 00 05 01 00 00 60 00 (9000)
; [3] Read the full 16 bytes from Sector 0, Block 1
FF B0 00 01 10 [xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx] (9000)
; [4] Update the 16 bytes in Sector 0, block 1
FF D6 00 01 10 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F (9000)
; [5] Read the full 16 bytes from Sector 0, Block 1 again
FF B0 00 01 10 [xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx] (9000)
; [6] Authenticate sector 1, Block 5 with key at location 0
FF 86 00 00 05 01 00 05 60 00 (9000)
; [7] Store a value "1" into block 5
FF D7 00 05 05 00 00 00 00 01 (9000)
; [8] Read the value block 5
FF B1 00 05 04 [xx xx xx xx] (9000)
; [9] Copy the value from value block 5 to value block 6
FF D7 00 05 02 03 06 (9000)
; [10] Read the value block 6
FF B1 00 06 04 [xx xx xx xx] (9000)
; [11] Increment the value block 5 by "5"
FF D7 00 05 05 01 00 00 00 05 (9000)
; [12] Read the value block 5
FF B1 00 05 04 [xx xx xx xx] (9000)
The card seems to me like MIFARE Classic 1K.
I think you have mistake in the key number that you are tying to authenticate with. Try this:
ff 82 00 01 06 FF FF FF FF FF FF //Set key with on slot 1
ff 88 00 01 60 01 //Auth with key from slot 1 to block 1
I hope this will help.