PN532 not responding with FTDI cable

[ktownsend]

I don't see anything obviously wrong with the board or chip itself, and those pins should have no issue soldered together since they're connected anyway.

The only possible HW explanation to me is a poor solder joint on the FTDI connector, or a fried chip if something was connected incorrectly. Can you perhaps post a photo of the solder joints for the FTDI header just to see if there are any cold solder joints?

I can't offer any real support with libnfc on the mac, and getting libnfc working is something you'd really have to take up on the libnfc forums (they're reasonably active) since it's not something maintained here.

The boards are definately tested before they go out, so the HW should be sound, though mistakes do happen, however rare. If you can post a photo, I'll have a look, and we can try switching the boards if everything looks good. For libnfc, I'd try posting on their forum to get some clarification on setting things up properly on a Mac.

[ktownsend]

I managed to get the board working on the Mac with Lion and libnfc 1.6.0-rc1. It didn't work out of the box, but following the suggestions from scott mentionned earlier and doing a rebuild, it worked for me. See viewtopic.php?f=19&t=22085

I built libnfc with the following options to include pn532_uart:

Code: Select all

wget http://libnfc.googlecode.com/files/libnfc-1.6.0-rc1.tar.gz
tar -xvzf libnfc-1.6.0-rc1.tar.gz
cd libnfc-1.6.0-rc1
./configure --with-drivers=pn532_uart --enable-serial-autoprobe
sudo make
sudo make install
cd examples

changing to the examples folder I get:

Code: Select all

Kevins-Mac-mini:examples kevin$ ./nfc-poll
/Users/kevin/libnfc-1.6.0-rc1/examples/.libs/nfc-poll uses libnfc 1.6.0-rc1 (r1326)
NFC reader: pn532_uart:/dev/tty.usbserial-FTE5WWPB - PN532 v1.6 (0x07) opened
NFC device will poll during 30000 ms (20 pollings of 300 ms for 5 modulations)
ISO/IEC 14443A (106 kbps) target:
    ATQA (SENS_RES): 00  04 
       UID (NFCID1): 3e  b9  6e  66 
      SAK (SEL_RES): 08 

That's all it took for me. Do you have the correct FTDI drivers installed? You'll also need some other dependencies like glib, libusb (v0.1 I believe), etc. You might want to try installing macports, and then install the (older) version of libnfc which should install most of the dependencies, uninstall just libnfc, and then try the version above.

Code: Select all

sudo port install libnfc
sudo port uninstall libnfc

I'm pretty hopeless with a Mac, though, and only bought one a few weeks ago to test stuff with, so there is likely someone else that might be able to offer more help on this. Let me know if that changes anything for you, though.

[DavidKaufman]

In my prior libnfc build, I did not use "sudo". Today I followed your steps:

Code: Select all

sudo make
sudo make install


Now I get results:

Code: Select all

/Users/david/DDK_Linux_Dev_Projects/libnfc-1.6.0-rc1/examples/.libs/nfc-poll uses libnfc 1.6.0-rc1 (r1326)
/dev/tty.usbserial-FTFXI984
trace   libnfc.driver.pn532_uart   Trying to find PN532 device on serial port: /dev/tty.usbserial-FTFXI984 at 115200 bauds.
trace   libnfc.bus.uart   Serial port speed requested to be set to 115200 bauds.
trace   libnfc.chip.pn53x   Diagnose
trace   libnfc.chip.pn53x   Timeout values: 500
trace   libnfc.bus.uart   TX: 55  55  00  00  00 
trace   libnfc.chip.pn53x   SAMConfiguration
trace   libnfc.chip.pn53x   Timeout values: 1000
trace   libnfc.bus.uart   TX: 00  00  ff  03  fd  d4  14  01  17  00 
trace   libnfc.bus.uart   RX: 00  00  ff  00  ff  00 
trace   libnfc.chip.pn53x   PN53x ACKed
trace   libnfc.bus.uart   RX: 00  00  ff  02  fe 
trace   libnfc.bus.uart   RX: d5  15 
trace   libnfc.bus.uart   RX: 16  00 
trace   libnfc.bus.uart   TX: 00  00  ff  09  f7  d4  00  00  6c  69  62  6e  66  63  be  00 
trace   libnfc.bus.uart   RX: 00  00  ff  00  ff  00 
trace   libnfc.chip.pn53x   PN53x ACKed
trace   libnfc.bus.uart   RX: 00  00  ff  09  f7 
trace   libnfc.bus.uart   RX: d5  01 
trace   libnfc.bus.uart   RX: 00  6c  69  62  6e  66  63 
trace   libnfc.bus.uart   RX: bc  00 
trace   libnfc.general   1 device(s) found using pn532_uart driver
...


Thanks for your help.

[DavidKaufman]

Finally found the difference. libnfc is sending this

Code: Select all

trace   libnfc.bus.uart   TX: 55  55  00  00  00


to wake-up the HSU from sleep mode. ("HSU wake up condition", page 99, pn532um.pdf)

[enzo]

Hi All,

Is it correct that you first have to wake-up the HSU before sending any other command?
We really don't want to use libnfc for controlling this chip. We have our own C/C++ code for controlling serial devices and the command set of the chip is not to complicated. But we also don't get any response back.

Can you tell me exactly which commands (bytes) are needed to start communication via HSU?

Thanks, Erik

[DavidKaufman]

At the bottom of http://www.ladyada.net/products/rfidnfc/about.html are links to documents.

The PN532 User Manual http://www.adafruit.com/datasheets/pn532um.pdf has a section called HSU wake up condition (page 99) where it says

When the host controller sends a command to the PN532 on the HSU link in order to exit from Power Down mode, the PN532 needs some delay to be fully operational (the real waking up condition is the 5th rising edge on the serial line.

As a consequence, if the host controller wants to be sure that the command will not be lost or partially received, some precautions must be taken:
* Either send a command with large preamble containing dummy data,
* Or send first a 0x55 dummy byte and wait for the waking up delay (Twake up time) before sending the command frame.

[enzo]

Thanks David, I will test this with our serial communication tool

[DavidKaufman]

I added a long wakeup to my serial test app:

Code: Select all

    *cmdPtr++ = PN532_HSU_WAKEUP;
    *cmdPtr++ = PN532_HSU_WAKEUP;
    *cmdPtr++ = 0;
    *cmdPtr++ = 0;
    *cmdPtr++ = 0;
    *cmdPtr++ = 0;
    *cmdPtr++ = 0;
    *cmdPtr++ = 0;
    *cmdPtr++ = 0;
    *cmdPtr++ = 0;
    *cmdPtr++ = 0;

    *cmdPtr++ = 0;
    *cmdPtr++ = 0;
    *cmdPtr++ = 0;

    *cmdPtr++ = PN532_STARTCODE1;
    *cmdPtr++ = PN532_STARTCODE2;
    *cmdPtr++ = cmdlen;
    *cmdPtr++ = ~cmdlen+1;


and then got the ACK.

I also found that testing with libnfc on my Mac does not always work. Sometimes it receives the initial ACK from the PN532 and sometimes it does not. I need to read more about the PN532 power down info, in case the lack of ACK is related to the wake-up time.

[Sly]

Hi all, I also have recently bought the PN532 breakout board and had little success, my original plan was to use the board with a minimus 32 board for testing via a USBtoSerial program and later a full program written on the minimus' ATmega32U2 but I had little success and then moved onto trying via a FTDI cable I got off ebay... http://www.ebay.co.uk/itm/290697403727? ... 060wt_1304 (The 5v model if anyones looking) and I've still had no success. I've tried versions 1.4, 1.5, 1.6rc1 and have been unable to get any response, all commands sent seem to just timeout... I know it's not alot to go on but I ask if anyone has advice on where to go from here? I've got the power light on so I know the board isn't totally messed up.

I'm not overly great with electronics, i'm a programmer and usually more high level stuff, i'm probably out my depth so sorry if some of the stuff I say/ask comes across as a bit dumb.

Is it possible the FTDI cable I've got has the wrong voltage for the Tx, Rx and that's why it doesn't work? Is it possible I've some how got a dud board or i've screwed up the PN532?

Any positive help or comments is appreciated! Thank in advance!

[DavidKaufman]

I found on my Mac that the PN532 did not always reply to the libnfc library. Sometimes it would timeout, other times it would work. I always tested with nfc_poll. With the serial test program, did you send 55 55 then lots of zeros the first time, before sending a command, to wake-up the PN532?

[Sly]

I forgot to add that mine setup is Linux (ubuntu) setup that i've been testing from... So I don't believe it's the same issue as what you've had running on the Mac, though I might wrong I guess.