RF430FRL152H NDEF capability with NFC Android phones

Hi Dennis,

I'm moving this thread to the NFC/RFID forum, their experts should be able to help with your question.

Regards,
Ryan

Hello Josh,

Just to clarify.

What does an Android NFC NDEF Format action do other than to write a structure to the chips accessible memory blocks?

If as you say this is important then perhaps I need to format the chip memory accordingly. i.e. format it.

But a low level format is equivalent to writing a structure to the memory being formatted.

OK so  then what could that "magic" byte sequence be?

If I knew it and I wrote it to memory, then I think what you are saying is that my SAMSUNG would recognize it as a nicely formatted NDEF device.

Is that true?

Ralph seems to imply there is something deeper Android must be "told" such that NDEF messages can be supported.

So my point or question is: Do you think that formatting the RF430FRL152H as an NDEF device will enable it to support NDEF?

From my point of view I agree with you totally, I dont see why Android can read the byte sequence in the chip but then then reject a totally valid NDEF data structure that abides by NFC TAG 5 specs and say its not NDEF. 

I think Android must "know" this device is simply not to be supported... no?

BEst

Dennis

Hi Dennis,

For older Android phones there are some cases where the Android phone does not recognize the FRL as an NDEF capable device period. We'd have to test with newer devices like the S6 so see if that is no longer the case with the newest phones. Phones using Broadcom's chipset for NFC won't have this issue though.

However, regardless of that particular aspect, the real problem you will have is using the Sensor application and NDEF at the same time which is just not possible.

NFC Devices that are looking NDEF messages, including Android phones, will read Block 0 (for ISO15693, such as RF430FRL152H) to determine if there is an NDEF tag by looking for what is called the Capability Container which contains the basic information needed for NDEF message formatting such as the version number, read/write capabilities, and memory available.

The problem at hand here is the RF430FRL152H uses Block 0 (and some other blocks below it) to run the Sensor Application. Therefore it is impossible to place the Capability Container at this memory location when using it for any Sensor based applications. Since the CC can't be located at Block 0, no Android phone can recognize it as an NDEF capable device when using the Sensor application.

Dear Ralph, Josh,

I kind of disagree.

The FRAM from FRAM_LOCK_BLOCKS 0xF840 //Address of ISO15693 lock blocks have tried to

does not have any significance for the micro-controller.

As i understand it , from the data sheet, it was specifically meant to be the place to find NDEF messages.

So I have diligently loaded this area with correctly NFC Tag 5 spec formatted data. Very simple, but correct.

E1 40 F2 09 03 0B D1 01
07 54 02 65 6E 41 42 43
44 FE 00 00 00 00 00 00

This would result into an NDEF message containing one Text record with the message "ABCD".

The first 4 bytes (E1 40 F2 09) are the capability container:

0xE1 is the magic number identifying the capability container for a tag where the complete memory area can be addressed with one byte block addresses.
0x40 codes version 1.0 of the Type 5 tag memory mapping and indicates free read/write access to the memory.
0xF2 defines the overall NDEF memory area (except for the CC bytes) to have a length of 242 (0xF2) times 8 bytes (= 1936 bytes).
some may argue this should be 0xF3 but I have tried both
0x09 indicates that the tag supports the READ_MULTIPLE_BLOCKS command (bit 0 set) and the LOCK_BLOCK command (bit 3 set).

The next 2 bytes (03 0B) are the header of the NDEF Message TLV (tag-length-value coded data structure):

0x03: Header byte indicating NDEF Message TLV.
0x0B: Length of NDEF Message TLV = 11 bytes.

The next 11 bytes (D1 01 07 54 02 656E 41424344) are the NDEF message:

0xD1: Record header byte:
Bits 7 and 6: This is the only record of the NDEF message.
Bit 4: This is a short record (i.e. the payload length is coded with a single byte).
Bits 2..0: The record type codes an NFC Forum well-known type.
0x01: The type name field has a length of 1 byte.
0x07: The payload field has a length of 7 bytes.
0x54: The type name (in ASCII: "T") indicating an NFC Forum well-known Text record type (Text RTD).
0x02..0x44: The payload field of the Text record:
0x02: The text is encoded in UTF-8, the language field consists of 2 bytes.
0x65 0x6E: The language field (in ASCII: "en") indicating the language English.
0x41 0x42 0x43 0x44: The text payload (in UTF-8: "ABCD").

The next byte (FE) is the Terminator TLV indicating the end of the used data area. The remaining bytes of that block are filled with zeros (0x00) in order to avoid problems with some Android devices.... is our guess.

But despite we think we have correctly structured the data, we found this doesnt work.

Actually we followed many hints from the TI software developer who wrote he examples provided for the chip.

In these examples he/she hints that probably the example will not work but might...

So my point and question is:

is the NDEF recognition a function of
a) low level RF interactions not transparent to me and my firmware OR
b) the data bytes from address 0xF840 onwards

if a) then I am wasting my time and must wait for Android to get acquainted with the FRL152

if b) as is being suggested from your kind posts (i.e. a data formatting issue) then
what should the capability container contain.

Note that we found similar problems with other Type 5 TAGs misbehaving, such as Texas Tag-it HF-I Plus which need work arounds in the capability container to work i.e. fiddle the memory block length field.

So while I dont know what to do, I need to know if NDEF formatting will help or not. And if so why?

BEst

Dennis

Hi Dennis,

For starters...

Are saying that you wrote this data:
E1 40 F2 09 03 0B D1 01
07 54 02 65 6E 41 42 43
44 FE 00 00 00 00 00 00

To address 0xF840?

Or did you mean 0xF868?

Sorry copy pasting too fast these days....

#define NDEF_START_ADDRESS 0xF868
#pragma RETAIN(NFC_NDEF_Message);
#pragma location = NDEF_START_ADDRESS; // the location of the address
u08_t NFC_NDEF_Message[20] = {
// Most of the Android applications will not recognize this message as NDEF at this point, due to the
// tag not being registered with Android NFC stack. However ISO15693 RFID communication is supported.
// Block 0
0xE1, // NDEF Magic Number
0x40, // Version Number, read/write access conditions
0xF2,
0x09,//extended memory //0x00, // does not support read multiple blocks (limited to only 3 blocks)


here is a frag of my code

Dennis

Hi Dennis,

Okay good - that is great to hear because that means you didn't lock a number of blocks on accident :)

I am going to send you an E2E Friend Request so we can take this discussion offline temporarily. I have spoken to Alex (who I assume it the TI software developer you referred to above) and have something that may help you further.

Dear Jacobi,

I am trying to use NDEF with RF430FRL152H.
I have followed this thread, and another similar thread at Stack Overflow:
stackoverflow.com/.../ti-rf430frl152hevm-nfc-ndef-formatting
Reading ‘Additional information 3’ of the above site, it seems that NDEF actually works on RF430FRL152H. However, it seems to require changing settings beyond memory configuration. It my understanding correct? If so, what would need be changed?

Tag hardware: RF430FRL152HEVM
Tag software: RF430FRL152H_NFC_Only_Project from RF430FRL152H Firmware (Rev. C)
Reader hardware: Samsung Galaxy S5
Reader OS: Android 5.0.1
Reader software: NFC TagInfo

Thank you.

If you can wait until early next week, we should have the working NDEF firmware uploaded to the RF430FRL152H product page.

It may not work on some of the older handsets, like Note 2, but it should with the latest and future ones.

Dear Kozitsky,

Thank you for the reply.

Would the firmware be uploaded to the following page?
www.ti.com/.../toolssoftware

Unfortunately this work is still "ongoing". I will notify when it is posted to www.ti.com.

Dear Kozitsky,

I wonder whether there is some hint regarding when the firmware would be updated. Since proof of concept (PoC) demo will be given at the end of August, so soon a decision needs be made whether a different option needs be explored or even a different chipset needs be considered.

Thank you.

I will contact you using E2E private conversation to further provide the help that you need.

Recently the example firmware supporting NFC using RF430FRL15xH has been completed and is available on ti.com at the following path:
www.ti.com/.../slac691