As per my earlier blog post, I wondered if I could make a NFC card reader... Well, I have!
Tinkering
I am in a lucky position in many ways - whilst I have a "full time job", a lot of the day to day running of A&A is handled by my management team, so I can "tinker".
This means I can try things out, do R&D pretty much as much as I like, and try and make something like this NFC reader just for the hell of it. Of course there are practical applications - I have several of the Elechouse PN532 NFC readers here because we made access control and alarm systems for the office (and even sold one) which use them. I suspect we could make, and sell, these cards. But a lot of the R&D I do is speculative (and educational) - it might sell, or might lead to something that does, maybe. Indeed, my work on NFC and DESFire cards does look like it had led to a contract that is very worthwhile, but I could not have known that at the start. The more expertise we get as a company, the more we can sell.
So, to answer the questions people have asked, mainly "why?", it is mostly because I can!
Back to the NFC reader itself
I said it may be a nice idea to try and make my own reader, much like the Elechouse reader. Well, I went ahead, a proof of concept, and it works. Yes, I am shocked too.
As a version 1 board it was not perfect. For a start, it seems the data sheet for the crystal shows the underside of the chip pin out, so if you use that as the solder pads you end up back to front. Some messy soldering and wires allowed me to work around that.
I also found soldering a QFN-20 chip hard, even with my heat gun (hence the charring), so I have ordered an oven. I'll blog on that later. I may eventually progress to solder paste masks and the like. We'll see how it goes. Even so, this is all well within the grasp of the amateur / hobbiest.
I also found the LEDs would not work - apart from ordering the wrong LEDs (diode drop was more than the supply voltage, idiot), it seems GPIO P34 does not play and I can't work out why. I have read the data sheet over and over, tried loads of config changes, and it should work, but I cannot make it work (and cannot on the Elechouse boards either), so re-done using other GPIO pins.
 |
| Version 1 board - actually works! |
Version 2 board
I also decided to move to smaller 0805 components instead of 1206 - simply because of the challenge of fitting all the components on such a small board. I have made a number of value changes to more closely match the PN532 reference circuit. So that is next. I also think the Elechouse boards can overload the receiver, and it meant my Amex card would not read on my board, but a component change and it does now!
But first I need to actually test the two LEDs that should work do in fact work well enough, and test the oven when it arrives. If all goes well I'll order some version 2 boards and test.
What is wrong with other boards?
If you search for NFC readers you find two main types of things you can buy: (a) a nice plastic card reader with rubber feet to sit on your desk and connect via a USB lead to your PC, or (b) a "development board" with lots of 0.1" spaced pins to allow you to tinker, usually quite large. What you don't find is a board designed to actually be used as a component in an access control system.
To be fair, the Elechouse is pretty close - it has lots of extra pads for general tinkering but is not bad. What is lacked was LEDs for feedback and a tamper switch. That is what I have added. Just to be clear, my board is not a copy of the Elechouse, and is based on the reference circuit in the PN532 datasheet.
My board is HSU (High Speed UART) only (as that is better on a length of wire than I2C), only four wires (GND/VCC/TX/RX), and a choice of connectors on either side of the board for easy use in an access system or in a nice simple case as a device on your desk connected to a PC, if that is what you want. I'll do a 3D case design as well for both.
So I actually think my board design will be a good, usable, and even sellable board. If there is any demand I may get a few hundred properly made. But it is also nice that I am making this all open source, not just the s/w drivers, but the actual PCB layouts so you can easily order and make yourself if you want.
This is the version 2 board so far... May be real boards next week.
[P.S. I have ordered these now...]
Update: The V2 board work, and I have sent to an RF engineer to check if I need to make any tweaks before making the next version.
...a lot of the day to day running of A&A is handled by my management team, so I can "tinker".
ReplyDeleteAh, the joys of being top dog.
Odds are you've been through all this N times, but a few notes from the datasheet, just in case:
ReplyDeleteLooks like a dangerous pin :-)
1. Unlikely but maybe some interaction:
Remark: If hide_svdd_sig of the register control_rngpower is set and
gpirq_enable_P34 is also set then this bit will be asserted independently
of the level on the pad P34.
2. SIC_CLK ?
4 P3[4] When P34 alternate function SIC_CLK is not used, writing to P3[4] writes the
corresponding value to P34 pin according to the configuration mode defined by
P3CFGA[4] and P3CFGB[4].
Reading from P3[4] reads the state of P34 pin
3. Also unlikely but ...
6 hide_svdd_sig Configures internal state of input signals SIGIN and P34 when
idle. This bit can be used to avoid spikes on SIGIN and P34 when the
SVDD switch is enabled or disabled.
When set to logic 0, internal state of SIGIN and P34 are driven by pads
SIGIN and P34 respectively.
When set to logic 1, internal state of P34 is fixed set to logic 1.
4.
The PN532 generates the supply SVDD to the secure IC. The pins SIGIN and SIGOUT
are referred to this supply, as well as p
5.
4. Promising?
4 sic_switch_en Enables or disables power to SVDD switch. When set to logic 0,
SVDD switch is disabled and SVDD output is tied to the ground.
When set to logic 1, the SVDD switch is enabled and the SVDD output
delivers power to secure IC and internal pads (SIGIN, SIGOUT and
P34)
Odds are you've been through all this N times, but a few notes from the datasheet, just in case:
1. Unlikely but maybe some interaction:
Remark: If hide_svdd_sig of the register control_rngpower is set and
gpirq_enable_P34 is also set then this bit will be asserted independently
of the level on the pad P34.
2. SIC_CLK ?
4 P3[4] When P34 alternate function SIC_CLK is not used, writing to P3[4] writes the
corresponding value to P34 pin according to the configuration mode defined by
P3CFGA[4] and P3CFGB[4].
Reading from P3[4] reads the state of P34 pin
3. Also unlikely but ...
6 hide_svdd_sig Configures internal state of input signals SIGIN and P34 when
idle. This bit can be used to avoid spikes on SIGIN and P34 when the
SVDD switch is enabled or disabled.
When set to logic 0, internal state of SIGIN and P34 are driven by pads
SIGIN and P34 respectively.
When set to logic 1, internal state of P34 is fixed set to logic 1.
4.
The PN532 generates the supply SVDD to the secure IC. The pins SIGIN and SIGOUT
are referred to this supply, as well as p
5.
4. Promising?
4 sic_switch_en Enables or disables power to SVDD switch. When set to logic 0,
SVDD switch is disabled and SVDD output is tied to the ground.
When set to logic 1, the SVDD switch is enabled and the SVDD output
delivers power to secure IC and internal pads (SIGIN, SIGOUT and
P34)
6. The 13.56MHz clock can be switched to P34 / SIC_CLK (see sic_clk_p34_en bit in
Table 177 on page 145).
7. 6330h 1 CIU_SIC_CLK_en Enables the use of secure IC clock on P34 / SIC_CLK
8. Or something else :-)