Topic: Add support for pn532 chip

Hi, I'm trying to add support for pn532 chip to libnfc but I have some issues with the serial port communication.

I've added dev_pn532.h and dev_pn532.c to the source tree.

This is my current work-in-progress code (linux-based):

#include "defines.h"

#include <stdio.h>
#include <string.h>
#include "dev_pn532.h"
#include "rs232.h"
#include "bitutils.h"

#define BUFFER_LENGTH 256
static char buffer[BUFFER_LENGTH] = { 0x00, 0x00, 0xff }; // Every packet must start with "00 00 ff"

typedef struct {
  serial_port sp;
} dev_spec_pn532;                                                                  

dev_info* dev_pn532_connect(const uint32_t uiIndex)
{
  dev_info* pdi = INVALID_DEVICE_INFO;
  dev_spec_pn532* pdsp;
  dev_spec_pn532 dsp;
  uint32_t uiDevIndex;

  // Initialize the device index we are seaching for
  uiDevIndex = uiIndex;

  // Open the PN532 device
  serial_port sp = rs232_open("/dev/ttyUSB0");
  if (!sp)
  {
    #ifdef DEBUG
      printf("Invalid serial port name\n");
    #endif
    return INVALID_DEVICE_INFO;
  }

  dsp.sp = sp;
  #ifdef DEBUG
    printf("Found PN532 device\n");
  #endif

  // Allocate memory for the device info and specification, fill it and return the info
  pdsp = malloc(sizeof(dev_spec_pn532));
  *pdsp = dsp;
  pdi = malloc(sizeof(dev_info));
  strcpy(pdi->acName,"PN532");
  pdi->ct = CT_PN532;
  pdi->ds = (dev_spec)pdsp;
  pdi->bActive = true;
  pdi->bCrc = true;
  pdi->bPar = true;
  pdi->ui8TxBits = 0;
  return pdi;
}                                                                                          

void dev_pn532_disconnect(dev_info* pdi)
{
  dev_spec_pn532* pdsp = (dev_spec_pn532*)pdi->ds;
  rs232_close(pdsp->sp);
  free(pdi->ds);
  free(pdi);
}                                        

bool dev_pn532_transceive(const dev_spec ds, const byte_t* pbtTx, const uint32_t uiTxLen, byte_t* pbtRx, uint32_t* puiRxLen)
{                                                                          
    uint32_t uiPos = 0;                                                             
    int ret = 0;                                                           
    char buf[BUFFER_LENGTH];
    dev_spec_pn532* pdsp = (dev_spec_pn532*)ds;

    // Packet length = data length (len) + checksum (1) + end of stream marker (1)
    buffer[3] = uiTxLen;                                                                
    // Packet length checksum 
    buffer[4] = BUFFER_LENGTH - buffer[3];                                                  
    // Copy the PN53X command into the packet buffer
    memmove(buffer+5,pbtTx,uiTxLen);

    // Calculate data payload checksum
    buffer[uiTxLen+5] = 0;                   
    for(uiPos=0; uiPos < uiTxLen; uiPos++) 
    {
      buffer[uiTxLen+5] -= buffer[uiPos+5];
    }

    // End of stream marker
    buffer[uiTxLen+6] = 0;        

    #ifdef DEBUG
      printf("Tx: ");
      print_hex((byte_t*)buffer,uiTxLen+7);
    #endif

    ret = rs232_send(pdsp->sp, buffer, uiTxLen+7);
    if (!ret)
    {
      #ifdef DEBUG
        printf("rs232_send failed\n");
      #endif
      return false;
    }

    ret = rs232_receive(pdsp->sp, buf, puiRxLen);
    if (!ret)
    {
      #ifdef DEBUG
        printf( "rs232_receive failed\n");
      #endif
      return false;
    }

    #ifdef DEBUG
      printf("Rx: ");
      print_hex((byte_t*)buf,puiRxLen);
    #endif

    // When the answer should be ignored, just return a succesful result    
    if(pbtRx == NULL || puiRxLen == NULL) return true;

    // Only succeed when the result is at least 00 00 FF xx Fx Dx xx .. .. .. xx 00 (x = variable)
    if(ret < 9) return false;

    memcpy( pbtRx, buf + 7, *puiRxLen);

    return true;
}

I've connected a NXP demo board to my computer (at /dev/ttyUSB0). When I launch the nfc-list program with debug information, the result is:

Found PN532 device
Tx: 00  00  ff  04  fc  d4  06  00  00  26  00  
rs232_receive failed
Tx: 00  00  ff  02  fe  d4  02  2a  00  
rs232_receive failed
Error connecting NFC reader

Please, help me smile

PS: the serial port works in "loop-back mode" and the NXP demo board works too with its Windows SDK.

Last edited by zuck (2009-08-14 10:49:31)

Re: Add support for pn532 chip

Hi,
it seems you are using a USB<->serial converter to connect to the demo board. Sometimes, problems with RS232 reading timeouts can happen in such a setup. I would try to increase the timeout (orig. set to 30 ms in rs232.c) to even 1 second to see if this is the case. If so, I would then try to find the acceptable timeout level.

Btw., where can one buy the development kit with PN532? I tried to contact NXP few months ago and realized they are definitely not willing to sell their kits to common people like me :-)

Tom

Re: Add support for pn532 chip

You can find it on Digikey (www.digikey.com) smile

For my problem: my code is very similar to ARYGON one, which uses the PN532 chip too. However it doesn't work.

I'm using an USB-serial converter but if I increment the timeout value to 1s there is no changes sad

In my opinion the issue is in the VBAT mode function of PN532: probably the chip is in "stanby" mode when I connect it to my PC and I need to wakeup it as first action.

Re: Add support for pn532 chip

zuck wrote:

In my opinion the issue is in the VBAT mode function of PN532: probably the chip is in "stanby" mode when I connect it to my PC and I need to wakeup it as first action.

How about to sniff the communication in between the development kit and its demo applications to see what it is going on during the startup? On the USB under WinXP (if I understand it correctly, those demos run on this platform), you can try a free evaluation copy of sourceUSB (www.sourcequest.com, section DOWNLOADS). Basing on my own experience, the “free” version is quite reliable and powerful. You do not even need any deep USB knowledge. Just run the sniffer, select the device, start capturing, and run the application being captured. Then simply browse through IN/OUT transactions and look for their data. As I have said, it is all very intuitive…

On the other hand, NXP promises to include a full documentation into their DKs. This is the reason why I wanted to buy it (as the chip itself can be bought for much less than $550 smile). Please correct me if I am wrong, but they obviously did not give you a *full* documentation, since finding a solution to your problem should be much easier then… smile

Tom

Re: Add support for pn532 chip

After a long debug session, we've discovered some issues in our current code (based on arygon one) and test environment:

1) The Serial-USB converter introduces some buffer problems, as tom314 said.

2) We need to force the serial port speed at 115200 b/s:

# rs232.c

// Copy the old terminal info struct
sp->tiNew = sp->tiOld;
sp->tiNew.c_cflag = B115200 | CS8 | CLOCAL | CREAD;
sp->tiNew.c_iflag = CCLAIMED | IGNPAR | IGNBRK;
sp->tiNew.c_oflag = 0;
sp->tiNew.c_lflag = 0;
sp->tiNew.c_cc[VMIN] = 0;      // block untill n bytes are received
sp->tiNew.c_cc[VTIME] = 0;     // block untill a timer expires (n * 100 mSec.)
 
// Clear the IO queues.
tcflush(sp->fd, TCIOFLUSH);

3) The r232 read function code seems to not working as expected. We've replaced it with a new version which reads exactly the number of bytes in the buffer:

# rs232.c

bool rs232_receive(const serial_port sp, byte_t* pbtRx, uint32_t* puiRxLen)
{
  int iResult;
  int byteCount;
  fd_set rfds;

  // Reset file descriptor
  FD_ZERO(&rfds);
  FD_SET(((serial_port_unix*)sp)->fd,&rfds);
  iResult = select(((serial_port_unix*)sp)->fd+1, &rfds, NULL, NULL, &tv);

  // Read error
  if (iResult < 0) return false;

  // Number of bytes in the input buffer
  ioctl(((serial_port_unix*)sp)->fd, FIONREAD, &byteCount);
#ifdef DEBUG
  printf("Rx buffer size: %d\n", byteCount);
  fflush(stdout);
#endif

  // Read time-out or empty buffer
  if (iResult == 0 || byteCount == 0) return false;

  // There is something available, read the data
  *puiRxLen = read(((serial_port_unix*)sp)->fd,pbtRx,byteCount);

  return (*puiRxLen > 0);
}

4) We need a minimum time delay (~30ms) beetween two "send command" calls.

# dev_pn532.c

bool dev_pn532_transceive(const dev_spec ds, const byte_t* pbtTx, const uint32_t uiTxLen, byte_t* pbtRx, uint32_t* puiRxLen)
{
  // Wakeup the pn532C106 chip.
  if (!dev_pn532_wakeup(ds))
      return false;

  // Wait for a time > 200 us (30ms).
  usleep(30000);

  // Command packet.
  byte_t abtRxBuf[BUFFER_LENGTH];
  uint32_t uiRxBufLen = BUFFER_LENGTH;
  uint32_t uiPos;
    
  // Packet length = data length (len) + checksum (1) + end of stream marker (1)
  abtTxBuf[PREAMBLE_LENGTH] = uiTxLen;                                                                
  // Packet length checksum 
  abtTxBuf[PREAMBLE_LENGTH+1] = BUFFER_LENGTH - abtTxBuf[PREAMBLE_LENGTH];                                                  
  // Copy the PN53X command into the packet buffer
  memmove(abtTxBuf+PREAMBLE_LENGTH+2,pbtTx,uiTxLen);
  
  // Calculate data payload checksum
  abtTxBuf[uiTxLen+PREAMBLE_LENGTH+2] = 0;                   
  for(uiPos=0; uiPos < uiTxLen; uiPos++) 
  {
    abtTxBuf[uiTxLen+PREAMBLE_LENGTH+2] -= abtTxBuf[uiPos+PREAMBLE_LENGTH+2];
  }
  
  // End of stream marker
  abtTxBuf[uiTxLen+PREAMBLE_LENGTH+3] = 0;
  
  byte_t ack[BUFFER_LENGTH];
  uint32_t ackLen = 0;

  // Send the command packet.
#ifdef DEBUG
  printf("Tx (%d): ", uiTxLen+PREAMBLE_LENGTH+4);
  print_hex(abtTxBuf,uiTxLen+PREAMBLE_LENGTH+4);
  fflush(stdout);
#endif
  if (!rs232_send((serial_port)ds,abtTxBuf,uiTxLen+PREAMBLE_LENGTH+4))
    return false;
    
  // Wait for an ACK + response frame.
  if (!rs232_receive((serial_port)ds,abtRxBuf,&uiRxBufLen))
    return false;
#ifdef DEBUG
  printf("Rx (%d): ", uiRxBufLen);
  print_hex(abtRxBuf,uiRxBufLen);
  fflush(stdout);
#endif
  
  // When the answer should be ignored, just return a succesful result    
  if(pbtRx == NULL || puiRxLen == NULL) return true;

  // Only succeed when the result is at least 00 00 ff 00 ff 00 00 00 FF xx Fx Dx xx .. .. .. xx 00 (x = variable)
  if(uiRxBufLen < 15) return false;
  
  // Remove the preceding and appending bytes 00 00 ff 00 ff 00 00 00 FF xx Fx .. .. .. xx 00 (x = variable)
  *puiRxLen = uiRxBufLen - 15;
  memcpy(pbtRx, abtRxBuf+13, *puiRxLen);
  
#ifdef DEBUG
  printf("Final Rx (%d): ", *puiRxLen);
  print_hex(pbtRx,*puiRxLen);
  fflush(stdout);
#endif
  
  return true;
}

This is the last execution output:

Found a PN532 device connected to /dev/ttyUSB0
Tx (15): 55  55  00  00  00  00  00  ff  03  fd  d4  14  01  17  00  
Tx (19): 55  55  00  00  00  00  00  00  00  00  ff  04  fc  d4  06  00  00  26  00  
Rx buffer size: 15
Rx (15): 00  00  ff  00  ff  00  00  00  ff  02  fe  d5  15  16  00  
Tx (17): 55  55  00  00  00  00  00  00  00  00  ff  02  fe  d4  02  2a  00  
Rx buffer size: 16
Rx (16): 00  00  ff  00  ff  00  00  00  ff  03  fd  d5  07  00  24  00  
Final Rx (1): 00  
Tx (19): 55  55  00  00  00  00  00  00  00  00  ff  04  fc  d4  06  63  3d  86  00  
Rx buffer size: 19
Rx (19): 00  00  ff  00  ff  00  00  00  ff  06  fa  d5  03  32  01  06  07  e8  00  
Final Rx (4): 32  01  06  07  

The program has unexpectedly finished.

The program crashes in libnfc.c at line 127 sad:

bool pn53x_set_reg(const dev_info* pdi, uint16_t ui16Reg, uint8_t ui8SybmolMask, uint8_t ui8Value)
{
  pncmd_set_register[2] = ui16Reg >> 8;
  pncmd_set_register[3] = ui16Reg & 0xff;
  pncmd_set_register[4] = ui8Value | (pn53x_get_reg(pdi,ui16Reg) & (~ui8SybmolMask));    <<===========
  return pdi->pdc->transceive(pdi->ds,pncmd_set_register,5,NULL,NULL);
}

Last edited by zuck (2009-08-25 11:54:13)

Re: Add support for pn532 chip

Hi zuck,

I actually try to make more ARYGON devices works with libnfc.
Using APDB1UA33N, which is a "simple" pn532 on a ARYGON PCB, i'm able to read MIFARE tag since r88.

A little experience feedback:

zuck wrote:

1) The Serial-USB converter introduces some buffer problems, as tom314 said.

I use an FT232R USB UART under linux and it seems I haven't any buffer problem.

zuck wrote:

2) We need to force the serial port speed at 115200 b/s:

You're right according to datasheet, that's the default speed for PN532 device.

zuck wrote:

3) The r232 read function code seems to not working as expected.
We've replaced it with a new version which reads exactly the number of bytes in the buffer.

Can you create an issue related to this and add a patch against latest SVN revision, please ?

zuck wrote:

4) We need a minimum time delay (~30ms) beetween two "send command" calls.

Yeah! I had to do this too. But even communication works with a 20ms delay, tag detection doesn't work without a 40ms delay (experienced value... no information from datasheets).
You can see these delays in: http://code.google.com/p/libnfc/source/ … v_arygon.c

With these modifications, I was able to communicate with APDB1UA33N but not with APDB2UA33 which comes with an additionnal µC that is not used by libnfc. libnfc directly use PN532 using TAMA language.
BTW, I had some similar output with this device and nfc-list segfault at the same place, have a look at http://code.google.com/p/libnfc/issues/detail?id=4

Roel, any idea ?

Romuald Conty

Re: Add support for pn532 chip

rconty wrote:

I use an FT232R USB UART under linux and it seems I haven't any buffer problem.

Yes, we changed our converter and no problems appear anymore.

rconty wrote:

Can you create an issue related to this and add a patch against latest SVN revision, please ?

http://code.google.com/p/libnfc/issues/detail?id=17

rconty wrote:

Yeah! I had to do this too. But even communication works with a 20ms delay, tag detection doesn't work without a 40ms delay (experienced value... no information from datasheets).
You can see these delays in: http://code.google.com/p/libnfc/source/ … v_arygon.c

Yes, you're right! With a 40ms delay the receive process is more stable!

rconty wrote:

With these modifications, I was able to communicate with APDB1UA33N but not with APDB2UA33 which comes with an additionnal µC that is not used by libnfc. libnfc directly use PN532 using TAMA language.
BTW, I had some similar output with this device and nfc-list segfault at the same place, have a look at http://code.google.com/p/libnfc/issues/detail?id=4

With the rs232 receive function patch, I can communicate with my pn532 chip and read all supported tags.

For the C106 revision of the chip, I need to wakeup it as first action with a specific command. Unfortunately, I'm under NDA, so I need to request the NXP authorization before post the complete code.

Re: Add support for pn532 chip

zuck wrote:

With the rs232 receive function patch, I can communicate with my pn532 chip and read all supported tags.

Sounds good ! Your patch have been applied in svn r96. You can now use upstream version.

zuck wrote:

For the C106 revision of the chip, I need to wakeup it as first action with a specific command. Unfortunately, I'm under NDA, so I need to request the NXP authorization before post the complete code.

NDA and (L)GPL, that's a long debat... But if you distribute your code which is under LGPL, even to one customer, you must send your modification according to LGPL. But NDA doesn't allow you to share information found in NDA-covered document. So, a simple solution is to write down your code without any comment that explain something covered by NDA.
You can have a look to http://gcc.gnu.org/ml/gcc/2001-07/msg01363.html or http://lists.gpl-violations.org/piperma … 00487.html to know more about this not-easy-state.

BTW, Thanks !

Romuald Conty

Re: Add support for pn532 chip

Authorization request sent, now I'm waiting for the NXP response wink

BTW, now my pn532 code and arygon one seem to be completely equivalent if the chip is already awake.

Re: Add support for pn532 chip

zuck wrote:

Authorization request sent, now I'm waiting for the NXP response wink

Great. Hope NXP allow you to share information about that. Where have you requested this autorisation ? Do you have some contact there or just using web form ?

zuck wrote:

BTW, now my pn532 code and arygon one seem to be completely equivalent if the chip is already awake.

Developing nfc-eventd (http://code.google.com/p/nfc-tools), I have had some issues with my ARYGON reader : 20ms + 20ms delay is not enought... I had to raise delay to 50ms (svn rev105), which make this chip slower than touchatag hmm (experienced, not mesured).
BTW, in ARYGON datasheet I haven't seen any timing diagrams and I had requested an access to PN53x datasheets from NXP but it is pending. Have some information about this delay in PN532 datasheet ? I don't really care about "why" this delay, but just want to know if 50ms will be "always" OK...

Thank you.

Romuald Conty

Re: Add support for pn532 chip

Hi all,
do you have any ideas to support for pn532 chip via i2c interface ? (on linux)

Re: Add support for pn532 chip

Hello,

tungsys wrote:

do you have any ideas to support for pn532 chip via i2c interface ? (on linux)

AFAIK, nobody in libnfc core-team works on this feature but contributions are welcomed.

Romuald Conty

Re: Add support for pn532 chip

To tungsys:

I'm working on the SPI interface code of PN532 on a S3C2410 board now.

The code is already ready in last Wednesday, but the hardware is still in debug now, I'm not sure when the hardware will be confirmed to work.

Tom and Roel has talked with the president of my client last weekend (the president is on business trip in Germany today, I don't know if Tom or Roel will meet with him face to face in this week for a better communication), they are talking about the cooperation between my client and libnfc community for some more open source devices as planed, and about wether to donate my code to libnfc.

I agree with rconty's last post about restructure existing code to make the code more modular, Protocol layer (register setttings, TAMA commands, etc) -> bus layer (I2C/UART/SPI/USB) will be the core code, and the current device code will be put into a board layer that just call the core code with different parameters of different boards but with the same chipset or bus, this way, chipset, bus interface to communicate, and board using the chipset are totally decoupled, this is a clear and modular structure that we can add even other NFC chipsets later, and other bus communication protocols later in core, and add as many boards as possible if you like.

And specific to I2C now, there's already a rather good I2C interface in Linux kernel, and we can easily write a general OS independent I2C interface header with the abstraction of I2C bus protocols very clearly seen by this API, and the implementation of this internal I2C API will be different on each OS platform supported.

My current SPI code is written in this style, spi_open(), spi_close(), spi_configure(), spi_transfer(), spi_read_pn532_status(), spi_read_pn532_fifo(), spi_write_pn532_fifo(), are the API, so simple just 6 functions, and currently I only implement this API in Linux, and it's hardware architecture and board independent, we need just to implement this API for other OS on demand now.

Last edited by izico (2009-09-28 10:24:50)

Re: Add support for pn532 chip

Hi, rconty,

If you need the PN532 datasheet, I can send to you.

As I know there's no NDA signed with NXP that I can't disclose this to a developer (but not publicly).

My client never warned me about never to divulge this datasheet, so I guess this must be not a issue else they habitually warned me.

Please send me a private letter for the datasheet if needed, anyway, I think there may be some legal issue if I divulge it publicly.

izico

Re: Add support for pn532 chip

Hi izico,

izico wrote:

If you need the PN532 datasheet, I can send to you.

Thanks you a lot, but no I don't need it.

But if you know how to wake up an PN532 v1.6, we could fix this issue : http://code.google.com/p/libnfc/issues/detail?id=15

Romuald Conty

Re: Add support for pn532 chip

Hi, Romuald,

I don't know how to do it, in fact, I even don't know how the embedded firmware is written to execute the commands sent thought the FIFO manager, and how it sends the response through the FIFO manger, I depend on your existing code to do the magic for me.

I found no much document about this, and the NXP HAL SDK has a Tama adaption layer (TAL) that works with embedded firmware like libnfc (It has another JAL, Joiner adaption layer, and they are the 2 low level layer support DAL, Device Abstraction Layer, which is used by the HAL, Hardware Abstraction Layer, Just reading this name make me a little headache, not to say their dual diligence to comply with the standard Win32 API style and my most hated Hungarian naming convention), but NXP employees seem never bother to write a really simple and clear document to explain well everything to new maintainer, (I don't know if this is because they are CMM5 certified), though they love to write a lot \doxygen style comments, (Maybe this is the coding policy of NXP? As I've seen several different coding styles of NXP SDK).

I'm a little lazy and easy going programmer with very narrow interest and ability focused on my current problem in hand only, though I've broad interest to a lot things, but definitely just interested a lot but any expertise in it.

Our hardware engineer is still debugging the PN532 device on our board, I'm working on integrating libfprint on our FS90 fingerprint scanner now, unlike libnfc, I have some issues in it as I can get only a closed SDK from Futronics, biometrics company are generally not friendly to open source, and the fprint team seems to hate closed source biometics company too.

But I think my idea about how to restructure the existing code should be considered in the core team, I think that'll make the code much modular and more intuitive and easier to understand and add new features.

izico

Re: Add support for pn532 chip

Hi Izico, can you pls send me the data sheet of PN532. My personal email is : tungsys@yahoo.com , thank you smile
btw, what is the problem with the hardware ? My hardware also got problem when connect to host via I2C bus....

Hi rconty, this is the flow to wakeup pn532 via UART

// Wake Up seq for v106 - need to set protocol to Raw data
PC -> IFD : UNKNOWN COMMAND
            00 00 FF 10 F0 D4 55 55 00 00 00 00 00 FF 03 FD
            D4 14 01 17 00 83 00
IFD -> PC : ACK
            00 00 FF 00 FF 00
            00 00 FF

PC -> IFD : WRITE GPIO
            00 00 FF 04 FC D4 0E 90 00 8E 00
IFD -> PC : ACK
            00 00 FF 00 FF 00
IFD -> PC : WRITE GPIO EXECUTED
            00 00 FF 02 FE D5 0F 1C 00

PC -> IFD : WRITE GPIO
            00 00 FF 04 FC D4 0E 10 00 0E 00
IFD -> PC : ACK
            00 00 FF 00 FF 00
IFD -> PC : WRITE GPIO EXECUTED
            00 00 FF 02 FE D5 0F 1C 00

PC -> IFD : MASK NUMBER
            00 00 FF 02 FE D4 02 2A 00
IFD -> PC : ACK
            00 00 FF 00 FF 00
IFD -> PC : MASK NUMBER EXECUTED
            00 00 FF 06 FA D5 03 32 01 06 07 E8 00


// 3 - Mifare UltraLight @ 106bps
//     --------------------------
PC -> IFD : INITIATOR : LIST PASSIVE TARGETS
            00 00 FF 04 FC D4 4A 01 00 E1 00
IFD -> PC : ACK
            00 00 FF 00 FF 00
IFD -> PC : INITIATOR : LIST PASSIVE TARGETS EXECUTED
            00 00 FF 0F F1 D5 4B 01 01 00 44 00 07 04 45 63
            00 00 00 00 E7 00

Re: Add support for pn532 chip

Hi, tungsys,

As I'm a consultant that's get paid by time spent on a project, so my client will let me rest when they are sure it's hardware but software problem.

My hardware fellow colleague just says that the hardware has problem, nothing more, this will both save my time and the cost of his boss, in his kind view, I guess.

Datasheet sent.

How do you know the commands? Can you give me some definite resource how the embedded firmware works? I know C51 assembly and C coding a little, though I don't use it extensively now in favor of ARM.

izico

Re: Add support for pn532 chip

Hi izico, actually i don't know how the embedde firmware works, i just use the APDU script from nxp to wake-up pn532 via uart.
The raw data flow is captured in the SCRTester that show the communication between host and pn532. If you need that script, pls email to me smile
thanks for your sharing .
Currently, i got the problem that cannot wake-up the pn532 via i2c interface sad
any one know how to wake-up the pn532 via i2c ?

Last edited by tungsys (2009-09-29 10:20:42)

Re: Add support for pn532 chip

zuck wrote:

Hi, I'm trying to add support for pn532 chip to libnfc but I have some issues with the serial port communication. I've added dev_pn532.h and dev_pn532.c to the source tree

Hi Zuck, where do you put your dev_pn532.h and dev_pn532.c ? I  am doing the I2C for pn532 and would like to follow your coding sample.

thanks

Re: Add support for pn532 chip

I've never posted it but since r143 of svn trunk there is a "pn532_uart" device which is derived from ARYGON code and it should work (chip version 1.4).

The 1.6 support is under construction... wink

Re: Add support for pn532 chip

zuck wrote:

The 1.6 support is under construction... wink

It should work using r152 and the PN532_UART driver (dev_pn532_uart.h/c).

Could somebody confirm that it works fine ?

Romuald Conty