Impact of setting RFUI OTP bits on NTAG

I’ve been playing with an NTAG216 to test out various changes before writing them to my NExT. One of the tests was to confirm that I understood how the lock and block bits worked and make sure I wasn’t doing anything that might brick the tag.

After setting up the lock bytes to match the config on my NExT, running the following from a PM3 against the static (b)lock bits worked exactly as I expected:

hf mfu rdbl -b 2
hf mfu wrbl -b 2 -d FFFFFFFF
hf mfu rdbl -b 2
hf mfu wrbl -b 2 -d 00000000
hf mfu rdbl -b 2

the reads returned 0F00 in the last two bytes each time and nothing was changed.

Doing the same thing against the dynamic bits however did change the values.

When I ran “hf mfu wrbl -b 226 -d FFFFFFFF”, the two RFUI bits in the second byte, and the one in the third byte were turned on and being OTP memory it is not possible to turn them off again.

This seems like expected behavior since the RFUI bits aren’t protected by the block bits. Being RFU (as opposed to “internal” or just “reserved”) I would think it shouldn’t have any significant effect and in my (very brief) testing it doesn’t seem to have caused any problems, but it does go against the advice in the data sheet (always write the RFUI bits as zeros) so I was wondering if anyone has observed any adverse effects from having these bits turned on?

1 Like

Good idea testing but I don’t think anyone has ever set those to FF haha. Since they are reserved, it’s probably fine.

3 Likes