Im wondering if its a case of it dosnt know how to deal with the fact that it cant just continue writing because those pages are slap bang in the middle of the user memory pages (Great job NXP)
1 Like
Possibly, yeah. I’ll do some testing with odd cases like this, and I’ll order some test NTAG i2Cs, since I don’t have access to any of those chips to test for compatibility.
1 Like
Thanks for finding this, honestly!!!
1 Like
We have test cards coming soon with ntag i2c (and breakout pins for the i2c bus)
1 Like
The super strange thing is i tested it on a i2c test card and it worked fine 
1 Like
Yes they will be and yes I’ll send you some asap
1 Like
So it loks like the problem mentioned above by @Devilclarke most likely has to do with this:
I was not aware of this problem, as I don’t have an xSIID installed, nor do I have any NTAG i2C devices. After I get a few, I’ll start messing around with the special care that this device needs in order to take full advantage of the 2K bytes of memory it’s got. I’m just about to start with programming up some of the base activities, fragments and utility classes for the DangerousNFC 2.0 application (after I finish mocking up the UI, writing some base logic out, and running it by @amal ). We’ll have plenty of motivation with that project to make sure the xSIID is fully “writable”.
5 Likes
Beautiful!!! Can’t wait to get my hands on one.
After much back and forth with NXP over the issues with the xSIID and accessing all 2k, it appears that android and iOS simply choke on trying to read ndef data that skips over a reserved section… and after reviewing the NFC Type 2 forum specification, there clearly is no provision for handling memory topography like that. The Memory TLV definition simply handles a single reserved section but there is no provision for reading memory beyond it, so basically the phones and reader chips in the phones can easily access that extended memory sector on 2k NTAG I2C chips, and you could also easily write your own mobile applications to do so, in the end the NFC library functions in both phone OSes which read and parse the data simply trip over it and land on their faces.
As such, these cards currently have 2k chips but they have been set up with a CC (capability container) that only addresses the first 1k for NDEF data. New cards, if they are made, will have 1k chips. The same is likely to be true for the next batch of xSIID as well.
3 Likes
2K… Pff… 640 bytes ought to be enough for anybody.
1 Like
If I make a gif that small, can it be scanned to show that by anyone?
I was thinking that when I saw your post the other day. I will give it a shot.
curious what NDEF record type is used for that?
Either NFC forum external type (TNF 4) or unknown (TNF 5) works with Android. When Android sees one of those two types, it grabs the first string in the text record and interprets it as a mime type - in this case, text/vcard, but it can be anything as long as Android can match it to an intent.
This is non-standard though. Pretty much Android-specific behaviour. However, seeing as though Android is a kind of a de-facto standard… 
1 Like
Man, that really sucks.
I don’t suppose we’ll see any way to get access that extra bit of memory then. It looks like Ultralight android APIs allow for specific page indexes when writing raw bytes, but there’s nothing of the sorts that I can see that would work with the i2c where we could maybe skip that reserved section manually. Nothing to extend/modify either that I can find. It doesn’t seem like the code for how android handles read/write operations under the hood is even available, and what is available isn’t granular enough to be able to modify for different results.
1 Like
Yep thats what I got from nxp was talking to them as my work may have an application for the i2c (allowing customers to store settings for our device and update them via ther phone).
The litteral response i got from nxp was “the 2nd sector is not meant for ndef data” when I asked what it was for then I was told “whatever your application wants to write but it can’t be read with a phone”.
1 Like