Actions
Forum Thread Details
  • Replies 9 replies
  • Subscribers 9 subscribers
  • Views 1501 views
  • Users 0 members are here
Related

PN512 problems (explore-nfc-ww -kit)

Former Member

Hi all.

 

 

I'm totally noob what comes to NFC. I'm trying to get the element14 PN512 board to work in my embedded project. I'm using the this SW library as base:

NFC Reader Library V04.030.00 R1 for PNEV512B including all software examples

 

I'm using MifareReaderC example with I2C and so I'm not using the serial setup from the code. I can communicate OK with the chip.

 

Problems:

1. However the timer implementation doesn't seem to start the timer. I added write to control register (address 0x0c) with param 0x50 (trigger now + initiator) after each timer conf. This puts the timer running and i can get the interrupt to be visible in the register. However shouldn't the original setup do this out-of-box? What I'm missing here?

2. The type 2 tag card that comes with the kit. Can it be read out of box or does it require writing someting to card? The SW is polling it, but cannot detect anything. I'm using the PN512 as initiator.

 

 

The examples are pretty cumbersome (don't really want to say horrible) and code rather old ('04/'06). Is there any simple c library available for PN512? Or any good tutorial how this and NFC should work. I have currently no idea if this is even correct configuration for card reading. I've tried reading all the documents and wiki stuff regarding Mifare/Felica/NFCIP-1 but not really having any big revelations how this whole field should work and what is what.

 

Sorry if that was a lot, but I'm more than little confused. NFC seemed like are that must be like one standard and everything nicely packaged to nicely available open source libraries. Not so much it seems image. Weirdest thing is that why there's so little info of 512 even though NXP claims it's the de-facto standard.

  • Hi maash,

     

    actually it looks like you are using the sources that are prepared to be used on microcontrollers such as LPC1769 and LPC11U68. There are sources prepared for the Raspberry Pi. Please use these to get started.

     

    You can find everything here:

    NFC Reader Library|NXP

     

    The related documentation that describes how to get started on Raspberry Pi is

    AN11480 and AN11802

     

    Depending on your needs there are two major software packages.

     

    Neard EXPLORE–NFC — Using NeardAL with EXPLORE–NFC

    This package follows the approach from Linux-NFC [1] which integrates the PN512 using the NFC Reader Library.

     

    NFC Reader Library for Linux

    This package brings the complete NFC Reader Library directly to Linux. Including all its examples. This is basically what you have been using, but ported to Linux. Tested on Raspberry Pi (1, 2, 3) running Raspbian system image. With this package you can make use of the NFC Reader Library API. Furthermore it supports the NFC reader ICs PN512, CLRC663 and PN5180.

     

    Both packages can directly read and write the T2T included in the EXPLORE-NFC package.

     

    HTH,

    Michael

     

    [1] https://01.org/linux-nfc

  • in reply to michaelneurohr

    Thanks Michael.

     

     

    Actually I'm not using RPi for this. I've got single thread embedded system that this is supposed to be used with. So it's custom system and connected via I2C, and I need to setup this so that it gets interrupt when tag is detected. The base setup (active/passive, what is the mode for this type 2 Tag, etc) is still quite vague to me.

     

    Main issue currently (I've used the old NXP BFL c-library as base) is that I cannot turn on the reader HF on. I cannot detect any 13mhz field with scope so the polling loop cannot detect any cards. Read and write seems to be working ok.

  • in reply to Former Member

    Actually the BFL is some quite old library which is not maintained anymore.

     

    If you want to use the PN512 to trigger an interrupt once it has a NFC tag detected, that will not work. The PN512 can be seen as a big state machine. All the protocol handling need to be done from the microcontroller that is operating the PN512. Thus the PN512 cannot work in an autonomous way so that it reports in case a tag is detected. You have to run the detection routine from the MCU.

     

    Maybe you can describe your use case in more detail so that I can provide some more specific input.

     

    Michael

  • in reply to michaelneurohr

    I don't really know how much more there's left to tell.

     

    Idea is that our system sleeps until it gets read interrupt from the reader. We only need to get ID of the tag/card/whatever (it doesn't have to be this this card type).

     

    I was under impression that PN512 can be in passive mode and wake up from external trigger. What is the separate interrupt line there for?

  • in reply to Former Member

    OK, now I fully got your use case.

     

    "Passive mode" in NFC is a specific P2P mode. One device is in Passive Initiator mode, the counterpart is in Passive Target mode. Where the Passive Initiator generates the for the communication required NFC carrier field all the time, where the Passive target never generates an NFC field at any time, while in this mode. So the "Passive mode" does not help at all in your case.

     

    The interrupt line is used for many different things. Timers of the reader IC, transmission errors, CRC interrupts and more.

     

    To fulfil your use case there are two options I'd suggest.

     

    1. The CLRC663 has a so called LPCD (Low Power Card Detection) mode. Basically LPCD is able to detect detuning of the antenna. This can happen either if a NFC tag is in the field, or any other metallic object. In case of a detuning, the CLRC663 triggers an interrupt and wakes up the host MCU. But this does not necessarily mean that there is an NFC tag in the field. So after the wakeup of the MCU, you have to try in software, if the disturber is the NFC tag you are looking for. if yes, you can run your application. If not, you can simply go back to sleep.
    2. The second option would be to use the PN7462AU or its derivatives. The PN7462 is a NFC Controller where you can modify the firmware. With this NFC IC you could develop your customized routine into the PN7462 itself. That would enable you to trigger on a very specific NFC tag so that the PN7462 throws an interrupt only once the specified tag is detected.
  • in reply to michaelneurohr

    Ok, thanks for the info.

     

    I got the PN512 now to read the card. However the usefulness of this excersise is pretty low now image.

     

    What about the 125khz or other low hz RFID:s? Do they support this sort of passive scheme? I mean we really need only to read ID from the tag, not to write anything there or read larger payloads. In that sense the whole NFC card is pretty overkill. The low power consumption and external read triggering are the main things that interest me.

  • in reply to Former Member

    To be honest, I'm not absolutely sure. But independent of the technology you'll always have to do some business logic on your own.

     

    There are also tags with just 48 Bytes of user memory available. I think the solution I described with the PN7462 would match your use case pretty good. Actually I'd suggest the derivative PN7360, which should be a bit cheaper. With this one you should get all you need.

    Are you planning to design your own hardware?

  • in reply to michaelneurohr

    I don't mind writing drivers, it's quite fun if documentation is OK. Problem is that I don't quite understand the NFC area and different protocols. I think I'll have to look more into that area.

     

    Dunno about the HW. This is just tinkering at this point image.

  • in reply to Former Member

    There are already complete examples for these basic use cases.

     

    Are you planning to build a lot of devices, or just a few. Let's say less than 10? In that case you could go with the CLRC663 demo board and connect it directly to your device. As software stack you can use the NFC Reader Library that I already linked earlier today. When using that setup, you'd only have to connect the demo board, port the software stack and you are good to go.