[问答]

I2C SCL有时在接收阶段变为低电平，无法恢复

5094

问答对人有帮助，内容完整，我也想知道答案 0 嗨，我的问题是：我在PIC32 MZ2048 ECM144上使用Hydio1.07.01。我从外部RTC读取时间通过主I2C使用标准的静态驱动器（速度= 100kHz从60MHz外围总线时钟）。所有的工作都在几分钟内完成（我每秒读取时间），但是随机接收阶段（7字节）在收到的一个字节的ACK脉冲之后停止，显然是因为没有产生发送ACK序列中断（在调试中，每次接收I2C主控器时，我切换输出引脚值）。中断，以查看是否产生了所有中断。我现在看到的是ACK脉冲被发送，但是发送ACK序列中断没有产生，SCL不再高。我试图去初始化和重新初始化I2C模块，但是恢复这种情况的唯一方法是软件重置。在重新初始化之后，我还检查了中断标志的状态，启用了主和总线冲突中断，因此我不知道发生什么情况或如何在没有软复位的情况下恢复这种情况。我附上示波器跟踪的图片：SDA＝信号1，SCL＝信号2，Inte。Rrutt切换=信号3。提前感谢。以上来自于百度翻译以下为原文 Hi, My problem is the following: I'm working with HARMony 1.07.01 on a PIC32MZ2048ECM144. I read time from an external RTC via a master I2C using the standard static driver (speed = 100kHz from a 60MHz peripheral bus clock). All works fine for some minutes (I read time every second), but randomly the receive phase (7 bytes) stops after the ack impulse of one of the received bytes, apparently because the Send ACK sequence interrupt is not generated (In debug, I toggle an output pin value each time I receive a I2C Master interrupt, in order to see if all interrupts are generated). What I see at this moment is that the ACK impulse is sent, but the Send ACK sequence interrupt is not generated and the SCL never goes high anymore. I tried to deinitialize and re-initialize the I2C module, but the only way to recover the situation is a software reset. I also checked the status of interrupt flags after re-initialization, and master and bus collision interrupts are enabled, so I have no idea of what happens or how to recover this situation without a softrare reset. I attached a picture of the oscilloscope trace: SDA = signal 1, SCL = signal 2, Interrupt toggle = signal 3. Thanks in advance. Attached Image(s) 0
2019-7-10 16:12:40　　评论淘帖0 邀请回答您可以邀请以下用户，快速回答问题 × qun333 该类别下有 57 个回答。邀请回答技术发广告该类别下有 56 个回答。邀请回答 caoguiqun 该类别下有 56 个回答。邀请回答 psw30 该类别下有 44 个回答。邀请回答伊丹姿子该类别下有 41 个回答。邀请回答 uwufwjrw 该类别下有 39 个回答。邀请回答 hetao1111 该类别下有 38 个回答。邀请回答 lc123617 该类别下有 35 个回答。邀请回答欧阳大大该类别下有 32 个回答。邀请回答作死不止该类别下有 31 个回答。邀请回答 asd010 该类别下有 31 个回答。邀请回答 wy8719 该类别下有 29 个回答。邀请回答 60user92 该类别下有 29 个回答。邀请回答 ju978779 该类别下有 28 个回答。邀请回答嘻嘻爱哈哈该类别下有 28 个回答。邀请回答 haikitty 该类别下有 28 个回答。邀请回答 xiuzhen122 该类别下有 27 个回答。邀请回答 pol666 该类别下有 27 个回答。邀请回答 ueywyrsdfs 该类别下有 26 个回答。邀请回答 lhly23 该类别下有 25 个回答。邀请回答举报马雁翔相关推荐 • STM32的I2C接口死锁在BUSY状态无法恢复怎么解决？ 1288 • 请问微控制器在连续接收数据时用作I2C从机时为什么有时钟拉伸？ 1548 • I2C的 ip核总线中保持时间是不是决定了SDA数据在SCL低电平的哪个时候开始变化的 5590 • 如何去解决I2C SCL无时钟切换的问题呢 209 • I2C SCL信号一直保持High 6141 • AD9984 I2C总线的ACK始终为高电平（NACK）是为什么？ 300 • 关于I2C停止信号函数的延时问题 99 • I2C IP核Core I2C怎么样？ 3792 • 如何解决i2c设备主机与从机直接无法正常数据交互的问题 17471 • stm8s I2C模块死机，如何恢复 9115 1个回答

答案对人有帮助，有参考价值 0 您的跟踪显示了8个时钟的突发，它们之间只有一个时钟。由于您没有显示传输的第一个时钟，因此我不能确定哪些时钟用于数据，哪些时钟用于ACK。如果用箭头和标签对跟踪进行注释会有帮助。如果8条紧挨在一起的是时钟，而孤立的一条是ACK，那么有两件事情需要注意。由于某种原因，最后一个时钟比以前的任何一个都有更长的延迟（从突发到那个）。是什么引起的？你知道你的RTC是“时钟延长”吗？下一步，如果最后一个时钟是ACK时钟，那么RTC没有激活时钟。数据引脚在前沿上高，这意味着“不ACK”。I2C容易锁定。主要问题是CPU在传输过程中被重置（您没有重置），但是外带消息是锁定的I2C总线可能需要“超时”。初始化应该将管脚编程为GPIO，然后在SCL管脚上手动生成至少8个“虚拟时钟”，以确保从机不在传输过程中。您应该尝试这个作为您尝试恢复的一部分。为了发现从设备是否引起问题并驱动时钟引脚，请将电阻器与SCL线串联，每端都有大的值上拉。当不同的设备驱动线路时，这将给出不同的电压电平，让您在示波器轨迹中随时看到哪个设备是活动的。以上来自于百度翻译以下为原文 Your trace shows bursts of 8 clocks with a single clock between them. Since you didn't show the first clock of the transfer, I can't tell which clocks are for the data and which one is for the ACK. It would help if you annotated the trace with arrows and labels. If the 8 ones close together are the clock and the isolated one is the ACK, then there are two things to notice. For some reason the last single clock had a far longer delay (from the burst to that one) than any of the previous ones. What caused that? Do you know if your RTC is "clock stretching"? Next, if that last clock is the ACK clock, then the RTC didn't ACK that clock. The Data pin goes high on the leading edge, which means "no ack". I2C is prone to locking up. The main problem is having the CPU reset in the middle of a transfer (which you're not having), but the take-away message is that a locked up I2C bus may need to be "clocked out". Initialisation should program the pins as GPIOs and then manually generate at least 8 "dummy clocks" on the SCL pin to make sure the slave isn't in the middle of a transfer. You should try this as part of your attempted recovery. In order to find if the slave is causing a problem and driving the clock pin, put a resistor in series with the SCL line with large value pullups at each end. That will give different voltage levels when the different devices are driving the line, letting you see which one is active at any one time in your oscilloscope trace. Tom

2019-7-10 16:20:20 评论举报王晗