您好!
有时 MSP 会停止对 i2c 正确回复直到其复位、这会带来问题。
MSP 充当从器件。
当它开始出现行为错误时、MSP 会确认地址和接收到的数据、但之后会停止确认。 SCL 在它应该应答时卡在低电平。 SCL 保持低电平32ms、然后在处理 USCI_I2C_UCCLTOIFG 时重新启动总线
不过、在总线复位后、MSP 会保持错误行为、具有相同的模式。 仅当我完全复位 MSP 时、它才可以正常工作。
以下是我如何复位总线。
case USCI_I2C_UCCLTOIFG: //Timeout of the bus, reset i2c ucBusyDetectionCounter += 1; P1SEL1 &= ~(BIT6); // Generate NACK by releasing SDA, P1SEL1 &= ~(BIT7); // then SCL, via disconnecting from the I2C UCB0CTLW0 |= UCSWRST; // Reset UCB0CTLW0 |= UCMODE_3 | UCSYNC; // I2C mode, sync mode UCB0I2COA0 = SLAVE_ADDR | UCOAEN; // Own Address and enable UCB0CTLW0 &= ~UCSWRST; P1SEL1 |= (BIT6|BIT7); // Re-connect pins to I2C UCB0IE |= UCRXIE + UCSTPIE + UCCLTOIE; // Enable RX and TX interrupt break;
我想我有两个问题:
1:某些内部问题、导致其无法达到下一状态
2:未完成总线重新启动、无法纠正该错误。
来自该文档:
在以下情况下、由 eUSCI_B 扩展时钟:
1:内部移位寄存器正在等待数据、但 TXIFG 仍挂起
2:内部移位寄存器已满、但 RXIFG 仍挂起
3:仲裁丢失中断挂起 =>不太可能、它在与 USCI_I2C_UCCLTOIFG 相同的例程中处理、正常工作
4:UCSWACK 在 UCBxCTLW1中被选中并且 UCBxI2COA0确实导致了匹配=>不可能、 UCSWACK 未被激活
我目前正在探究 时钟拉伸的前两个原因。
我的问题:
-你看到了这样的问题吗? 是否有任何指针可以帮助我了解问题的根本原因?
-你觉得总线重置代码有任何问题吗?
注:
我很确定 i2c 主器件不是问题、当 MSP 复位时问题停止、与其他 i2c 从器件的通信正常。
谢谢。
塞德里克