NFC Write Failures and Recovery
Why Writes Fail and How to Recover
Diagnosing and recovering from NFC tag write failures including lock bits, password protection, memory limits, and corrupted tags.
NFC Write Failures and Recovery
Write failures are more dangerous than read failures because a partial write can corrupt a tag and make it permanently unreadable. This guide explains the mechanisms behind write errors, how to detect them before they ship, and how to recover tags that appear bricked.
Why Writes Fail More Than Reads
Reading is a one-round RF transaction: the reader sends a command, the tag responds with data. Writing requires the tag to store energy from the RF field during the write cycle — a process that takes 1–5 ms per block and is sensitive to field strength drops, alignment shifts, or power glitches.
| Write Failure Mode | Root Cause | Frequency |
|---|---|---|
| RF field dropout during write | Tag moved mid-transaction | Common in consumer contexts |
| Incorrect block address | Off-by-one in firmware | Rare but catastrophic |
| Writing to reserved memory | Misread memory map | Corrupts capability container |
| Exceeding user-memory | Payload too large | Caught by Memory Calculator |
| write-endurance exhausted | Too many write cycles | Rare in deployments < 100K writes |
| Password mismatch before write | Tag is password-protection locked | Returns NAK |
| lock-bits set | Tag marked read-only | Returns NAK |
| Static lock byte collision | Mis-parsed lock bit map | Corrupts nearby data blocks |
Understanding the Write Cycle
On an NTAG213 (nfc-a Type 2), a write transaction proceeds:
- Reader issues
WRITEcommand with 4-byte block address and 4-byte payload - Tag samples field strength — if insufficient, no ACK is returned
- Tag writes to internal EEPROM (~1.5 ms)
- Tag returns ACK (0x0A) on success, NAK (0x00) on failure
If the tag moves or the field drops between steps 2 and 3, the write may be partial. Partial writes corrupt the affected 4-byte block. If that block is the NDEF TLV length field, the entire message becomes unparseable.
Protective Write Strategies
Strategy 1: Write metadata last
Always write NDEF payload blocks before writing the TLV length and the capability container. The tag is in a consistent (empty) state until the final length byte is committed, so a failure mid-stream leaves the old data intact.
Correct order:
1. Write user data blocks (blocks 4..N)
2. Write NDEF TLV start (block 4, byte 0 = 0x03)
3. Write TLV length byte(s)
4. Write Terminator (0xFE)
5. Verify full read-back
Strategy 2: Always verify after write
Read back every block immediately after writing and compare byte-for-byte. The NDEF Encoder generates the expected byte sequence for comparison.
Strategy 3: Set lock bits last
Never set lock-bits or otp bits until you have verified the full payload. A locked tag with corrupt data is unrecoverable.
Diagnosing a Failed Write
Use raw NFC read tools (NFC TagInfo, PN532 CLI) to dump the full tag memory in hex. Compare against the expected layout.
| What you see | Diagnosis |
|---|---|
| All bytes 0x00 from block 4 onward | Write never started or chip is blank |
| TLV tag 0x03 present, length 0x00 | Write started, TLV length not committed |
| TLV length OK, payload truncated | Field dropout mid-payload |
| Capability container bytes corrupt | Write hit CC area; tag likely unformattable |
| NAK on every write command | Lock bits set or wrong password |
Paste the hex dump into the NDEF Decoder — it will report the exact byte offset where parsing breaks.
Recovery Procedures
Case 1: Corrupt NDEF, unlocked tag
Re-format and re-write. Most NFC apps (NFC Tools Pro, TagWriter) have a "Format" function that rewrites the capability container and clears the NDEF TLV.
Case 2: Corrupt capability container
The CC occupies bytes 12–15 (blocks 3) on NTAG213. Write the correct values directly:
CC byte 0 (0x0C): NDEF Magic Number = 0xE1
CC byte 1 (0x0D): Version = 0x10 (NFC Forum Type 2 v1.0)
CC byte 2 (0x0E): Memory size = 0x12 (144 bytes available / 8)
CC byte 3 (0x0F): Access = 0x00 (read/write)
This requires a raw block-write tool, not a high-level NDEF app.
Case 3: Password-locked, password unknown
Unrecoverable unless the chip supports factory-reset via a specific command sequence. NTAG213/215/216 do not support password reset. Discard the tag.
Case 4: Lock bits set, payload corrupt
Unrecoverable. The locked blocks cannot be rewritten by design. Discard the tag.
Case 5: write-endurance exhausted
Writes silently fail — writes return ACK but data does not persist. Verify by reading back immediately after every write. Replace the tag.
Preventing Failures at Scale
For production encoding lines:
- Encode-and-verify in one fixture: The reader writes, then immediately reads back and compares CRC.
- Track per-tag write count using the tag's serial number if your process requires many rewrites.
- Temperature range: EEPROM write endurance degrades above 85°C. Encode tags before any high-temp process (label lamination, hot foil).
- RF field stability: Mount the encoding antenna rigidly; hand-held encoding introduces alignment jitter.
See Also
자주 묻는 질문
Our guides cover a range of experience levels. Getting Started guides are written for beginners with no prior NFC knowledge. Programming guides target developers integrating NFC into mobile apps or embedded systems. Security guides are for engineers designing secure NFC deployments for payments, access control, or authentication.
Most guides require only an NFC-enabled smartphone (iPhone 7+ or any modern Android device) and a few NFC tags (NTAG213 or NTAG215 recommended for beginners, available for under $1 each). Advanced guides may reference USB NFC readers like the ACR122U or Proxmark3 for development and testing.
Yes. Programming guides include code examples for Android (Kotlin/Java with the Android NFC API), iOS (Swift with Core NFC), and web-based tools (Web NFC API for Chrome on Android). All code samples are tested and include inline comments explaining each step.