这让我感到非常意外,我查看了数据表,用户指南,勘误表,不知道我做错了什么,也不知道如何处理。
一些背景:
此I2C实施使用轮询(请参阅SLAZ440H中的Issue USCI29)
不使用重复启动条件(参见SLAZ440H中的问题USCI35)
总线速度为100KHz,带有4.7K上拉电阻,取消了WFP 1.6 跳线。 我正在使用MSP430G2系列,版本1.5 的启动板。
此应用程序的目的是在INTB (连接到WFP 2.2)中断时,从MCP2.3018万上的寄存器INTCAPB读取信息。 P2中断设置一个软件标志,这将触发写入以设置寄存器地址,然后从寄存器INTCAPB中进行后续读取。
是的,我已经阅读 了MSP430MCU (SLAA734)上常见eUSCI和USCI串行通信问题的解决方案 以及器件的I2C示例代码。 我尝试了TI I2C实现,I2C中断导致调用TRAPINT,从而捕获程序计数器。
现在谈谈症状:
正如您从逻辑分析器输出中看到的那样,开始和停止条件在I2C规范范围内并得到确认。 在最近的写入事务结束之前,它们一直保持不变。 从属设备和逻辑分析仪都无法识别以下读取事务。
在停止条件后立即设置断点似乎可以通过在停止和启动条件之间留下巨大的间隙来解决问题,但我无法解决该问题。 在调试时,我发现这是一个令人不快的代码:
如果(状态和I2C_REG_SET){ //如果为以后的读取操作设置寄存器计数器
如果(状态和键盘读取){ //如果读取键盘的状态
// MCP2.3018万的地址将已加载
如果(UCB0TXBUF == INTCAPB){ //如果发送的最后一个字节是INTCAPB
//控制字节已成功发送
//现在可以发送停止条件,等待4.7us,然后作为接收器发送启动条件
状态&=~I2C_REG_SET; //重置I2C_REG_SET位,计数器已成功发送
UCB0CTL1 || UCTXSTP; //发送停止条件
While (UCB0CTL1和UCTXSTP); //确保停止条件已完成,然后再继续
__DELAY周期(Tbuf); //延迟4.7us (1/SMCLK * 75)
UCB0CTL1 &=~UCTR; //成为接收器
UCB0CTL1 || UCTXSTT; //发送开始条件
} 否则{ //否则:
UCB0TXBUF = INTCAPB; //发送INTCAPB作为注册号字节
I2C_I = INTCAPB; //更新寄存器迭代器的主副本
__DELAY周期(Tbuf); //延迟4.7us (1/SMCLK * 75)
}
}
}
