M24SR64 with NDEF File Length in 36 bytes

[wenkai]

Posted on January 19, 2015 at 06:55

Dear Sirs:

We are using M24SR64. Now we met a problem with NDEF File Length in 36 bytes. Problem: 1. If the NDEF File Length is 36 bytes, it can not be a successful data in Android OS or NXP TagInfo app or NFC TagInfo app. Only the app of ST ''M24SR Demo'' can show the payload we wrote. 2. If the NDEF File Length is 35 or 37 bytes, it is a successful Tag data. At first, we used I2C to write the data and we met this strange behavior. Then we used the M24SR Demo app to test it, it also fail in 36 bytes (35 or 37 are OK). Here is a simple way to reproduce the stange behavior: - Tested in Samsung S3 (Android 4.3, may PN544) and Nexus7 generation1 (Android 4.4.3, may 65N04) - Use the app M24SR Demo (download from Google Play)   -> Choose the NDEF editor and TEXT mode   -> Key in the data (payload)         1234567890         1234567890         12345678        (28 Bytes)        or         1234567890         1234567890         1234567890    (30 Bytes)        => Above 2 are successful tag data (Record #1: TEXT record)   -> Key in the data (payload)         1234567890         1234567890         123456789       (29 Bytes)        => The Android will not response the data is a Tag data        => NXP TagInfo or NFC TagInfo app show ''No NFC data set available''        => Only M24SR Demo will show the payload we wrote.   -> What I said 36 bytes is       In NDEF file content       00 24 (Total 36 bytes)       D1 01 20 54 02 7A 68 (7 bytes)       31 32 33 34 35 36 37 38 39 30       31 32 33 34 35 36 37 38 39 30       31 32 33 34 35 36 37 38 39             (29 bytes as 12345678901234567890123456789) We do not know the reason in this length. At first we thought we had a bug in our I2C code. Then we double checked by app M24SR Demo, it has the same stange behavior. Does anybody meet the similar problem before? Or please inform or correct where is the bug we have. Thanks for your help! Thanks! Wen-Kai

[wenkai]

Posted on January 22, 2015 at 11:33

Does anybody meet the situation or reproduce the behavior?

We still blocked in this problem.... and We are not sure if different length happens. Any idea or feedback is wonderful for us. Thansk for your help! Wen-Kai

[na]

Posted on February 16, 2015 at 08:51

Hello,

Did you find the answer (and fix to this)? I have a similar problem, but during readout (over I2C), where I read the length (and it says 0x14). But if I try to read the 0x14 data from the chip, M24SR 2KB, it will not work. I can read out data from 0 to 0x10, but after that it fails (0x11 will not work). I don't get an answer over the I2C, after I send 0xAC I don't get any answer back (no ACK or anything from M24SR). But If I try to read (for example) 0x10 it will work, (I will get the first characters of ''Hello world''). I follow the example in Appendix C, in app note AN4433. Is it a bug in the M24SR, maybe just a batch that is strange? It also feels quite strange that I should be the only one having problem from an example in an app note.... That's why I think this is so strange! Br Nicklas

[wenkai · Accepted solution]

Posted on March 05, 2015 at 04:24

Hi, Nicklas:

Sorry for reply lately. (And I really appreciate for your discussion.) Do you overcome the situation? In I2C method, I ever meet M24SR did not ''ACK''. 0xAC + xx + .... + xx: OK 0xAD -> NACK In the beginning of I2C communication, I mean step by step according AN4433, I did not find this behavior. While the data length gets longer, it happens About this situation, i add a delay. 0xAC + xx + .... + xx: OK DELAY 0xAD -> ACK The time of delay: 100us: Fail 200us: OK 500us: OK 1ms: OK At last i use 200us in my FW. Hope it is useful for you. (p.s. I did not find any recommend from ST document about ''Delay''. Thus, I did not sure if it is a correct way or not.) (If you saw the recommend in any document, please tell me) BTW, I did not really solve our problem as the subject. We only can avoid to use the specific byte now. We are not sure other bytes if OK or not. Hope you and anybody can give us more information! Thanks for your discussion. Wen-Kai

[na]

Posted on March 12, 2015 at 20:56

Hi Wen-Kai,

Thanks for the hlep, your suggestion worked! I added a delay between telling M24SR to read the NDEF message and before starting to read it back (between the I2C stop-bit and I2C start bit. 50us works, but 10us doesn't work. I haven't digged into the spec, to try to find an answer to it. Maybe I find soem strength to do that later... But once again, THANKS for help! /Nicklas