cancel
Showing results for 
Search instead for 
Did you mean: 

M24LR16E-R ST25SDK iOS (Swift): "BAD_PARAMETER" on readBytes due to 0 Memory Size

allevi72
Associate

Hello everyone,

I am developing an iOS application using the ST25SDK (converted/wrapped for Swift) to interface with the M24LR16E-R Dynamic NFC Tag.

I am facing a blocking issue where any attempt to call readBytes() (which is used in TagReadMemoryGenViewController.readMemoryContent) throws a ComStSt25sdkSTException with error code BAD_PARAMETER.

The Setup:

  • Chip: M24LR16E-R (IC Ref: 0x4E)

  • Platform: iOS (Swift) using CoreNFC

  • Library: ST25SDK for iOS

The Problem: Upon investigation, the root cause appears to be that the ST25SDK mTag.getMemSizeInBytes() returns a memory size of 0 bytes. Consequently, when readBytes() is called, the SDK performs an internal safety check: if (address + length > mMemSizeInBytes) { throw BAD_PARAMETER; } Since mMemSizeInBytes is 0, this check always fails.

Root Cause Analysis: The issue seems to originate in the iOSRFReaderInterface during the Get System Info command. The M24LR16E-R has 512 blocks (2048 bytes total). When using CoreNFC's native getSystemInfo method, it seems unable to correctly parse the number of blocks for this specific tag (likely due to the 8-bit overflow since 512 > 255), returning invalid values (e.g., -1 or 0) to the bridge.

When the ST25SDK receives this invalid data from the reader interface, it defaults the memory size to 0.

What I have tried: I am attempting to patch the getSystemInfo method in my iOSRFReaderInterface.swift to manually construct the raw response buffer expected by the SDK. I noticed that ISO 15693 specifies that if nbBlocks > 256, the response should contain 0xFF in the Number of Blocks field.

My current workaround logic is:

  1. Detect IC Ref == 0x4E (M24LR16E).

  2. If CoreNFC returns invalid block counts, I manually force the response buffer to contain 0xFF for the number of blocks.

  3. I expect the ST25SDK to recognize the 0xFF + 0x4E combination and incorrectly calculate the 2048 bytes size from its internal lookup table.

My Questions:

  1. Is there a standard/recommended way in the ST25SDK for iOS to handle High Density tags (like M24LR16E) where the block count exceeds 1 byte?

  2. Does the SDK require the Get System Info response to be manually patched with 0xFF in the iOSRFReaderInterface, or should it handle the "Extended Get System Info" automatically?

  3. Why does readBytes throw BAD_PARAMETER immediately instead of attempting an actual read command if the memory size is not fully determined?

Any snippets or guidance on how to correctly implement getSystemInfo in the iOSRFReaderInterface for M24LR16E would be greatly appreciated.

Thanks in advance.

1 ACCEPTED SOLUTION

Accepted Solutions
JL. Lebon
ST Employee

Hello, 

Unfortunately, the M24LR16E is not supported by iOS and there is no way to have it working.

Please see Solved: NFC. memory M24LR 64 ER - STMicroelectronics Community

Best regards.

View solution in original post

1 REPLY 1
JL. Lebon
ST Employee

Hello, 

Unfortunately, the M24LR16E is not supported by iOS and there is no way to have it working.

Please see Solved: NFC. memory M24LR 64 ER - STMicroelectronics Community

Best regards.