NFC Tag becomes "corrupted" after writeNdefMessage interrupted I/O

Question

We have an Android application that communicates with an NFC tag on a custom hardware device. The hardware device can also communicate and perform operations on the tag mounted to it.

The Android application communicates with the NFC tag in two ways:

IsoDep#transceive(byte[]) for triggering a power cycle of the hardware device.
Ndef#writeNdefMessage(NdefMessage) for writing an NdefMessage/NdefRecord with some user data.

Functionally, these operations look something akin to:

private static final byte[] NDEF_SELECT_APP_FRAME = new byte[] {
    (byte) 0x00, (byte) 0xA4, (byte) 0x04,                  
    (byte) 0x00, (byte) 0x07, (byte) 0xD2,                  
    (byte) 0x76, (byte) 0x00, (byte) 0x00,                  
    (byte) 0x85, (byte) 0x01, (byte) 0x01                   
}; 

private static final byte[] SYSTEM_FILE_SELECT = new byte[] {   
    (byte) 0x00, (byte) 0xA4, (byte) 0x00,                  
    (byte) 0x0C, (byte) 0x02, (byte) 0xE1,                  
    (byte) 0x01                                             
};                                                              

private static final byte[] TOGGLE_GPO = new byte[] {           
    (byte) 0xA2, (byte) 0xD6, (byte) 0x00,                  
    (byte) 0x1F, (byte) 0x01, (byte) 0x00                   
}; 

boolean recordSuccess = writeRecord(tag, intent, context);
if (recordSuccess) {
    boolean success = transceive(NDEF_SELECT_APP_FRAME, tag, context)
            && transceive(SYSTEM_FILE_SELECT, tag, context)
            && transceive(TOGGLE_GPO, tag, context);
    if (success) {
        // Success!
    } else {
        // Error!
    }
}

We've found that, very occasionally, it seems possible that I/O can be interrupted while the Ndef data is being written (we're not sure why, but we presume pulling the phone away from the tag at just the right time is the reason). This seems to result in the tag being in a "corrupted"-like state, where the previous Ndef data can no longer be found on the tag. In fact, tag.getTechList() won't even list Ndef as an available technology on the tag, though it was originally available.

All further attempts to write Ndef data to the tag will then fail because Ndef.get(tag) will return null.

As far as I'm aware, the normal procedure from this point would be to reformat the tag using NdefFormatable. However, NdefFormatable is not listed as a technology type in tag.getTechList(), and so NdefFormatable.get(tag) also returns null.

Questions:

Why is the tag seemingly becoming corrupted/erased?
Why is Ndef not listed as a tag technology after corruption, even though the tag originally supported it?
How can we recover from this state, given that NdefFormatable.get(tag) seems to return null?

EDIT: The NFC chip appears to be a M24SR04-Y. The specification sheet can be found here: https://www.st.com/resource/en/datasheet/m24sr04-g.pdf.

Capability Container contents shown by TagInfo app:

# Capability Container (CC) file content:
Mapping version 2.0
CC length: 15 bytes
Maximum Le value: 246 bytes
Maximum Lc value: 246 bytes
NDEF File Control TLV:
* Length: 6 bytes
* NDEF file ID: 0x0001
* Maximum NDEF data size: 512 bytes
* NDEF access: Read & Write
[0] 00 0F 20 00 F6 00 F6 04 06 00 01 02 00 00 00    |.. ............ |

Adarsh Rotte Adarsh Rotte · Accepted Answer · 2020-06-01T06:54:22

After having a glance at the datasheet shared by you, following are my observations:

0xE103 : CC File
0x0001 : NDEF File
CC File is Read-Only from both RF and I2C
Max NDEF File Size: 512 bytes
Read and Write : Free Access
Max No of bytes can be read or write in one operation : 246 bytes
Assuming that CC content has never changed: 00 0F 20 00 F6 00 F6 04 06 00 01 02 00 00 00 : 15bytes

With reference to the code snippet of operations shared by you:

What is it that you are doing in TOGGLE_GPO? Session Open, WIP or MIP?
I suspect that the card is going in corrupted-like state, when it is interrupted during this phase
Assuming that you are not modifying the CC file content in writeRecord().
If possible, share the low-level details of every steps that you are performing, which will help understand better.

Update:

Now that the possibility of Corrupted CC is ruled out, the next step would be to do the same for NDEF TLV, especially the V block where the NDEF File ID, Max. NDEF size and Read/Write Access of NDEF File are stored, by comparing Working and Corrupted state values.
Identify the step, where upon occurring error the card goes to corrupted state. This could be achieved by logging every step. If the card gets corrupted on interruption at a specific step consistently, then it will narrow down the hunt.
Try to SET the StateControl, when the card is in corrupted state. This is just a random thought, but might help.

Cheers!

NFC Tag becomes "corrupted" after writeNdefMessage interrupted I/O

2 Answers