AnsweredAssumed Answered

M24SR02 problems with ReadBinary command

Question asked by turowski.adam.001 on May 18, 2017
Latest reply on May 18, 2017 by turowski.adam.001

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



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,