[参考译文] MSPM0G1107：I2C/SMBus 的多主器件问题

师父应该先听后讲,所以我总是想,实际仲裁丢失的条件是相当罕见的（非常紧张的种族）。 但是、I2C 容易受到噪声/干扰的影响。

我不知道 另一位师父是否遵守规则。 它是否知道它位于多主总线上？

分析仪是否跟踪您可以发布的内容？

高 RT、

尽管您已经读取总线状态、但它确实具有两个主器件在下次生成 START 信号的可能性。

我想您可以检查另一个主器件是否支持多控制器模式。 顺便说一下、这两个控制器的配置是什么、相同的 SCLK 频率？

当问题发生时、总线、M0 或电池中的命令是有效的、还是两者都无效？

B.R.

Sal

感谢您发送编 修。  我认为,作为这个主题的人,我可以继续:)

您好 Bruce！ 这就是我们在`信号之前检查总线是否可用的方法、同时使用`μ s (pRegs->master.msr 和 I2C_MSR_Busy_set) μ s、您是对的：仲裁丢失的情况很少发生、但有时驱动程序会检测到这种情况。  

但是、有时看起来好像驱动程序没有注意到总线正在被另一个主设备使用。  逻辑分析仪显示电池（第二个主器件）的数据正在通过 I2C/SMBus 传输、MCU 控制器似乎认为它正在使用总线本身。 结果是接收缓冲区中有错误的数据。

嗨、Sal！  
这个 SCLK 频率也许是一个很好的线索、因为两个掌握者的两个时钟略有不同。 一个大约为 65kHz、另一个大约为 100kHz、但根据我记得的情况、我在配置中尝试了使这些频率更接近、此时问题仍然发生。

很难说这个问题是何时发生的。 逻辑分析仪中的总线似乎运行正常。 我们可以看到这个问题、因为从 FIFO 的接收缓冲区中有错误的数据、并且 驱动程序不报告任何错误标志。 每次看到它时、另一个主器件都会使用总线。

时钟同步和仲裁都是多主器件运行的一部分。 但两个（所有）主设备都必须执行它们。

我想 MSPM0 可能无法正确执行它们、但至少它要求[Ref TRM (SLAU846B) 第 20.2.3.9/.10 节]。 其中一个证据是另一个主装置的类似陈述。 （您是否有我可以查找的器件型号？）

另一个证据是分析器迹线、它（可能）将显示哪个主设备正在干扰另一个主设备（即，哪个主设备先通话）。

[编辑：您可能需要 I2C_MSR_BUSBSY_SET 而不是  I2C_MSR_BUSY_SET、因为前者反映了所有总线活动、而后者是该主器件生成的唯一活动。 也就是说：I2C 单元本身应该等到 BUSBSY=0 后再开始新操作[参考 TRM 表 20-56]、因此检查软件可能是多余的。]

您好、Piotr、

但是、有时它看起来好像驱动程序没有注意到总线正被另一个主设备使用。

为了澄清这一点、您可以在读取一个具有 M0 的 GPIO 之前切换该 GPIO、以便您可以查看它是否错误判断总线状态。

B.R.

Sal