Open Source PN532 HW (Page 1 of 2)

You can already use all three.  I have two jumpers to select between UART, I2C and SPI though I've only ever tested UART.  All the useful pins are broken out, though.

Yes ... I spoke a few times with the guy working on it.  I'm aiming for something a bit more basic, though, and just want to be able to do basic NFC stuff with an inexpensive MCU.  My interest is just providing a reusable building block that can make it easier to develop other dedicated HW or peripherals.

I've already ordered the PCBs so they should be here in 2 week or so, and I should have enough parts on hand to make a small first batch.  I'll have to sit down and add up the part cost and PCBs and what I spent on the prototypes to figure out a price, but it should be fairly reasonable.  My interest is just recovering the money spent getting the board working (three prototypes plus parts, etc.), plus reimbursing Roel who ordered the PN532s.

Sounds good.  I already have working 1343 boards (see www.microbuilder.eu) that I'll hook up to the breakout board for now using UART.  It's trivial to combine the two boards later into a single PCB once the SW is working.  Once I get the PN532 breakouts in I'll let you know here though since I suspect some of you are in a far better position to port parts of libnfc than me.  I already have code to handle UART, I2C and SPI, though ... it's just the libnfc stuff.  I'll post a photo when I get the boards back and post the schematic and gerber files if the boards are OK (which I'm 99% sure they are).

Kevin

Very nice! Exactly as I except for. When could you send some boards, even prototypes to test it?

I wasn't sure whether the components would interfere with the antenna, and for a breakout board for development the size isn't really that critical so I didn't think it was worth spending a couple hundred Euros on a new design (one test spin plus the production tooling costs and PCB fees).  For a combined stand-alone board (PN532 + ARM) I'll place all the components in the middle, though, and try to make the antenna a little bit longer to improve the range a bit.

I ordered the boards a couple days ago and it's usually two weeks, but with Christmas maybe 2-3 days more.  I can probably put some together the first week of January.

Last edited by ktownsend (2010-12-23 17:59:54)

Got the PCBs in this morning and put two together to test.  Everything seems fine over UART, though I have no way at present to test anything via SPI or I2C.

http://yfrog.com/f/h7rsrej/

The range isn't extraordinary ... I can read an ov-chipkaart from about 3.5cm ... but the antenna isn't huge either, and perhaps I can add another 0.5-1.0cm if the board can be tuned a bit better.  I might try making a larger antenna and placing everything in the middle on a future revision, but I need to make sure all the HW is fine first.

Should be useful for development, though, since everything is broken out to 0.1" headers, etc.

I'd really like to do some basic tests first in SW before I put it in the store or publish the board files since I don't want to mislead anyone if there are any problems (though admittedly the board is pretty simple).  I believe there is SW SPI support in the Linux kernel, if I2C isn't an option (though I'm hardly a Linux expert and made this mainly for use with small embedded devices).  UART is fine for a PC, but something like SPI or I2C can sometimes be easier in embedded devices ... though it seems NXP has managed the SPI in kind of a wierd/non-standard way as well with the PN53x. :-(  I'll take a look at the link you mentionned though.

I didn't see that, but it's on request only so no surprise.  I think the antenna is actually OK, though, other than maybe needing some tuning.  Physical size is probably the biggest factor.  If I can get access to a network analyser I can probably improve it a bit or maybe I'll try to hit up someone I know who has one to measure it for me.  What is the typical range for a card like that (ov-chipkaart/RET) out of curiousity?

What I'd love is to get this working with a cheap MCU and make a small dedicated device that can log data, etc., but I'd need some help on the SW side since I don't have enough familiarity with NFC.  If you're interested in collaborating on an integrated open source/HW design I'd be glad to send you a PN532 board plus an LPC1343 or LPC1114 board.  Just email me via the contact page at microbuilder.eu.

Last edited by ktownsend (2011-01-03 14:19:35)

Hey,

Yes, I have received 4 prototypes.
It works but antenna's electronic need to be tweaked a bit: some devices need to "stick on" antenna to works.

We will annouce on this forum when the board will be available.
BTW, if anybody want to join the development effort of this project, send me a pm or an email.

Roel was able to get the boards tuned, which seems to have made a significant difference in range, especially for smaller tags.  I put together a small first batch of updated boards and will have more parts this week to put some more together next week.  It will take a bit of time to make some tutorials or documentation, but the HW at least seems sound.

I think your you're seeing the "Unable to wakeup" message because the board is permanently 'woken up' since the RSTPD_N pin is pulled high. (I've actually been thinking about putting a solder jumper on this in the enxt revision to be able to disable this as well.)  The board seems to be working if you're seeing the "PN532 will pooll during 30000 ms" message.  Just place a card over the antenna and you should see the details from it.

As said, this board works as expected, messages can be ignored in this case, BTW, I think the RSTPD_N pin should be pulled low to save some power.
Do you know if when RSTPD_N pin is high we can put the PN532 in sleep mode using the right software command ?
(I have to check this point in user manual, if I have enough spare time one day, I hope to implement sleep mode in libnfc.)

Hey,

Currently, I'm rewrinting PN532_UART driver in order to (greatly) speed up communication and improve the robustness.
During this rewriting I saw a interesting thing: your PN532 breakout board NEED to be waken up !

For a while, I dropped the PN532 wake up sequence at start and the board doesn't reply !
If I send the wake up sequence, the device become reachable again... So, its confirmed: your board start in sleeping mode, BTW, that's exactly what I'm expecting

Good news for planet, bad news for developers who will have to code wake up

BTW, I hope to implement a real sleep/awake mode handling in libnfc soon, currently its just a wake up sequence at start but we can make better.

Hi

I'm working with a little project where I'm trying to connect the breakout board from microbuilder.eu to an ARM Cortex-M3 from STMicroelectronic via UART.

I'ved quickly tried to get it to work but I cannot get it to answer me. I'm sending it the wakeup sequence (0x55, 0x55, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xff, 0x03, 0xfd, 0xd4, 0x14, 0x01, 0x17, 0x00), but I don't get any reply from it. The IRQ-pin is always high, I'ved tried to also send the ACK-command (0x00, 0x00, 0xFF, 0x00, 0xFF, 0x00) but nothing happens.

I've verified that all voltage levels are on the right level. I've also verified that I get the commands on UART both in a terminal program and with an oscilliscope.

How should the pins on the board be connected? Obviously 3.3 V, GND, the communication interface selection, Tx and Rx are straightforward, but the rest? What about RSTPDN_N  / RSTOUT_N? Any other pins that are necessary?

What other HEX commands are there out there? I've found these:
char NFC_startup[]     = {    0x55, 0x55, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
                        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
                        0xff, 0x03, 0xfd, 0xd4, 0x14, 0x01, 0x17, 0x00 };
char NFC_ack[]         = { 0x00, 0x00, 0xFF, 0x00, 0xFF, 0x00 };
char NFC_nack[]        = { 0x00, 0x00, 0xFF, 0xFF, 0x00, 0x00 };
char NFC_in_out     = { 0xFF };
char NFC_error[]    = { 0x00, 0x00, 0xFF, 0x01, 0xFF, 0x7F, 0x81, 0x00 };
char NFC_ext[]        = { 0x00, 0x00, 0xFF, 0xFF, 0xFF };
char NFC_com_start[]= {    0x00, 0x00, 0xFF };

Last edited by maax (2011-04-01 11:58:43)