This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
您好!
在我们的一个产品上、我们遇到了 SCL 有时卡在低电平的问题。 I2C 主设备是 cc3235、从设备是 msp430fr5738 (有2个其他 i2c 从设备、但我们已确认它们不是容纳线路的设备)。
我们看到 SCL 保持低电平的时间是无限的、并在重置 MSP 时释放。
调试非常困难、因为它每年仅影响约3%的器件。 幸运的是、在做另一个更改时、错误率增加到每周~5%、因此在仪器设备上重现仍然不容易、但可行。
我们还不确定根本原因、我们怀疑这可能是由 USCI37造成的、来自勘误表 https://www.ti.com/lit/er/slaz391ag/slaz391ag.pdf?ts = 1699367487148&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FMSP430FR5738
我们的问题:
-您能确认我们应该通过检查 UCB0STATW 和(UCSCLLOW | UCBBUSY)来检测 MSP 是否正在保留 SCL 吗?
-有没有简单的方法将 MSP 置于这种错误模式? 这将帮助我们确认它是我们发现的问题、并使主代码更加稳健。
-在 MSP 上正确复位总线的正确方法是什么? 我们计划使用以下代码。
UCB0CTLW0 |= UCSWRST; // Software reset enabled UCB0IE &= ~(UCRXIE | UCSTPIE); // Disable RX and TX interrupt UCB0IFG = 0; //Clear pending interrupts for (int i = 0; i < 200; i++) // Wait 200ms { __delay_cycles(8000); // Wait 1ms, ~1ms because MCLK = 8MHz } UCB0CTLW0 &= ~UCSWRST; // clear reset register UCB0IE |= UCRXIE + UCSTPIE; // Enable RX and TX interrupt
关于我们的系统的一些信息:
时钟= 8MHz
I2C 频率100kHz
我希望它足够清楚。
谢谢。
塞德里克
我成功地完成了这个序列:
case UCIV__UCCLTOIFG: // Bus timeout r = UCB1IE; // Save current IE bits P4SEL0 &= ~(BIT4); // Generate NACK by releasing SDA, P4SEL0 &= ~(BIT3); // then SCL, via disconnecting from the I2C UCB1CTLW0 |= UCSWRST; // Reset UCB1CTLW0 &= ~UCSWRST; P4SEL0 |= (BIT3|BIT4); // Re-connect pins to I2C UCB1IE = r; // Put IE back break;
上下文:我有一个实验从站、其中包含一个"挂起总线、请"主站可以发送的请求。 从机通过忽略它看到的下一个 UCTXIFG0 (读取请求)来实现此操作。 该代码是对最终 UCCLTO 超时的响应。
我粘贴的上面的代码在 FR2355上运行;我想我在其他几个平台(都使用 EUSCI)上进行了尝试。
谢谢!
我们通过在适当的时间停用 TX 和 RX 中断、设法使总线在 SCL 为低电平时挂起。 并像您那样使用 UCCLTO 对其进行复位。