[参考译文] RTOS/TM4C123GH6PM：运行 i2ctmp006_EK 示例、当访问未知地址时、i2c 时钟被拉低

您好 Lisa、

 我同意、如果主器件被否定、应根据下面显示的传输流程图发出停止和终止命令。 正如您看到的、当发生错误时、CPU 应该向 I2CMCS 寄存器写入一个如"--0-100"中所示的停止位。 但是、流程图是在软件中实现的。 我认为 TI-RTOS 在发生错误时采取的终止事务的方法可能略有不同。 我不熟悉 TI-RTOS 如何处理 I2C 错误的复杂性。 它可能有额外的 I2C 事务等待处理并排队、必须在终止前解除挂起。 我们可以咨询 TI-RTOS 专家。  

  

您好、Charles、
请告诉我谁是 TI-RTOS 专家？ 根据您的评论、停止位看起来是由 TI-RTOS 发出的。 我对吗？ 谢谢

您好、Charles、

我发现当第一个传输完成时、I2CMCS 状态寄存器的值是怪异的。 为什么总线空闲和繁忙标志同时存在？ 请告诉我为什么？ 谢谢！

您好 Lisa、

 实际上、我无法重现您的结果。 我运行了相同的 i2ctmp006_EK_TM4C1294XL_TI 示例、并看到在采样 NACK 后发出 STOP。 我自己编写了简单的非 TI-RTOS I2C 主测试用例、它们是相同的。

您好、Charles、

这是我的另一个问题、我检查了 TM4C129、它确实生成了 STOP。 但同一个示例项目、当它在 TM4C123上运行并且它没有生成 STOP 时。 我查看了129和123数据表、I2C 流程图看起来是完全相同的。 但是、129将在获得地址 NACK 后自动发出 STOP。 我检查软件、它是同一个软件。 很奇怪... 您可以在 TM4C123上测试它吗？ 谢谢~

您好 Lisa、

 我目前在周四之前不上班。 我不能在 TM4C123上工作、直到我回来。 但是、您能否同时修复从器件地址、以便继续进行开发。 同意需要解释主器件无法立即停止的原因以及 TM4C129和 TM4C123之间的细微差异。 但在我看来，这不是一个表演障碍。 更重要的是要知道主器件为什么没有获得 ACK'ed 我认为您的优先级是首先更正从器件地址、以便在主器件和从器件之间建立正确的通信。  

您好、Charles、

海报提到"I2C 总线"、但从未描述存在和连接的其他器件(如果有)。

总线的"条件"-受(所有)连接的器件影响-在生成 NAK 时可能起作用。

海报接着指出，"但在 TM4C123上运行的同一个示例项目. 失败。"    因此(原因不明)不清楚-如果海报识别到"4C42的 I2C 就绪"条件和(或许)其他 I2C 设置/配置。 编码方式与129的代码不同...

很久以前-但"时间已经冻结"-过去的海报"Bugs d器 最糟糕的噩梦"(真的)发布了一个相当完整的 I2C 代码列表-其中"4C123"(或者也许更早的 LX4F MCU)通过"NAK"正确地响应了"非法地址"。   过去(成功的 I2C 代码)是在"StellarisWare"(而不是品牌重塑(TM4C)版本)下生成的-这可能提供了帮助(潜在)解决问题的线索...

您好、Charles、

客户测试我们的 I2C 驱动程序、一项测试是访问 I2C 总线上的 unknow 器件。 测试完成后、客户发现 TM4C123将 SCL 拉至低电平。 因此、客户提出了这个问题、我可以重复一下 Launchpad 上的问题。

我挖掘代码并对其进行测试。 我将在更改代码后发出 STOP

if (errStatus &(I2C_MASTER_ERR_ARB_Lost | I2C_MASTER_ERR_ADDR_ACK)｛
GPIO_TOGGLE (Board_LED0、Board_LED_OFF)；//LISA
IF (errStatus 和 I2C_MASTER_ERR_ADDR_ACK)
｛
I2CMasterControlhwAttrs->baseAddr、
I2C_MASTER_CMD_BURST_SEND_ERROR_STOP)；
｝
I2CTiva_completeTransfer ((I2C_Handle)参数)；

｝

但是、第一个 I2C 数据问题重复起始模式。 但是、由于总线上没有器件、因此不应产生重复起始条件。 请参阅 I2C 波形。 在设置中断点后、启动第一个事务、当我们为 TM4C123加电时、I2CMCS 忙位设置1。 您能告诉我什么情况会将  I2CMCS 设置为忙吗？ 谢谢

波形  

 

2.

您好 Lisa、

 我可以在 TM4C123中复制。 在 TM4C123中、即使在地址周期内 NACK 之后、主器件也会发出另一个字节写入。 我尝试将0xF0写入为第一个字节数据、它显示在地址周期后的波形中。  

对于 RTOS 版本示例、我看到下面的波形。  

我与 Amit 进行了核对、他确认 TM4C123和 TM4C129之间的 I2C 模块不同。 与 TM4C129相比、TM4C123即使不是理想的行为也是预期行为。

您好、Charles、

我们是否有解决方案来修复 TM4C123？ 这是硬件问题吗？ 谢谢

您好 Lisa、
是的、这是一个硬件问题。 我们需要进行更多调查、并查看勘误表是否合理。

您好、Charles、

感谢您的回复。 我没有看到任何关于此问题的勘误表，您能否仔细检查它？ 谢谢！  

您好 Lisa、
我打算说、一旦清楚地了解了所有内容、我们就可以将此内容添加到勘误表中。

您好、Charles、

我在 TM4C123GH6PM 上发现了另一个奇怪的东西。 当我使用同一个项目(i2ctmp006_EK)且 ReadCount =2时。 即使总线上没有器件、I2C 也会发出完整的写入+读取波形。 请参阅下面的波形。 通常、M4应在写入地址后获取地址 NACK 以访问未知器件。 但是、我捕获的波形显示 M4获得 ACK 并更改为读取模式。 我插入了 GPIO 来观察读取模式/写入模式 入口点。 这真的很奇怪。  请参阅下面的波形。 还可以检查一下吗？ 谢谢

我没有在 I2C 总线上连接任何器件。 我不应该从设备获得 ACK。。

I2C 波形

CH3 -写入模式入口点

Ch4 -读取模式

您好 Lisa、
我在第三次传输后的波形中看到 ACK 字段为低电平。 您能否使用振荡器示波器来确认它确实被拉至低电平？

您好、Charles、

感谢您的回复。 我检查第9个时钟 SDA 为低电平的波形。 这意味着我们在器件上获得 ACK。 请参阅波形。 如果我不对、请告诉我。 谢谢！

您好 Lisa、
我不会对您在逻辑分析仪中看到的内容产生异议。 我在上一篇帖子中询问您是否可以确认使用范围。 如果 MCU 是 I2C 总线上的唯一节点、则 MCU 必须出于某种原因驱动此 ACK。 也许内核被误解为认为 MCU 主器件正在成为接收器、并试图告诉从发送器它仍然可以接受数据。 您的代码正在执行一些写入和读取操作、对吧？ 如果您将代码更改为仅写入而不是读取、该怎么办？