Help with writing NDEF message via i2c for M24SR

[jyi1]

Posted on October 06, 2014 at 17:34

Hello,

I'm having trouble writing an NDEF message to the M24SR (with 8KB EEPROM) via i2c.I am able to correctly write an NDEF Text Message via the official M24SR Android app.I am able to correctly read the NDEF File via i2c.However, when I try to write ''hello world'' via i2c to the NDEF file, the M24SR Android app reads an empty NDEF.Here is the i2c sequence of what I've tried:            (kill RF)

AC 52

            (select NFC)

AC 02 00 A4 00 0C 02 E1 03 D2 AF

            (5 reply bytes read)

02 90 00 F1 09

            (select CC)

AC 03 00 A4 00 0C 02 E1 03 D2 AF

            (5 reply bytes read)

03 90 00 2D 53

            (read CC length)

AC 02 00 B0 00 00 02 6B 7D

            (7 reply bytes read)

02 00 0F 90 00 44 45

            (read CC file)

AC 03 00 B0 00 00 0F A5 A2

            (20 read  bytes read)

03 00 0F 20 00 F6 00 F6 00 F6 04 06 00 01 20 00 00 00 90 00 A9 F3

            (select NDEF file)

AC 02 00 A4 00 0C 02 00 01 3E FD

            (5 reply bytes read)

02 90 00 F1 09

            (erase NDEF length)

AC 03 00 D6 00 00 02 00 00 6B 37

            (5 reply bytes read)

03 90 00 2D 53

            (update binary NDEF with ''hello world'')

AC 02 00 D6 00 02 0B 68 65 6C 6C 6F 20 77 6F 72 6C 64 2F FC

            (5 reply bytes read)

02 90 00 F1 09

            (update binary of NDEF with length of ''hello world'' = 11 = 0x0B)

AC 03 00 D6 00 00 02 00 0B

            (5 reply bytes read)

03 90 00 2D 53

            (deselect)

AC C2 E0 B4

            (3 reply bytes read)

C2 E0 B4

Again, after this sequence, when the NDEF is read via i2c, ''hello world'' is found, but the Android app sees an empty NDEF. I've tried appending the same ''header'' found when reading the Android-written NDEF via i2c, however the replies do not have a correct CRC.Can anyone please help clarify the implementation and point me in the right direction?Thanks in advance,Jon #android #ndef #m24sr

[Anais GALLIGANI]

Posted on October 21, 2014 at 14:34

Hi Jon,

Concerning your issue, this is linked to the format of

the  NFC Data Exchange Format (NDEF)  and the NFC forum Text Record type  specification (NFCForum-TS-RTD_Text_1.0).

Their format are explained on the NFC Forum web site. 

If the NDEF message is not correctly written, the Android system can’t determine which kind of NDEF message is stored in the memory.

Indeed on

            (update binary NDEF with ''hello world'')

AC 02 00 D6 00 02 0B 68 6C 65 6C 6F 20 77 6F 72 6C 64 2F FC

The NDEF header is missing.

NDEF header:

Record layout :

            First Byte: (0xD1)

                        MB = 1

                        ME = 1b

                        CF = 0b

                        SR = 1b

                        IL  = 0b  not present

                        TNF = 001b (wellknown type)

              Second Byte:

                        Type length = 0x01

              Third Byte:

                        Payload Length : 0x0E - 14 bytes

              Fourth Byte:

                        Type = 0x54 : “Tâ€�

              Payload : 02 65 6E 68 65 6C 6C 6F 20 77 6F 72 6C 64

                                             h   e   l   l    o        w  o   r    l    d

           Payload according to NFCForum TS RTD text document  (the payload detailed previously) :

            1 Byte (0x02) : Status byte 0x02 ( UTF-8;b6:RFU; Length of IANA Code : 2 bytes)

            2 bytes (IANA Code) : 0x65 0x6E : “enâ€�

In conclusion on Update Binary command the Payload to write is :

AC 02 00 D6 00 02 12

D1 01 0E 54 02 65 6E 68 65 6C 6C 6F 20 77 6F 72 6C 64

CRC1 CRC2

And then update binary size :

NDEF Length must be set to 18 bytes

AC 03 00 D6 00 00 02 00

12

I hope this is helping you, Best Regards, Have a nice day, ST NFC/RFID Dynamic tag support

[jyi1]

Posted on November 03, 2014 at 21:54

Hello ST support,

Thank you for your reply.I finally had time to try your suggestion, however I am still unable to get the Android app to correctly read the NDEF message written by i2c.I added the NDEF header as hinted. The original message '

Abc

' was written via the Android app. I am trying to update the message to contain '

hello world

' via i2cHere are the commands/replies that I am sending/receiving via i2c.

3:08:34 PM   

kill RF

[S_][W_][02][AC][52][P_] 

3:08:34 PM   

selectNFC

[S_][W_][11][AC][02][00][A4][04][00][07][D2][76][00][00][85][01][01][00][35][C0][P_] 

3:08:35 PM   

5 reply bytes read[S_][02][90][00][F1][09][P_]

3:08:35 PM   

select cc

[S_][W_][0B][AC][03][00][A4][00][0C][02][E1][03][D2][AF][P_] 

3:08:35 PM   

5 reply bytes read[S_][03][90][00][2D][53][P_]

3:08:35 PM   

read cc length

[S_][W_][09][AC][02][00][B0][00][00][02][6B][7D][P_] 

3:08:35 PM   

7 reply bytes read[S_][02][00][0F][90][00][44][45][P_]

3:09:58 PM   

read cc file

[S_][W_][09][AC][03][00][B0][00][00][0F][A5][A2][P_] 

3:10:03 PM   

20 reply bytes read[S_][03][00][0F][20][00][F6][00][F6][04][06][00][01][20][00][00][00][90][00][A9][F3][P_]

3:10:04 PM   

select NDEF

[S_][W_][0B][AC][02][00][A4][00][0C][02][00][01][3E][FD][P_] 

3:10:04 PM   

5 reply bytes read[S_][02][90][00][F1][09][P_]

3:13:26 PM   

erase NDEF length

[S_][W_][0B][AC][03][00][D6][00][00][02][00][00][6B][37][P_] 

3:13:37 PM   

5 reply bytes read[S_][03][90][00][2D][53][P_]

3:13:56 PM   

update binary with 'hello world'

[S_][W_][1B][AC][02][00][D6][00][02][12][D1][01][0E][54][02][65][6E][68][65][6C][6C][6F][20][77][6F][72][6C][64][EC][5C][P_] 

3:14:15 PM   

5 reply bytes read[S_][F2][02][0A][72][FF][P_]

  **** strangely shifted

3:15:17 PM   

update ndef length

[S_][W_][0B][AC][03][00][D6][00][00][02][00][12][F8][04][P_] 

3:15:21 PM   

5 reply bytes read[S_][03][90][00][2D][53][P_]

3:18:21 PM   

deselect

[S_][W_][04][AC][C2][E0][B4][P_] 

3:18:22 PM   

3 reply bytes read[S_][C2][E0][B4][P_]The documentation claims that 5 bytes should be read for the UpdateBinary reply, however the CRC does not match (but it is correct if the 5th byte is omitted).After the commands for the ReadBinary procedure are sent, the output is 

[S_][02][D1][01][06][54][02][65][6E][41][62][63][6C][6F][20][77][6F][72][6C][64][90][00][03][11][P_]

The data in ASCII ends up as'

Abclo world

'which should not be the case since the offset for the UpdateBinary command is 02 (beginning of the message, past the bytes designated for the NDEF message length).Can you please shed some light on this issue?Thanks again,Jon

[John TRAN]

Posted on November 11, 2014 at 20:23

Hi Jon,

Your NDEF ''text'' message is missing the NDEF header. It should be as below. D1010E5402656E68656C6C6F20776F726C64 You might want to check out the M24SRxx cookbook at www.nfcdynamictag.com Best regards, John

[NFC/RFID Customer support · Accepted solution]

Posted on January 05, 2015 at 16:22

Hello,

the problem comes from the lines highlighted in your I2C sequence :

3:14:15 PM

5 reply bytes read [S_][F2][02][0A][72][FF][P_]

**** strangely shifted

This asnwer from the Tag is not so strange : this is a EXTENTION WINDOW request. When a Update binary is requested AND time to process this prog is higher than expected time, an extention time is sent by the tag ... prog is not yet processed until the reader will send back an agreement for this extention time request.

update binary with 'hello world'

[S_][W_][1B][AC][02][00][D6][00][02][12][D1][01][0E][54][02][65][6E][68][65][6C][6C][6F][20][77][6F][72][6C][64][EC][5C][P_] Will take more than 10ms time, so a FWT is requested. The good process should be :

update binary with 'hello world'

[S_][W_][1B][AC][02][00][D6][00][02][12][D1][01][0E][54][02][65][6E][68][65][6C][6C][6F][20][77][6F][72][6C][64][EC][5C][P_] 

4 reply bytes read

[S_][F2][02][0A][72][FF][P_]

= where F2=FWTX Request / 02=extented time requested / 0A72=CRC

Agrement for FWTX and start prog

[S_][W_][05][AC][F2][02][0A][72][P_]

5 reply bytes read

[S_][02][90][00][F1][09][P_] --> Here the prog has been done successfully Regards,

[jyi1]

Posted on January 13, 2015 at 20:09

Hello pascalfromst,

Thank you very much for the suggestion. This has solve my issue with using the UpdateBinary command via i2c.After responding to the extension request, I had a little problem with reading the entire message, but that was just a result of an incorrect header.Thanks again everyone for the support.-Jon