Writing in user memory using ST25 framework on iOS inserts undesired 0x02 bytes (STS5DV04KC-I)

[louis-brunet]

Hello, I am writing a mobile application to interact with a STS25DV04KC-I chip. I am encountering problems when trying to write to to user memory on this chip from iOS using the ST25 framework.

I want to write a byte array into area 2, and to modify the NDEF records stored in area 1.  

I have successfully integrated the ST25 SDK on Android to fulfill these needs. When using the Android version of the SDK, I could successfully read and write bytes transparently with no issue (using the methods writeBytes and writeNdefMessage on the discovered tags).
My problem with the iOS SDK is the following: when writing data, there are extra, undesired bytes with the value 0x02  that are inserted into the data written to the chip. Example: I want to send the values [0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10], but the values written to memory are [0x02, 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0a, 0x02, 0x0c, 0x0d, 0x0e, 0x0f, 0x10].

- There is a 0x02 byte inserted before my byte array, offsetting every written byte by one byte address.

- Every 2-3 blocks (8-12 bytes, depending on the size of the written byte array), a byte is lost and replaced with this same value 0x02.

 

This happens both when calling the methods writeBytes and writeNdefMessage. One possible workaround for this is to split up calls to writeBytes into smaller chunks: for example, there are not extra 0x02 bytes added when using the iOS SDK to write 4 bytes at a time. This workaround also allows me to modify the NDEF message stored in area 1.

However, this solution is not satisfactory as I cannot risk corrupting the content of my chip's NDEF message, lest I have to manually intervene to rectify the EEPROM. I would prefer to do as much writing as possible in one message, while not getting these undesired 0x02 bytes.

 

Could someone please explain or link to resources explaining how to prevent these 0x02 bytes from being inserted into the STS5DV04KC-I's memory when writing user memory with the ST25 SDK on iOS?

 

I am unsure which other relevant information I could provide:

- ST25 framework (iOS) - 1.6.0 downloaded from https://www.st.com/en/embedded-software/stsw-st25ios001.html 

- iOS 18.5 

- iPhone 12 Pro

[victor laraison]

 

Hi Louis,

Thank you for your detailed description of the issue you are encountering with writing to the ST25DV04KC-I chip using the iOS ST25 SDK.

To better assist you, could you please confirm if your application is using our provided iOSReaderInterface as part of the ST25 SDK to handle communication between the SDK and iOS Core NFC? This interface is designed to manage data framing and command transmission, which might be related to the extra bytes you are seeing.

the iOSReaderInterface we provide in the SDK acts as the intermediary between the ST25SDK and the iOS Core NFC framework. Its role is to handle the low-level NFC communication, including framing and sending commands such as writeSingleBlock to the tag.

The extra 0x02 bytes you observe could be related to how the data is chunked or framed at a lower layer, possibly within the writeSingleBlock implementation.

To help resolve this:

If possible, share the exact usage pattern or code calling this writeSingleBlock method, so we can check if any additional data manipulation or framing might be occurring before this interface.
Please feel free to provide more details or code snippets, and we will be happy to support you.

Best regards,

 

 

[louis-brunet]

Hi Victor, thanks for the response.

Yes I confirm that we are using the iOSReaderSession class to start an NFC tag discovery session, implementing its protocol "tagReaderSessionViewControllerDelegateWithFinallyBlock". We tried to adapt the source code found in the demo NFC Tap app.

I have attached a file DemoApp.swift showing how we are trying to use the ST25 SDK in the iOS part of our Flutter application : from the handleTag() method, for each area to write, first present the password then try to write (either with nfcTag.writeNdefMessage() or nfcTag.writeBytes()).

I have tried calling the methods on the generic ComStSt25sdkNFCTag instance, or on more specific ST25DVCTag instances (writeBytes, write*Blocks, writeNdefMessage), as we successfully did in our Android implementation. However in either case and for any of these methods, when the bytes to write get longer than 1 block (4 bytes), I can observe these extra 0x02 bytes being written into the EEPROM (I can see this using the NFC Tap app and reading the written memory, comparing with the parameters passed to writeBytes()).

I assume we are misusing the iOS SDK, since this behavior is not present in our usage of the Android ST25 SDK even though are trying to call the equivalent methods.

[victor laraison]

Thx for information.

Please, could you send me the iOSRFReaderInterface.swift used into your app ? Same as provided into iOS NFC Tap  ? 

 

 

[louis-brunet]

I have attached the entire st25sdkiOS folder I am using at the moment. It includes the file iOSRFReaderInterface.swift. I believe we have not made any modifications to this file, it should be the same as in iOS NFC Tap. 

The most modifications I have done to the framework files were:

- adding a parameter scanningSheetMessage to iOSReaderSession's session start methods (tag reader and NDEF reader sessions) ;

- adding the includes "Type5Tag.h" and "ST25DVCTag.h" to the file st25sdkFramework.framework/Headers/st25sdkFramework.h to be able to use the class ST25DVCTag in Swift.

[victor laraison]

please, could you uncomment line 113 in iOSReaderInterface.swift (#DEBUG), then sending me the debug log when doing the "nfcTag.writeBytes(with: byteAddress, with: ssidIosByteArray)" command ? 

Thx

 

[victor laraison]

After reviewing the details, it appears that theiOSReaderInterface version currently in use on our side is not the latest one you are using in your latest application. To address this, I am sending you the updated version of the interface shortly.

Please use this latest version, and let me know if the issue persists or if you need any further assistance.

I have conducted several tests with the latest file to reproduce the issue you reported regarding data writing on ST25 chips.

I tested with S25DV64KC and ST25TV02K tags using the following command in my iOS code:

func handleTag(st25SDKTag: ComStSt25sdkNFCTag, uid: Data!) throws {
 let mAddressOffset = 0x08
 let mData = Data([0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, 0x10])
 
 st25SDKTag.writeBytes(with: jint(mAddressOffset), with: IOSByteArray(nsData: mData))
}

Below are excerpts from the command logs during these tests:

--> writeMultipleBlock command: 22 24 fe ec 26 06 00 51 02 e0 02 03 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
[4 bytes, 4 bytes, 4 bytes, 4 bytes]
--> writeSingleBlock command: 22 21 fe ec 26 06 00 51 02 e0 06 10 2f 66 72

And on another tag:

--> writeSingleBlock command: 22 21 ea 94 be 0d 00 08 02 e0 02 00 01 02 03
--> writeSingleBlock command: 22 21 ea 94 be 0d 00 08 02 e0 03 04 05 06 07
--> writeSingleBlock command: 22 21 ea 94 be 0d 00 08 02 e0 04 08 09 0a 0b
--> writeSingleBlock command: 22 21 ea 94 be 0d 00 08 02 e0 05 0c 0d 0e 0f
--> writeSingleBlock command: 22 21 ea 94 be 0d 00 08 02 e0 06 10 6d 6f fe

After these tests, I was unable to reproduce the insertion of undesired 0x02 bytes in the written data.