How Do You Implement NFC Tap-to-Pair for BLE on the nRF52?

Detailed Explanation

NFC tap-to-pair solves a real BLE onboarding problem: Just Works pairing has no protection against eavesdropping, and Passkey Entry or Numeric Comparison both need a display and/or buttons the product may not have. Out-of-Band (OOB) pairing exchanges the authentication data through a separate physical channel instead of over the BLE radio — and NFC is the most common OOB channel for consumer products, because tapping a phone against a device is a familiar, zero-friction interaction. For the BLE pairing methods and security levels this fits into, see BLE Pairing and Security in Embedded Products.

The NFCT Peripheral: Tag Emulation Only

The nRF52832, nRF52833, and nRF52840 include an NFCT (NFC Tag) peripheral that emulates a passive NFC tag — specifically, an NFC Forum Type 2 or Type 4 Tag. This is a one-way capability: the nRF52 can be read by an NFC reader (a phone), but it cannot itself read other NFC tags or act as an NFC reader. This distinction matters early in a design, since "NFC support" on a datasheet feature list can be misread as full reader/writer capability rather than tag-only.

The NDEF Bluetooth Carrier Configuration Record

When a phone taps the device, it reads an NDEF (NFC Data Exchange Format) message from the tag. For BLE pairing, this message contains a Bluetooth Carrier Configuration record — a standardised NDEF record type (defined in the Bluetooth SIG's Secure Simple Pairing Using NFC application document) that carries the device's Bluetooth address and the OOB pairing data (the security-relevant material the BLE stack uses to authenticate the pairing without requiring a passkey or numeric confirmation). The phone's OS reads this record on tap and hands the extracted Bluetooth address and OOB data to its Bluetooth stack to initiate OOB pairing.

Nordic's SDKs provide helpers for constructing this record rather than requiring it to be hand-built byte-by-byte: the nRF5 SDK's nfc_ble_pair_msg module generates the correct NDEF message from the device's actual Bluetooth address and OOB data at runtime, and the nRF Connect SDK (Zephyr) provides equivalent NFC/NDEF subsystem support.

The UICR NFC Pin Gotcha

The nRF52's two physical NFC antenna pins (NFC1/NFC2) default, via the UICR (User Information Configuration Registers), to NFC antenna function rather than general-purpose GPIO — even on designs that never intend to use NFC at all. If a board design routes these pins as ordinary GPIO (a common mistake when a design copies a reference layout without checking pin function defaults), the pins will not behave as expected until the UICR NFCPINS register is explicitly reconfigured to GPIO mode. Conversely, a design that does intend to use NFC must ensure this register is left at its NFC default (or explicitly set to NFC mode) and must never accidentally reconfigure it to GPIO in firmware. This is a one-time UICR setting, not a runtime GPIO configuration call, and getting it wrong produces a pin that appears completely non-functional regardless of how the GPIO driver is configured.

Antenna Design

NFC operates at 13.56 MHz using near-field magnetic coupling, not a conventional RF far-field antenna — the antenna is a small loop (a PCB trace loop or a discrete wound antenna) tuned to resonance with matching capacitors, connected directly to the NFC1/NFC2 pins. Nordic's reference designs (including the nRF52840 DK) specify working antenna geometries and matching component values as a starting point; a mismatched or incorrectly sized loop significantly reduces tap read range, sometimes to the point of requiring the phone to be pressed directly against the exact antenna location rather than anywhere on the product's surface — a poor user experience for a feature whose entire value proposition is convenience.

Design Considerations

• Confirm the specific nRF52 variant has NFCT before committing to this feature — the nRF52810/52811 do not have it, and substituting a variant late in a design changes both the BOM and the antenna layout requirements.
• Decide the UICR NFC pin configuration deliberately, in both directions — explicitly set NFCPINS to GPIO mode if NFC is not used on a board that has these pins routed as GPIO, and explicitly confirm (and never override in firmware) NFC mode if NFC is used.
• Follow a validated reference antenna design rather than an arbitrary loop trace — antenna geometry, matching capacitor values, and PCB placement all affect read range and reliability; start from Nordic's reference layout and validate tap range with real target phones before finalising the mechanical design.
• Test the actual pairing trigger behaviour on both iOS and Android, since NFC-to-Bluetooth handoff is not implemented identically across platforms — plan for a companion app on iOS specifically if OS-level tap-to-pair doesn't behave as expected during development.

For BLE onboarding, NFC tag emulation, and secure pairing firmware on Nordic hardware, Zeus Design's firmware team develops production nRF52 firmware for connected products.

Common Mistakes

• Leaving NFC1/NFC2 pins routed as GPIO on a board without reconfiguring UICR NFCPINS — the pins silently fail to behave as either working GPIO or working NFC until this register is explicitly set to match the actual board design.
• Assuming "NFC support" means the nRF52 can read external tags — the NFCT peripheral is tag-emulation only; a design that needs to read NFC tags or cards needs separate reader hardware.
• Copying a generic NFC antenna loop without validating against Nordic's reference design and matching values — an untuned antenna can reduce tap range so severely that the feature feels broken even though the firmware and NDEF message are correct.
• Assuming NFC tap-to-pair behaves identically on iOS and Android — iOS's more restrictive NFC-to-Bluetooth integration often requires companion-app involvement that Android may not need; verify both platforms independently rather than testing on only one during development.
• Hand-building the NDEF Bluetooth Carrier record instead of using the SDK helper — the record format has specific structural requirements from the Bluetooth SIG's NFC pairing specification, and a hand-rolled implementation is a common source of tags that read successfully as generic NFC data but fail to trigger BLE pairing on the phone.