PN532 ISO 14443A-4 slow communication

cancel
Showing results for 
Search instead for 
Did you mean: 

PN532 ISO 14443A-4 slow communication

466 Views
Contributor I

Hello,

I already sent this post few months ago, I hope to have an answer about the issue today.

I configured a PN532 as target and a PN512 as the initiator.  When I present the target in front of the initiator, it starts a NFC communication (data transfer).  But I noticed the PN512 receives the data few milliseconds too late and it's what I want to understand. 

I changed the code in order to send 17 bytes (See 17bytes... picture) from the target to the initator and it take more than 5 ms for the initiator to receive the data.  At 424 kbps for 17 bytes, it should take less than 1 ms to transfer.

The other picture (Communication issue.png) shows a bigger data transfer.  The PN532 is using chaining mode to transfer 64 bytes from the target to the initiator.  It takes around 10 ms for the PN512 to receive the 64 byte.  Again, from my perspective, it takes too long time to transfer the data. 

I'd like to know if it's possible for the PN532 or PN512 to transfer right away the data without latency?  I'd like to have an efficient communication when I need to send big data.

I hope to have an answer from you guys.  If you need more info, I can answer you! 

0 Kudos
5 Replies

96 Views
NXP TechSupport
NXP TechSupport

Hi Christian,

Thanks for the information! Actually to transfer/receive the 17 bytes , you should also take PN532 handling time, SPI interface data rate, and NFC transfer rate into account , so I agree 320usec is correct for transfer the 17 bytes via NFC, but it doesn't include all the transfer time, and I am also confused how you know the positions of cursors A1 and A2 are correct for the start and end of the transfer. Would you please help to clarify?

In my understanding ,it may be more clear to try the following test:

1. MCU on PN532 side toggles some GPIO when it sents 17 bytes out.

2.MCU on PN512 side toggles another GPIO when it receives 17 bytes.

Given these two MCU already know the 17 bytes for test.

Then you may measure the gap between these  two GPIO toggle signals to get the time for transfer the 17 bytes.

Would you please try the above test on your side? Thanks for your patience!

BTW, I also consulted our AE side, and they suggested sending the following command to PN532 side:

08 02 FF 00;register 02FFh from 02 (default value) to 00. Then the frequency changes from 6.58 MHz to 27.12 MHz


Hope that helps,
Have a great day,
Kan

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos

96 Views
Contributor I

Hello Mr Kan Li,

Thank you very much for the hint,  I changed the clock speed to 27 MHz and I noticed a nice change.  I passed from ~5 ms to 2.5 ms to transfer 17 bytes.  It's great!!  But I don't know what should be the consumption once I change the clock speed.  I could check that later.  So, is it possible to do other changes in the PN532 in order to optimize the process time? 

The cursor A1 is located to the 17 bytes transfer. Another question, why does it take so long time to receive the ACK answer (sometimes it can take 15 ms to receive a ACK).  For me, that means that the PN532 firmware is not optimized to be very fast.  For our product, the process time is very critical.

Best regards

Christian

0 Kudos

96 Views
NXP TechSupport
NXP TechSupport

Hi Christian,

In my understanding, 424kbps is the baud rate of NFC interface, but per your measurement , you also included the time of MCU pulling register and reading data from the front end, right? if so, maybe you can check if the SPI rate could be set a little bit higher, that might be helpful to decrease the time. another thing I was confused is looks like CS signal on PN512 side was toggled many times to read the 17 bytes, did it also read something else? I think you are using MCU + front end solution, so on MCU side it should know when 17 bytes were sent out and received, so maybe it is more clear to try the following test:

1. MCU on PN532 side toggles some GPIO when it sents 17 bytes out.

2.MCU on PN512 side toggles another GPIO when it receives 17 bytes.

Given these two MCU already know the 17 bytes for test.

Then you may measure the gap between these  two GPIO toggle signals to get the time for transfer the 17 bytes.


Hope that helps,
Have a great day,
Kan

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos

96 Views
Contributor I

Hello,

Thank you for your reply.  I think you misunderstood the picture.  The SPI clock is actually configured at 8 Mbps.  The 424 kbps is the bit data rate (NFC).  The many CS toggling on PN512 side is used to poll a status register (register address 0x07h) until IRQ bit was set (meaning that PN512 has available data in FIFO).  So, as you said, a MCU host sends a 17bytes to PN532 through SPI interface, a MCU from PN512 side polls status register until the IRQ bit is set and then, the MCU will retrieve the 17 bytes.  I don't understand why the NFC transfer is so long between the PN532 and PN512.  I need to have a data transfer as fast as possible.

Thank you very much!

Christian

0 Kudos

96 Views
Contributor I

As I explained in my first message, the 17-bytes transfer should takes less than 1 ms once the MCU transferred the data through the SPI interface.

At 424 kbps ==>  17 bytes * 8 bits/byte * 1s / 424 kbps = 320 usec to transfer 17 bytes. 

From the 17 bytes picture, delay between cursors A1 and A2 take more than 5 ms  ("A1" is PN532 transfer and "A2" PN512 receive).  How can I speed up the PN532 to transfer the data as fast as possible?

0 Kudos