M24SR02 problems with ReadBinary command

[adam239955_st]

Posted on May 18, 2017 at 11:28

Hi all,

In my application I am talking to M24SR02 chip over I2C with 100kHz clock. The problem I am having is with ReadBinary command. In the application I issue exactly the same ReadBinary command over and over again - reading 0x10 bytes from offset 0x0097. NDEF message length is set to 0x00E5 in two first bytes of NDEF file in M24SR02. During operation I am not changing the contents of NFC chip, just read it over and over again. Most of the time

ReadBinary

works fine returning correct values from M24SR02 memory, however sometimes exactly the same command returns 0x6A 0x86 error ('Incorrect P1 or P2 values'). Then after that point re-issuing the same ReadBinary command returns the same error forever. If after receiving and error I change the offset in command to say 0x0000, then everything goes back to normal and ReadBinary works again. I've checked I2C traffic of the offending packet with the scope and I can see that the command sent to M24SR02 is fine and the same regardless if it results in the error being returned or not.. Having said that I've noticed something that looks like I2C clock stretching: I2C_SCL line gets pulled low and starts toggling again after some time (approx. 200us, but it varies a little bit). It always happens on the boundary between sent bytes. I presume that this is done by M24SR02 - my MCU being master driving I2C bus uses hardware I2C block and DMA to send the packet, so it is extremely unlikely to run out of data to send for so long.

I've repeated experiment using ExtendedReadBinary command (I thought that the problem may have been caused by wrong NDEF message length), but the result was the same as with ReadBinary command. I've also introduced some delays (from 1ms - 2ms range)  between sending C-APDU and starting to read out R-APDU, but the problem is still there

Question:

1) How M24SR02 controls data flow on I2C? Is it using clock stretching? Or maybe it doesn't acknowledge its I2C address?

2) Is there a need to introduce delays between commands or command/replies?

Slightly unrelated bit. I've noticed that in examples provided in application notes PCB field used in (Extended)ReadBinary command alternates between 0x02 and 0x03. In my application I always send 0x02, M24SR02 replies alternate between 0x02 and 0x03. Is it obligatory to alternate between 0x02 and 0x03 for each command I sent?

Kind regards,

Adam

[adam239955_st · Accepted solution]

Posted on May 18, 2017 at 12:13

Here is an example of successful and unsuccessful accesses I was talking about in the original post:

#################################################

Access when ReadBinary returns is successful(only first 8 bytes of each C-APDU and R-APDU and their total lengths are printed out)################################################# --- NDEF Tag Application Select ---C-APDU: 02 00 A4 04 00 07 D2 76C-APDU: len 16 dec

--- OK response ---

R-APDU: 02 90 00 F1 09 00 00 00R-APDU: len 5 dec

--- NDEF Select ---

C-APDU: 02 00 A4 00 0C 02 00 01C-APDU: len 10 dec

--- OK response ---

R-APDU: 03 90 00 2D 53 00 00 00R-APDU: len 5 dec

C-APDU: 02 00 B0 00 00 02 6B 7D

C-APDU: len 8 dec

--- OK response with NDEF message lenght data ---

R-APDU: 02 00 E5 90 00 9F 3F 00R-APDU: len 7 dec

--- ExtendedReadBinary 0x10 bytes from offset 0x0097 ---

C-APDU: 02 A2 B0 00 97 10 E1 E6C-APDU: len 8 dec

--- OK response with NDEF message with data 0x10 bytes of data from 0x0097 offset ---

R-APDU: 03 80 00 00 00 00 00 00R-APDU: len 21 dec#################################################Access when ReadBinary returns error code(only first 8 bytes of each C-APDU and R-APDU and their total lengths are printed out)################################################# --- NDEF Tag Application Select ---C-APDU: 02 00 A4 04 00 07 D2 76C-APDU: len 16 dec

--- OK response ---

R-APDU: 02 90 00 F1 09 00 00 00R-APDU: len 5 dec

--- NDEF Select ---

C-APDU: 02 00 A4 00 0C 02 00 01C-APDU: len 10 dec

--- OK response ---

R-APDU: 03 90 00 2D 53 00 00 00R-APDU: len 5 dec

--- ReadBinary NDEF 0x02 bytes from offset 0x0000 (NDEF message lenght)

C-APDU: 02 00 B0 00 00 02 6B 7DC-APDU: len 8 dec

--- OK response with NDEF message lenght data ---

R-APDU: 02 00 E5 90 00 9F 3F 00R-APDU: len 7 dec

--- ExtendedReadBinary 0x10 bytes from offset 0x0097 ---

C-APDU: 02 A2 B0 00 97 10 E1 E6C-APDU: len 8 dec

--- Response with 0x6A 0x86 error code ('Incorrect P1 or P2 value')

R-APDU: 03 6A 86 6B 33 FF FF FFR-APDU: len 21 dec

--- Reissue ExtendedReadBinary 0x10 bytes from offset 0x0097 ---

C-APDU: 02 A2 B0 00 97 10 E1 E6C-APDU: len 8 dec

--- Response with 0x6A 0x86 error code ('Incorrect P1 or P2 value')

R-APDU: 03 6A 86 6B 33 FF FF FFR-APDU: len 21 dec

from now on the last two messages repeat forever