RoadTest: Integrating NFC with the NXP PN7150
Author: BigG
Creation date:
Evaluation Type: Development Boards & Tools
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?: NXP's PN532 (using Adafruit breakout board or Arduino shield), NXP's PN7120 SBC kit, and ST's NFC05A1 NUCLEO Arduino Shield (although this uses a NFC reader chip)
What were the biggest problems encountered?: No simple test points or on-board LED's to show that the hardware is working. No software documentation on NCI-protocol or proper documentation support for PN7150 code library. PN7150 interface board lacks pull-up resistors and lacks flexibility to choose different GPIO's for IRQ and VEN pins - there was a pin conflict with the FRDM-KW41Z kit we were given too.
Detailed Review:
For my road test report, I thought to begin with a short story that illustrates my user experience.
Maybe this sounds familiar. You have a neighbour who’s been poorly and you offer to cut their grass for them. They readily accept your offer and tell you that they have a lawnmower for you to use. You arrive to find that it’s a well-known brand petrol lawnmower, which you’ve never used before, but hey you’ve used many others in the past so it shouldn’t be a bother.
Well, after a good few hours of persistent tugging at the starter cord it simply won’t start. You’re sweating now, partly because of the physical exertion, but more so because you realise you face the acute embarrassment of having to go and ask for the user manual. Reading through the user manual does not really help either.
Exasperated you decide to start checking over the various components and discover that it has the wrong version of the spark plug inserted. You then dash off to get the correct one only to find, after another extended period of frustrated tinkering, that the lawnmower is very particular about timings and that the gap between electrodes has to be just right...
And so eventually you get it right and that lawnmower handles the job superbly.
Now let's jump into the road test proper, starting with a brief explanation of my approach.
As I spend a good deal of my time prototyping, I like to approach a road test by following a certain testing format... which is to ascertain ease and speed of development / debugging using the tools and documentation provided then once familiar with how things work I will attempt to expand and test my knowledge with a simple demo project. To achieve this aim within the allotted timescale the following will get reviewed:
Once again, I would like to thank Element 14 and NXP for sending me this package to road test. This is very much appreciated.
I decided to attempt to make an unboxing video but it was so bad I had to scrap it. So, kudos to all those who are able to do these videos in one take and get the commentary to make sense at the same time. So here are some pictures revealing the unboxing process instead, which I then created in video format - sorry I couldn't help myself.
My first impression was that the graphic design and information provided on all the packaging was very good.
The PN7150 NFC Controller SBC Kit for Arduino comes with a sample NFC card (NTAG Type 2) which is nice. There is no printed quick start guide included, which is no problem to me. Instead there is a URL on the back of the box, printed in bold purple text. You have to then apply a bit of common sense to know this would be a good place to start to get going.
We were also given a FRDM-KW41Z Freedom Development kit to use as part of the PN7150 review. This does come with a Quick Start Guide, which has a handy board pinout reference. The only minor thing that caught my attention was that labelling on the FRDM-KW41Z box was a little confusing. On the box it’s titled “FREEDOM DEVELOPMENT BOARD”, which in my mind would literally mean a board and hence I looked twice at the labelling, which said Quantity 1. In my view it should really say “Freedom Development Kit” as it has 2 x FRDM-KW41Z development boards.
Typing the URL, as found on the back of the box, into a web-browser takes you to NXP’s landing page for all the OM5578 Development Kits.
This is a single web-page which is sub-divided into page-marked topics:
Let’s now look at the next level of detail, starting with the Quick Start Guide PDF document.
The Quick Start Guide starts by providing three objectives:
Unfortunately, the document structure then does not quite follow the order of the objectives and I found it hard to follow the logic behind the hierarchical structure used and the content provided within, especially as my focus (with the FRDM-KW41Z) was to use the controller board with RTOS or Null OS created firmware.
The step by step installation guide is very poor as 10 out of 20 pages were dedicated just to a UDOO Neo board and no other board. This was of no relevance to me and only caused me confusion while reading through, especially as they were mainly demo related too. These pages should really be pushed to another document as they’ve done with the FRDM K64F example.
There is then just one page (section 3) on a non Linux or Android environment for the FRDM K64F board. This section is not really informative either and simply refers the user to this other document.
So, in my opinion, I wouldn't consider this to be a good quick start guide as it is not MCU hardware agnostic as it focused mainly on the UDOO Neo and to a lesser extent the FRDM K64F board. To improve, I would suggest more focus should be given on providing a good intro to the PN7150 module itself and the R3 compatible interface board.
At the very least this document should make reference to AN11759 – The PN7150 Product Quick Start Guide as this is a very useful document.
On a more positive note, the references given at the end of the document (section 4) are quite useful and as such my recommendation for now is if users want to save time they should move straight to this reference section and then onto the PN7150 Product Quick Start Guide.
Finally once you’re digested this Quick Start guide, I found that there was very little guidance as to where to go next, other than to look at AN11990 (NXP-NCI MCUXpresso example documentation) and the User Manual (UM10935). So I obediently followed this track.
This is actually a rather useful document and parts of it should really be pulled into the Quick Start Guide (AN11841).
It seems to follow a similar pattern as the Quick Start Guides in that the stuff I found the most relevant (sections 5 and 6) were stashed near the back of the document.
For someone who has never used any of NXP development boards before I did not find section 2 that meaningful as it did not apply to the FRDM-KW41Z board, or at the time of first read I did not know how to relate the information given to the FRDM-KW41Z board, in terms of pinouts, for example.
Section 3 was more useful as it related to the MCUXpresso IDE which I had also not used before. Here it provided a link to a project archive for the FRDM-K64F board and provided instruction on how to import this project into the IDE.
Section 4 provided an overview of the K64F based demonstration software, which was not really helpful as I had a different board. However, once you have the code up and running it is quite a useful section as it briefly explains the different operating modes available.
Section 5 provides a good description of the software architecture. If you are like me, your eyes will gravitate towards section 5.3, which is the porting recommendation for other MCUs.
Here it provides a slightly misleading comment “The only modules requiring adaptations is the TML components (relates to how the target provides this support), others modules being platform agnostics.” This is not strictly true and there are many places where the library code makes reference to another customised utility library named Tool.h/Tool.c. This omission cost me a good few hours of my time just trying to work this one out as I first thought this was an automated library file and not a custom utility type library. It does seem rather strange to me that a sleep or delay function is not automatically provided with a standard library as part of the IDE.
By the time you’ve got this far in the document you are itching to go. However, I found out later that it is very useful to continue reading as section 6 provides some vital information that will help you grasp what is going on inside the library and more importantly how to customise certain aspects of it to make it work on different hardware.
As stated in the User Manual introduction, this document provides the following:
The document is appended with further design details on antenna design, how to change the I2C address and much more (basically, it’s all the sort of things that should make the front section of a good user manual). Hence my impression is that it is back to front and needs reorganising.
According to the introduction in this document, it provides information on two things.
Firstly, it describes how to start working with PN7150 to add NFC functionality to a device - this essentially provides a link to PN7150 Product Data Sheet.
And secondly, it points to where you will find dedicated information for hardware, antenna and software integration as well as information related to the PN7150 demo kit for reference implementation to be used as example.” - this section is rather useful in that it provides references or document links to a range of information, such as low power operation, by way of example.
As mentioned this is my first time using the NXP development environment and the first time using an NXP Development Board, by way of the FRDM-KW41Z kit. I am not one for printing out loads of documents just to read up on a product and rely almost exclusively on online material, which I read directly on the screen.
So for me the nxp.com website was a breath of fresh air. I found it very well designed and the content provided when doing keyword searches was excellent.
The above is the results page when searching for “PN7150”. I found a handy trick by clicking on a button “See all search results” right at the bottom of the page. This then segments all the information available into different tabs, making it very easy to navigate.
Also found within the website are various video tutorials. I found these useful when trying to get up to speed with the MCUXpresso IDE. What was disappointing though is that most of these training videos are not available on YouTube, which I personally prefer (as you can speed the videos up, for example).
Another “go-to” site for me was the NXP community website.
I found out through my information searching that this is way more than a simple user Q&A forum. There is a wealth of information available and you will come across some PN7150 tutorials here too – although at the time these were limited to a couple of boards, such as the FRDM-K64F board (this has the RTOS example) and the LPC board (has the BM example).
Having waded through loads of documents and web pages, I then went the full circle and I watched the element14 webinar recording, which can be found here:
There is very handy explanation on the NXP NFC library and important functions linked to the NXP_NCI API. This is 2/3rds into the webinar (from 24 minutes). This information can also be found in the section 6 of document AN11990.
For the hardware review, I will look at the three elements that make up the PN7150 SBC Kit for Arduino (R3 compatible boards):
The NFC Controller chip I am more familiar with is NXP’s PN532 transceiver module. This module has been widely available as a development add-on board for a number of years now, partly thanks to its more visible adoption within the open-source hardware community. No doubt it was adopted commercially too as I found it rather good.
However, according to the NXP website, the PN532 is not recommended for new designs and they recommend PN7120 or PN7150 as a replacement.
So, let’s look at how these modules compare:
Now, what I cannot figure out is why all the marketing brochures for the PN7150 say its max operating voltage is 4.75V and not 5.5V as per the product data sheet. Surely they must realise that it is these sorts of things that are a real headache for systems integrators and developers as it creates uncertainty and risk that things will not operate as specified. So are they hiding something, I wonder.
Looking at the footprint and electric characteristics we can see that the PN532 could be replaced with the PN7150. The nice thing is that PN7150 offers a lower polling current (150 micro Amps) compared to the PN532 (25 milli Amps) and offers more capability in terms of what can be handled during the three operating modes.
What is not clear in the PN7150 data sheet is the amount of memory that is allocated to any RX/TX RAM buffers (if there are any). For me this becomes an issue if transmitting large data files using NFC P2P mode for example. At least the amount of RAM/ROM is documented for the PN532. Anyhow, I never evaluated this use case during the road test.
Then I see that the PN7150 offers "Active Load Modulation", which is explained as a footnote below the diagram. To be honest, I could not tell the difference when testing, as the antenna on my PN532 breakout board was larger than this kit's antenna and also appeared to be more sensitive.
When looking at the pinouts, you will notice there is very little else in common. The PN7150 is very much a subset of what the PN532 offers as IO’s. For example there is no SPI or HSU and there are no GPIO’s broken out either (PN532 has 4).
On the plus side, the PN7150 is significantly cheaper than the PN532.
The controller board is a self-contained board, which includes the PN7150 module, a tuned antenna and connectors for the interface board.
In fact, you could almost classify the OM5578 controller board as a breakout board; although it appears that you cannot purchase this controller board directly. A real pity as so much could be done with this board directly and it would open up possibilities for the user to design their own customised interface boards. All they would have to do is not solder in those pin headers and leave it up to the user to decide on what they want to use.
I just happened to have a PN532 breakout board from Adafruit.
As can be seen by this picture the OM5578 is significantly smaller than my Adafruit PN532 Breakout board. If you watch the demo video below you will notice that the Adafruit antenna was more sensitive in picking up cards at distance. So beside this size difference it is difficult to determine how antennae perform without proper instrumentation. So at face value, I’m willing to believe NXP’s claim that antenna performance is enhanced with PN7150’s active load modulation.
Unlike the interface boards for Raspberry Pi and Beaglebone, the design of this interface board is the real weak link in the Arduino based SBC kit, in my opinion. I was certainly caught out by my assumptions and expectations of how this Arduino interface board would work. It is a pity that they never adopted the design tricks of others.
For example, there is no need to solder in the header pins as you have no limited the height of the interface board and the controller. Certainly provide the headers pins with the kit as most users would use them but there are cases where you would want to use you longer pin headers.
Then it is my firm view that the purpose of an interface board is to cater for a range of Microcontroller host options. Hence it needs to make allowances for this and so, at the very least, should include traces and footprints (suggest 0804s) for pull-up resistors on the SDA and SCL lines. You have to make allowances for the fact that test application may have other devices using the I2C bus too and so it may not be beneficial or possible to rely on the internal pull-ups of the host controller. This was rather short-sighted in my opinion considering it has minimal cost implication on the fabrication of the interface board.
It would have been helpful if options were provided to allow the user to select which pins to use for VEN and IRQ pins, especially as no other IO’s have been broken out from the PN7150 module – it did seem curious as to why traces were included on the interface board which were not used. For example, there are many Arduino shields available on the market that have successfully provided the user with pin selection options to handle a UART interface via a software serial connection. At the very least, if you want to have the least risk option for pin clashes then, in my opinion, the IRQ pin should have been assigned to PTC19 on the FRDM-KW41Z board which is D2 on an Arduino as this would more commonly be assigned as in input pin which can also be used for interrupt handling.
Then for this road test we had an incompatibility issue with the pins assigned for VEN (voltage enable) and the IRQ (Interrupt) GPIO’s and the version we had of the FRDM-KW41Z board.
This meant I had to hack the interface board to get it to work.
This then highlighted another significant weakness of the design, as there was now a small risk that I could have damaged the PN7150 module. There were no simple visual indicators, such LED’s, or designated test points which you could use to validate that your controller board is in fact still working. There was absolutely no way to quickly and simply determine if you were having a software issue or a hardware problem. This caused significant delay when trying to develop an application using an unfamiliar module.
This resulted in me fashioning my own breakout board just to get started - I eventually returned to the interface board once I knew the controller board was working:
This was my first time using MCUXpresso as well as the first time to use a FRDM-KW41Z board... as well as a PN7150. What a combo!
Well I found that this combo is a bit like driving a high performance rally car in mud. You have complete access to everything that controls the car but that still does not help when you head (i.e. communicating) at high speed down a hill knowing that you’re actually not fully in control of what the car’s doing at any given second, but once you overcome your fear and trust what’s under the hood you absolutely love the experience... even if it means you occasionally end up in a ditch and need rescuing.
My initial expectation with this “Arduino” kit was that there would be a range of suitable software available for download, from say a repository like Github, which would readily work on a select number of microcontrollers in order for you to test that firstly your PN7150 NFC Controller SBC Kit is working and secondly to showcase the use of the NTAG216 card, which comes with the kit, by reading data from it and/or writing data to it.
Unfortunately, that is not quite the case here – yes the demo software does read and write to the card but this software is only available for a couple of LPC boards and a K64F board and the NFC library is part of a complete project archive for each board. Then when you find that the AN11990 documentation is not complete it makes it difficult to work everything out quickly.
Within the NXP-NCI MCUXpresso example (AN11990) document, it informs the user that there are two primary code examples available, which are delivered in the form of MCUXpresso projects running on NXP’s LPC82x, LPC11Uxx and LPC11U6x microcontrollers from the LPC family or on the K64 microcontroller from the Kinetis K family.
The document furthers explains that the K64 related project (based on SDK2.2) shows code example integrated under RTOS (freeRTOS) while the LPC ones run without OS support (BM or Bare Metal). It assumes that you are aware that SDK’s for the LPC boards are already included with MCUXpresso.
The AN11990 document further assumes that you know what to do to set up other suitable microcontroller SDKs. I did not find this to be an issue because there is plenty of training material about and I found this website to be superb and it was very easy to navigate and download what I needed. It just takes time, as there is a fair bit to learn.
Now, for anyone, like me, who has no experience of MCUXpresso you will have a lot of ground to cover before things start to make sense and if you are like me and have yet to have a good user experience with Eclipse IDE (it is my least favourite) this is a daunting task indeed.
Well, on a positive note, MCUXpresso has won me over. The whole user experience is one of speed. Maybe it is just me, but I thought that the code compile times are truly impressive. The only thing I still need to get to grips with is screen perspectives because every now and then I do something to my screen layout and I can never readily revert back to default. Anyhow I find this to be a very minor issue and is related to Eclipse and not MCUXpresso.
The manner in which you select your Development Board, configure the settings, download this information to your computer and then upload into MCUXpresso is brilliant. It is very well thought out and it worked seamlessly for me.
In the middle of Section 3 (SW setup) of the document is the key message of how to get the required software file... namely you retrieve from https://www.nxp.com/doc/SW4325
Clicking on this link will redirect to the NXP website where you will be required to register your details and log in to be able to download this file.
The document then explains how to import this file into the IDE.
From then on, if you do not have a FRDM-K64F board you are left to figure out the rest on your own. Now as mentioned before in my write up, section 5.3 (Porting recommendation for other MCUs) of this document does help even if a little misleading as the others software modules inside the library were not quite so platform agnostic as I would’ve assumed.
The compressed SW4325 software file contains a ReadMe, a Software Licensing Agreement and another compressed folder “NXP-NCI_MCUXpressoExample_V1.3”. You will need to extract out these files from the zip file first, because if you look carefully at Figure 6 you will see that it is the NXP-NCI_MCUXpressoExample_V1.3 zip file that you will need to import into MCUXpresso.
Now, one thing I did notice, which is different to any other example I downloaded within MCUXpresso, is that none of those project folders contain a “doc” folder with a readme file. I have only just discovered, through writing my road test report, that you need to read that readme file in main archive as it contains all the relevant info... and to make it easier for the reader here is an image of it:
It is worth noting that according to this readme.txt file, these code examples only handle up to NFC Forum Type 4 tags and do not handle NFC Forum Type 5 tags, https://nfc-forum.org/tag/type-5/, which is supposed to be compatible with the PN7150 module.
Well, thank goodness for a standardised project structure.
This at least provides assurance early on as to which folders and files are custom and which are custom to the project. Unfortunately that is where standardisation ends because when you get into the nitty-gritty of code modification you will quickly pick up on many little details that are not properly documented. For me these project examples indicate that the code was written and tested by an accomplished individual who works with speed rather than aiming for style perfection. This makes it more difficult for someone to amend this code for another microcontroller and if you are like me learning the ropes with MCUXpresso it is significantly more challenging and time consuming.
In my case, I decided to port across the non-OS (bare metal) code version to the FRDM-KW41Z board. This meant a rewrite of the TML (Transport Mapping Layer) as the FRDM-KW41Z has a different I2C library compared to the LPC boards. I then compared the LPC NfcLibrary and nested subfolders against the K64F board and found that they could be copied across as is. After that, I too then gave up on code perfection and hacked it all together to get it working.
So, despite the documentation gaps, I would recommend you study sections 5 and 6 of the AN11990 document, as it actually does help but do not assume that this provides a thorough explanation of everything – I learnt the hard way by not paying enough attention to these sections and lost time in the process.
Following the success with the code port to the FRDM-KW41Z board I decided to port my code adaption across to Cypress PSoC Creator and recreate the bare metal project on a PSoC 6 BLE Pioneer Board. With the bare metal option, I also wanted to observe if similar operational quirks would arise.
As I sure many of you know, PSoC 6 is dual core and has both an M0+ and an M4 ARM Cortex core. I also knew that I had the option of porting the K64F RTOS code across, should I have hit problems, although I also knew that this would have meant more work on the PSoC 6 side for me, simply because I did not have a ready made RTOS program that would be quick and easy to adapt. So I have left it at that.
Here is the second video demo.
(was having problems uploading, so if video not working here is the link to youtube: https://www.youtube.com/watch?v=8OnTe-T0rlA)
As per usual, when creating videos I get video-triggered gremlins - I've discovered they are quite common. As such you will notice a problem with my phone not being detected. Thus I have also attached a graphic to show that the phone P2P mode actually does work, but I remain none the wiser as to the original problem. I did observe that it requires a reboot to get it working again. So, I'll leave it at that for now.
Following this road test I am happy to conclude that the following features are indeed noteworthy:
And some things I am still not sure about:
Top Comments
Thanks. Yes indeed that was harder than expected. One good thing that came out of the experience though was getting to know the MCUXpresso IDE. I really like it now. In fact, I might even be ready to jump…
I discovered the error in the library and created a code fix!
/* Wait for card removal */ NxpNci_ProcessReaderMode(RfIntf, PRESENCE_CHECK); printf("CARD REMOVED\r\n"); /* Restart discovery…