Blah blah blah

readPassiveTargetID() intentionally waits around in a blocking delay until a card enters the magnetic field. The reason for this blocking delay is to ensure a well-understood command/response flow. Once the magnetic field is activated and a read request is sent via readPassiveTargetID, you can keep sending new commands to the PN532, but the moment a card or tag enters the field, the PN532 will send a response to the initial read request, even if it's in the middle of some other response or activity. To avoid having to debug this in SW, a blocking delay was implemented to keep the command/response pattern as clear as possible.

As a workaround to this blocking-delay limitation, an optional timeout was added to the latest NFC libraries to allow you to set a specific timeout after read requests.

By default, the PN532 will wait forever for a card to enter the field. By specifying a fixed number of retries via MxRtyPassiveActivation (see UM section 7.3.1 describing the RFConfiguration register, specifically CfgItem 5) the PN532 will abort the read request after specified number of attempts, and you can safely send new commands without worrying about mixing up response frames. To wait forever, set MxRtyPassiveActivation to 0xFF. To timeout after a fixed number of retries, set MxRtyPassiveActivation to anything less than 0xFF.

Example Code:

ToDo