Design Notes on Implementing NFC with the ST25DV Series

1. Context and Motivation

(Practical Observations from Real Hardware)

NFC often appears deceptively simple: a tag, an antenna, and a phone. In practice, reliability depends on subtle interactions between antenna geometry, tuning, mechanical stack-up, firmware behavior, and user expectations.

This post documents practical observations from implementing NFC using the ST25DVxx family in a real embedded system. The focus is not on introductory NFC concepts, but on the aspects that most strongly influenced whether NFC worked consistently in practice.


2. Why the ST25DV Series Is Attractive

The ST25DVxx series is appealing for embedded designs because it combines:

  • I²C access from a microcontroller

  • RF access from standard NFC readers

  • Non-volatile EEPROM functionality

  • Fine-grained access control via passwords and area partitioning

  • Minimal external component requirements

In many systems, this allows NFC to function simultaneously as:

  • a provisioning interface,

  • a configuration channel,

  • and a lightweight data logging mechanism,

without requiring a dedicated NFC controller.


3. Antenna Design: Inductance First, Everything Else Second

The NFC antenna’s primary role is to provide a specific inductance that, when paired with a tuning capacitor, resonates at 13.56 MHz.

The resonance condition is:

freq = 1/(2*pi*sqrt(L*C)), where pi = 3.1415.., L = Inductance (H) and C = capacitance

STMicroelectronics provides online tools to estimate antenna inductance based on geometry, which are useful as a starting point.

NFC Inductance | RF Design | eDesignSuite | STMicroelectronics

In practice:

  • Parasitic capacitance is unavoidable

  • PCB copper, nearby ground planes, batteries, and enclosures all shift resonance

  • Final tuning rarely matches first-pass calculations

For this reason, it proved essential to:

  • populate a slightly low tuning capacitance initially,

  • include multiple unpopulated capacitor pads for adjustment,

  • and allow for temporary wiring access during characterization.


4. Bench Characterization Before Integration

A simple loop antenna—such as a single turn of wire approximately 20 mm in diameter—was sufficient to validate basic behavior.

Holding the loop in a controlled position (e.g., using a 3D-printed fixture) allowed repeatable measurements while varying tuning components.

Driving the antenna with a signal generator and observing the response on an oscilloscope (using high-impedance probes) made resonance behavior immediately visible.

One notable observation:
Even with resonance offset by 300–500 kHz, NFC communication remained functional in many cases—particularly when using diagnostic tools such as NFC Tools. However, user-visible behaviors (such as reliably launching a URL without a helper app) degraded more quickly.

In short: getting a response was easier than expected; getting a good user experience was not.


5. Tuning Fragility and Mechanical Sensitivity

Tuning performed on an exposed PCB did not reliably translate once the antenna was placed near:

  • batteries,

  • shielding,

  • metallic fasteners,

  • enclosure walls,

  • within the final enclosure.

This taught an important lesson:
final NFC tuning must be done in something very close to the final mechanical configuration.

Simulation reduces iteration time, but enclosure effects dominate final performance such that it was only worth testing in the final enclosure with the design finalized.

Measured relative antenna response versus frequency before and after a 36 pF tuning adjustment in which the PCB was also installed into the case. Response magnitude is shown as measured in mV RMS from oscilloscope.

Two things are immediately apparent. First, usable NFC response is not confined to a narrow resonance peak; significant coupling is still present even when the resonant frequency is offset by several hundred kilohertz. The additional attenuation of being located inside the mechanical enclosure is also evident.


6. NDEF as the Practical Abstraction Layer

Once RF behavior was reliable, NDEF became the most practical abstraction for interoperability across platforms.

Key takeaways:

  • NDEF works consistently across iOS and Android

  • URL records are universally supported (tap and retrieve a website)

  • External-type records allow structured binary payloads

  • Careful length accounting is essential on small EEPROM devices

Using NDEF avoided platform-specific behaviors and allowed NFC interactions to degrade gracefully when payload size or parsing changed.


7. Using NFC for Configuration and Logging (High-Level)

In this system, NFC was used to:

  • provision a URL,

  • store configuration parameters,

  • and append session-level log data.

Rather than streaming data over RF, logs were accumulated in RAM and written to the NFC tag at session completion. This avoided RF timing sensitivity and kept NFC interactions opportunistic rather than deterministic.

The key constraint was EEPROM size, which drove careful budgeting of:

  • TLV overhead,

  • record headers,

  • and payload formats.


8. What Mattered in Practice

Several implementation details proved disproportionately important:

  • NFC reliability depended more on geometry and tuning discipline than firmware

  • Slight resonance error was tolerable; inconsistent coupling was not

  • NDEF structure clarity mattered more than payload complexity

  • NFC worked best when treated as event-driven, not continuous

Most failures were mechanical or RF in origin, even when they initially appeared to be software bugs.


9. Closing Observations

The ST25DV family enables powerful NFC capabilities with minimal hardware overhead, but it requires system-level thinking.

NFC succeeds when:

  • antenna design is important, but tuning is carried out in the final configuration,

  • limited information flows between the phone and the device,

  • a great deal of thought goes into the framework used to send this information.

Ignoring any one of these tends to produce systems that “mostly work”—which is often worse than not working at all.

Scroll to Top