[问答]

M24SR02 ReadBinary命令出现重复问题

问答对人有帮助，内容完整，我也想知道答案 0 大家好，在我的应用程序中，我正在使用100kHz时钟通过I2C与M24SR02芯片进行通信。我遇到的问题是使用ReadBinary命令。在应用程序中，我一遍又一遍地发出完全相同的ReadBinary命令 - 从偏移0x0097读取0x10字节。在M24SR02中，NDEF消息长度在NDEF文件的两个第一个字节中设置为0x00E5。在操作过程中，我没有改变NFC芯片的内容，只是一遍又一遍地阅读。大多数时候 ReadBinary 从M24SR02内存返回正确的值可以正常工作，但有时完全相同的命令会返回0x6A 0x86错误（'P1或P2值不正确'）。然后在该点之后重新发出相同的ReadBinary命令将永远返回相同的错误。如果在接收到错误后我将命令中的偏移量改为0x0000，则一切都恢复正常，ReadBinary再次起作用。我已经检查了带有范围的违规数据包的I2C流量，我可以看到发送到M24SR02的命令很好并且相同，无论是否导致错误被返回。说过我已经注意到了一些东西看起来像I2C时钟延长：I2C_SCL线拉低并在一段时间后再次开始翻转（大约200us，但它稍微变化）。它总是发生在发送字节之间的边界上。我认为这是由M24SR02完成的 - 我的MCU主驱动I2C总线使用硬件I2C模块和DMA发送数据包，因此极不可能耗尽数据发送这么长时间。我已经使用ExtendedReadBinary重复实验命令（我认为问题可能是由错误的NDEF消息长度引起的），但结果与ReadBinary命令相同。我还介绍了在发送C-APDU和开始读出R-APDU之间的一些延迟（从1ms到2ms范围），但问题仍然存在题： 1）M24SR02如何控制I2C上的数据流？它是否使用时钟拉伸？或者它可能不会确认其I2C地址？ 2）是否需要在命令或命令/回复之间引入延迟？略有不相关的一点。我注意到在应用笔记中提供的示例中，（扩展）ReadBinary命令中使用的PCB字段在0x02和0x03之间交替。在我的应用程序中，我总是发送0x02，M24SR02回复在0x02和0x03之间交替。对于我发送的每个命令，是否必须在0x02和0x03之间交替？亲切的问候，亚当以上来自于谷歌翻译以下为原文 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 0
2019-7-25 13:58:01　　评论淘帖0 邀请回答您可以邀请以下用户，快速回答问题 × wang21cj 该类别下有 44 个回答。邀请回答新星之火12138 该类别下有 41 个回答。邀请回答 chm5 该类别下有 39 个回答。邀请回答 hgimtk 该类别下有 33 个回答。邀请回答 HengDu 该类别下有 30 个回答。邀请回答 jghgfdssas 该类别下有 28 个回答。邀请回答 hwp0415229 该类别下有 28 个回答。邀请回答颜刚YanG 该类别下有 26 个回答。邀请回答可口可甜该类别下有 26 个回答。邀请回答 kingnet6688 该类别下有 26 个回答。邀请回答麻酱该类别下有 25 个回答。邀请回答 zyh34997 该类别下有 25 个回答。邀请回答柱子图宁该类别下有 25 个回答。邀请回答 jenny042 该类别下有 25 个回答。邀请回答 kingnet9999 该类别下有 25 个回答。邀请回答 andyfly7 该类别下有 25 个回答。邀请回答 heks 该类别下有 24 个回答。邀请回答 iyfhnvbn 该类别下有 24 个回答。邀请回答哈哈神神该类别下有 24 个回答。邀请回答成长的小师弟该类别下有 24 个回答。邀请回答举报秦伙茂相关推荐 • M24SR i2c通信协议功能是什么？ 1680 • M24Sr02读写长度出错 2236 • 请问ReadBinary（）到ExtendedReadBinary（）的差异是什么？ 1346 • M24SR ExtendedReadBinary命令无法找到 727 • 如何发送M24SR02 NDEF文件？ 1937 • 需要C代码用于M24SR02-Y 1110 • 怎么通过I2C与M24SR通信 1046 • 如何保护M24SR EEPROM读/写密码？ 1188 • 可以使用M24LR04E发送NDEF消息吗？ 986 • 请问M24SR-16的页面尺寸是多少？ 982 1个回答

答案对人有帮助，有参考价值 0 以下是我在原帖中谈到的成功和不成功访问的示例： ################################################# ReadBinary返回成功时访问（只打印出每个C-APDU和R-APDU的前8个字节及其总长度） ################################################# --- NDEF标签应用选择--- C-APDU：02 00 A4 04 00 07 D2 76 C-APDU：len 16 dec --- OK回复--- R-APDU：02 90 00 F1 09 00 00 00 R-APDU：len 5 dec --- NDEF Select --- C-APDU：02 00 A4 00 0C 02 00 01 C-APDU：len 10 dec --- OK响应--- R-APDU：03 90 00 2D 53 00 00 00 R-APDU：len 5 decC-APDU：02 00 B0 00 00 02 6B 7D C-APDU：len 8 dec --- OK响应NDEF消息长度数据--- R-APDU：02 00 E5 90 00 9F 3F 00 R-APDU：len 7 dec ---来自偏移0x0097的ExtendedReadBinary 0x10字节--- C-APDU：02 A2 B0 00 97 10 E1 E6 C-APDU：len 8 dec --- OK响应NDEF消息，数据0x1097，数据来自0x0097偏移量--- R-APDU：03 80 00 00 00 00 00 00 R-APDU：len 21 dec ################################################# ReadBinary返回错误代码时访问（只打印出每个C-APDU和R-APDU的前8个字节及其总长度） ################################################# --- NDEF标签应用选择--- C-APDU：02 00 A4 04 00 07 D2 76 C-APDU：len 16 dec --- OK回复--- R-APDU：02 90 00 F1 09 00 00 00 R-APDU：len 5 dec --- NDEF Select --- C-APDU：02 00 A4 00 0C 02 00 01 C-APDU：len 10 dec --- OK响应--- R-APDU：03 90 00 2D 53 00 00 00 R-APDU：len 5 dec ---来自偏移0x0000的ReadBinary NDEF 0x02字节（NDEF消息长度） C-APDU：02 00 B00 00 00 02 6B 7D C-APDU：len 8 dec --- OK响应NDEF消息长度数据--- R-APDU：02 00 E5 90 00 9F 3F 00 R-APDU：len 7 dec ---来自偏移0x0097的ExtendedReadBinary 0x10字节--- C-APDU：02 A2 B0 00 97 10 E1 E6 C-APDU：len 8 dec ---响应0x6A 0x86错误代码（'错误的P1或P2值'） R-APDU：03 6A 86 6B 33 FF FF FF R-APDU：len 21 dec ---从偏移量0x0097重新发出ExtendedReadBinary 0x10字节--- C-APDU：02 A2 B0 00 97 10 E1 E6 C-APDU：len 8 dec ---响应0x6A 0x86错误代码（'错误的P1或P2值'） R-APDU：03 6A 86 6B 33 FF FF FF R-APDU：从现在开始，在最后两条消息中，Len 21将永远重复以上来自于谷歌翻译以下为原文 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 76 C-APDU: len 16 dec--- OK response --- R-APDU: 02 90 00 F1 09 00 00 00 R-APDU: len 5 dec--- NDEF Select --- C-APDU: 02 00 A4 00 0C 02 00 01 C-APDU: len 10 dec--- OK response --- R-APDU: 03 90 00 2D 53 00 00 00 R-APDU: len 5 decC-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 00 R-APDU: len 7 dec--- ExtendedReadBinary 0x10 bytes from offset 0x0097 --- C-APDU: 02 A2 B0 00 97 10 E1 E6 C-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 00 R-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 76 C-APDU: len 16 dec--- OK response --- R-APDU: 02 90 00 F1 09 00 00 00 R-APDU: len 5 dec--- NDEF Select --- C-APDU: 02 00 A4 00 0C 02 00 01 C-APDU: len 10 dec--- OK response --- R-APDU: 03 90 00 2D 53 00 00 00 R-APDU: len 5 dec--- ReadBinary NDEF 0x02 bytes from offset 0x0000 (NDEF message lenght) 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 00 R-APDU: len 7 dec--- ExtendedReadBinary 0x10 bytes from offset 0x0097 --- C-APDU: 02 A2 B0 00 97 10 E1 E6 C-APDU: len 8 dec--- Response with 0x6A 0x86 error code ('Incorrect P1 or P2 value') R-APDU: 03 6A 86 6B 33 FF FF FF R-APDU: len 21 dec--- Reissue ExtendedReadBinary 0x10 bytes from offset 0x0097 --- C-APDU: 02 A2 B0 00 97 10 E1 E6 C-APDU: len 8 dec--- Response with 0x6A 0x86 error code ('Incorrect P1 or P2 value') R-APDU: 03 6A 86 6B 33 FF FF FF R-APDU: len 21 decfrom now on the last two messages repeat forever

2019-7-25 14:13:00 评论举报秦伙茂