完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
敬启者:
我们正在使用M24SR64。 现在我们遇到了36字节的NDEF文件长度问题。 问题: 1.如果NDEF文件长度为36个字节,则它不能是Android OS或NXP TagInfo应用程序或NFC TagInfo应用程序中的成功数据。 只有ST''M24SR Demo'的应用程序才能显示我们编写的有效载荷。 2.如果NDEF文件长度为35或37字节,则它是成功的标签数据。 起初,我们使用I2C来编写数据,我们遇到了这种奇怪的行为。 然后我们使用M24SR Demo应用程序来测试它,它也失败了36个字节(35或37都可以)。 这是一种重现stange行为的简单方法: - 测试三星S3(Android 4.3,可能是PN544)和Nexus7 generation1(Android 4.4.3,可能是65N04) - 使用应用程序M24SR演示(从Google Play下载) - >选择NDEF编辑器和TEXT模式 - >键入数据(有效载荷) 1234567890 1234567890 12345678(28字节) 要么 1234567890 1234567890 1234567890(30字节) => 2以上是成功的标签数据(记录#1:TEXT记录) - >键入数据(有效载荷) 1234567890 1234567890 123456789(29字节) => Android不会响应数据是Tag数据 =>恩智浦TagInfo或NFC TagInfo应用程序显示''没有可用的NFC数据集'' =>只有M24SR Demo才会显示我们编写的有效负载。 - >我说的是36个字节 在NDEF文件内容中 00 24(总共36个字节) D1 01 20 54 02 7A 68(7字节) 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字节为12345678901234567890123456789) 我们不知道这个长度的原因。 起初我们认为我们的I2C代码中存在错误。 然后我们通过应用程序M24SR Demo进行双重检查,它具有相同的stange行为。 以前有人遇到过类似的问题吗? 或者请告知或纠正我们所遇到的错误。 谢谢你的帮助! 谢谢! 文启 以上来自于谷歌翻译 以下为原文 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 |
|
相关推荐
4个回答
|
|
有人遇到这种情况或重现这种行为吗?
我们仍然阻止了这个问题.... 我们不确定是否会发生不同的长度。 任何想法或反馈对我们来说都很棒。 Thansk的帮助! 文启 以上来自于谷歌翻译 以下为原文 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 |
|
|
|
你好,
你找到了答案(并解决了这个问题)吗? 我有一个类似的问题,但在读出期间(通过I2C),我读取长度(并说它是0x14)。但如果我尝试从芯片读取0x14数据,M24SR 2KB,它将无法正常工作。我可以读出0到0x10之间的数据,但之后它会失败(0x11将无效)。 我发送0xAC后没有得到I2C的答案我没有得到任何回复(没有来自M24SR的ACK或任何东西)。但是,如果我尝试读取(例如)0x10它将起作用,(我将获得''Hello world''的第一个字符)。 我按照应用笔记AN4433中的附录C中的示例进行操作。 它是M24SR中的一个错误,也许只是一个奇怪的批次? 我觉得应该是应用笔记中唯一一个有问题的人,这也很奇怪......这就是为什么我觉得这很奇怪! BR 尼克拉斯 以上来自于谷歌翻译 以下为原文 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 |
|
|
|
嗨,尼克拉斯:
很抱歉最近回复。 (我非常感谢您的讨论。) 你克服了这种情况吗? 在I2C方法中,我曾经遇到过M24SR没有''确认''。 0xAC + xx + .... + xx:好的 0xAD - > NACK 在I2C通信的开始,我的意思是按照AN4433一步一步, 我没有发现这种行为。 当数据长度变长时,就会发生这种情况 关于这种情况,我加了一个延迟。 0xAC + xx + .... + xx:好的 延迟 0xAD - > ACK 延迟时间: 100us:失败 200us:好的 500us:好的 1ms:好的 最后我在我的FW中使用了200us。 希望它对你有用。 (p.s.我没有从ST文件中找到关于''延迟''的任何推荐。 因此,我不确定这是否是正确的方法。) (如果您在任何文档中看到推荐,请告诉我) 顺便说一句,我并没有真正解决我们作为主题的问题。 我们现在只能避免使用特定的字节。 如果可以,我们不确定其他字节。 希望您和任何人都能给我们更多信息! 谢谢你的讨论。 文启 以上来自于谷歌翻译 以下为原文 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 |
|
|
|
嗨文凯,
感谢hlep,你的建议奏效了! 我在告诉M24SR读取NDEF消息之前和开始读回之前(在I2C停止位和I2C起始位之间)之间加了一段延迟。 50us工作,但10us不起作用。 我没有深入研究规范,试图找到答案。也许我发现soem的力量以后再做... 但是再次感谢你的帮助! /尼克拉斯 以上来自于谷歌翻译 以下为原文 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 |
|
|
|
只有小组成员才能发言,加入小组>>
请教:在使用UDE STK时,单片机使用SPC560D30L1,在配置文件怎么设置或选择?里面只有SPC560D40的选项
2783 浏览 1 评论
3252 浏览 1 评论
请问是否有通过UART连接的两个微处理器之间实现双向值交换的方法?
1826 浏览 1 评论
3672 浏览 6 评论
6065 浏览 21 评论
1349浏览 4评论
对H747I-DISCO写程序时将CN2的st-link复用为usart1,再次烧录时无法检测到stlink怎么解决?
373浏览 2评论
STM32G474RE芯片只是串口发个数据就发烫严重是怎么回事?
468浏览 2评论
STM32处理增量式编码器Z信号如何判断中断是正转的还是反向转的?
292浏览 2评论
使用STM32F407VET6的USB2.0功能,发现ctl后芯片无数据返回,是什么原因可能导致的呢?
217浏览 2评论
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2025-1-13 02:19 , Processed in 0.994778 second(s), Total 50, Slave 45 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191 工商网监 湘ICP备2023018690号