How do you write a tag's configuration pages without ruining it?
Read the chip's memory map first, write every page as a whole after reading it, set the password before the setting that switches protection on, and leave every one way bit for last. Then run the whole sequence on a tag you can afford to lose, since no platform API checks what code writes there.
The map belongs to the chip
Configuration pages hold the settings the configuration page lists: password, access conditions, counters, mirroring and lock bits. No NFC Forum type defines them, so their positions change from one chip to the next. An NTAG213 keeps its dynamic lock bytes in page 40 and its configuration in pages 41 to 44, according to its fiche on wakdev.com; an NTAG215 uses pages 130 to 134, according to its own.
A page number is therefore valid for one reference only. Code identifies the chip before writing, as the chip identification page describes from the buyer's side, and refuses to run its sequence on anything else: page 41 of an NTAG213 is ordinary user memory on an NTAG215.
A page is written whole
WRITE sets four bytes at once, and the MifareUltralight reference documents writePage() as writing one page. Configuration bytes share pages, so changing one of them means reading the page, changing that byte, and writing the four back.
Write back what you read for the bytes you do not mean to change. A byte written as zero because the code did not know its meaning is a setting changed without anyone deciding it, and some settings do not come back.
Not every page reads back what was written. The page holding the password is normally not readable, as the password page notes, so code keeps the value it wrote instead of expecting to read it back.
An order that keeps you in
Write the password before the setting that switches protection on. The password page describes the two steps, the key and its scope; in the other order, protection starts with whatever password the chip held before, and later writes inside the protected range need that one.
Leave one way settings for the end. Lock bits, a counter that cannot be disabled once enabled, and a bit that freezes the configuration itself are permanent on the chips that have them, as the configuration page warns, and each one set early turns a mistake further down the sequence into a lost tag.
Read each page back after writing it, except those that are not readable, and stop at the first difference. A sequence that continues past a failed write builds on a state nobody knows.
One tag to lose first
Run the complete sequence on one tag before the batch, then check it from a second device that does not hold the password: a write that succeeds there means the scope is wrong, the test the password page recommends. On the same tag, try a wrong password as well where the chip limits failed attempts, since the limit goes into production with everything else.
Keep that tag, labelled with the sequence and the date. It is the reference when a batch behaves differently, the same reasoning as the dead tag the corrupted tag page suggests keeping to test a verification step.
Then write the batch with the same code, not a variant of it. The bulk writing page covers the production side.
Frequently asked questions
Can the NDEF API write configuration pages?
No. Configuration sits outside NDEF, so it takes raw WRITE commands on the pages the chip's datasheet names.
Why did my configuration write land in the content?
The page number belonged to another chip. Page 41 holds configuration on an NTAG213 and user memory on an NTAG215.
Can a wrong configuration be undone?
A password can be changed with the current one. Lock bits and a frozen configuration cannot, on any chip that has them.
Should the password be written before or after the protection setting?
Before. Otherwise protection starts with the password the chip already held, and later writes in the protected range need that one.