[参考译文] TM4C1290NCZAD：有关 TM4C129 I2C 干扰的问题

尊敬的 Meredith：

为了更好地理解和调试这个问题、我一直在尝试自己重新创建这个问题、但到目前为止、我还没有成功地这样做。 我不会说这是预期行为、在浏览主题时、我还没有看到相关案例的报告。

在我尝试重新创建问题的末尾、我添加 了一个 SysCtlReset、并通过一个针对3V 的 o 范围集上的触发器来监视 SDA、并且在几十次尝试中、它仅在与从器件通信开始时触发。 复位时未观察到毛刺脉冲。

因此、我想在此再提出几个问题：

1) 1)这是否仅在定制硬件上发生？ 是所有器件还是少数器件都存在这种情况？ 执行复位时、它们是否可以100%重新创建该时间？

2) 2)他们是否移除了从器件并仍然观察到这一点？

3) 3)当复位发生时、是否有任何 I2C 通信正在进行？

4) 4)他们是否看到 SysCtlReset 与看门狗之间有任何差异？ 我没有尝试看门狗复位、但我已经通过 RST 置位和 SysCtlReset 尝试硬复位和软复位。

您好 Ralph、

我的小型技术小组(喜欢)您的诊断列表(#1和#2)。

事实证明、了解"受问题影响的人口(百分比)"以及"连接设备可能产生的影响"总是很有用的。

我们建议在您的诊断列表中添加(进一步)问题/观察结果：

• 请注意、"I2C 从设备(或远程主设备)设备(可能访问"SDA")的数量目前为"未知！"   
• 没有提到"远程"I2C 器件(从器件或主器件)如何或是否(任何)连接到此类复位或受到此类复位的"影响"。
• 事实证明、简单地说、"脱开并提起远程器件的 SDA 引脚"(当然要轻轻地)、而不是"取出芯片"会更容易。   (如果有多个远程 I2C 器件、尤其有用！)
• 在复位被置为有效时、明智的做法是监控到 MCU 和(所有)远程 I2C 器件的电源电压。
• 我们发现、"较长持续时间重置和/或脉冲重置"可能"帮助消除此类"干扰问题"。

未说明的是、"如何发现这种干扰"及其潜在影响。   (如果没有发生 SCL 切换-那么 SDA 毛刺脉冲可能没有记录……)

拉尔夫

感谢您关注此问题和后续行动。 以下是我对您的问题的回答以及更多(希望有用)信息。

1) 1)我可以在我们的定制硬件和 EK-TM4C1294XL LaunchPad 板上重现此问题。

2) 2)当我们使用 LaunchPad 板进行重现时、总线上没有 I2C 从器件。 Tiva 是唯一的器件。

3) 3)复位发生时没有 I2C 通信。 为了简化调试、我们在启用任何 I2C 通信之前立即发出可疑的复位信号。

4) 4)我们看到 SysCtlReset 和 Watchdog 的行为相同。

为了简化问题、我删除了所有不必要的代码来隔离问题。 此外、我还开始专门使用 LaunchPad 来重现和调试该问题。 在我的硬件配置中、除了在 SDA 引脚和+3.3V 之间连接一个10KOhm 电阻器来创建所需的上拉电阻器以实现正确的 I2C 操作外、我使用的是一个全新的 LaunchPad 板。 该电阻器连接到接头 A1引脚10 (I2C0SDA)和接头 A1引脚1 (+3.3V)。

我已附上重现此问题的源文件。 它使用 SysCtlReset、但看门狗复位执行相同的操作。 我还附加了一个示波器捕获、该示波器捕获使用附加的代码来显示干扰。

如果您有任何建议、我可以尝试使用 LaunchPad、请告诉我。 我非常感谢你在这一问题上的帮助。

谢谢、

道格

e2e.ti.com/.../Policy.c

Doug、您好！

感谢您添加了这些详细信息、以及您如何在 LaunchPad 上重新生成问题。 这是一种奇怪的行为、因为当不使用从器件时、我仍然使用与不产生干扰的 I2C 板相同的上拉值(3.3kOhm、我最初使用的是 BOOSTXL-SENSHUB)、并且我能够复制压降。

在本例中、最小电压为2.64V、持续时间约为15ns。

我需要与同事进一步了解这一点、但有几个问题：

1) 1)跌落是否在系统级别引起问题、或者是否只是了解器件工作原理的更多问题？

2) 2)定制硬件上使用了什么值的上拉电阻器？

3) 3)自定义硬件上是否存在连接和未连接从器件的问题？

我又进行了另一轮搜索、以了解有关该主题的更多信息、但没有看到太多内容。 我从读数中得出的初始猜测是、这与开漏配置的工作方式有关、因此当您将其转换为模拟模式时、这就是"干扰"消失的原因。 您是否注意到上拉电阻值与观察到的压降之间存在任何关联？

拉尔夫

 BOOSTXL-SENSHUB 似乎连接到 EK-TM4C123GXL、后者使用 TM4C123器件。 我们的器件是 TM4C129器件、它们可能具有不同的行为。 我不熟悉 TM4C123和 TM4C129器件之间的差异。

回答您的问题：

1) 1)这是一个系统级问题。 我们的产品是平台标准的一部分、允许我们的客户向其添加第三方器件。 这意味着我们无法控制连接到总线的从器件数量、这意味着我们需要容忍不在我们控制下的 I2C 器件、其中一些器件可能会受到干扰的不利影响。

2) 2)我们在某些硬件上使用4.7K、在其他硬件上使用10K。

3)是的、我们的硬件上存在从器件存在和不存在从器件的问题。

我注意到电阻值确实会影响电压电平和干扰持续时间。 更高的上拉电阻值更大的压降和更长的恢复时间。

我确认当 GPIO 引脚配置为 I2C SDA 时、复位期间可能会出现不可避免的干扰。 如果我们可以确认在复位期间将 SDA 引脚更改为模拟模式是无毛刺脉冲的、那么我们将对该解决方案感到满意。 作为参考点、当我们将 SDA 引脚配置为原样以进行 I2C 操作(漏极开路、由 I2C 外设控制)时、我们会看到复位时的干扰、复制率为100%。 当我们在复位之前将引脚重新配置为模拟输入时、我们观察到在1000个以上的复位周期内重现了0%。 基于我们的测试、我们对该修复程序/解决方案非常有信心、但也希望 TI 对该修复程序充满信心。

感谢您的所有帮助！

道格

Doug、您好！

[引用用户="Doug Ahlstrom"> BOOSTXL-SENSHUB 似乎连接到 EK-TM4C123GXL、该设备使用 TM4C123器件。 我们的器件是 TM4C129器件、它们可能具有不同的行为。 我不熟悉 TM4C123和 TM4C129器件之间的差异。

BoosterPack 同样适用于 TM4C LaunchPad 和 DK-TM4C129X。 我将 BoosterPack 与 EK-TM4C1294XL LaunchPad 和来自[安装路径]\TivaWare_C_Series-2.1.4.178\examples\boards\EK-tm4c1294xl-bootstxl-senshub 的工程一起使用

[引用 user="Doug Ahlstrom">当我们在重置前将引脚重新配置为模拟输入时、我们观察到在1000多个重置周期内重现0%。 基于我们的测试、我们对该修复程序/解决方案非常有信心、但也希望 TI 对该修复程序充满信心。

我们现在正在进一步分析根本原因、在我们了解原因之前、我不准备建议该修复是否理想。 但这是一个很有希望的结果、一旦我们更好地了解问题、我们将把它作为可能的解决方案来研究。

您好！

为了"完整性"，以下几点不值得(部分)考虑？

• 开幕词说，" Tiva 的 I2C 总线 SDA 信号的问题"，但仍不清楚是否审查了"PB3"以外的信号。   如果(另一个) SDA 功能引脚能够解决此问题-这似乎是一个出色的解决方案。
• SDA 的"犯罪合作伙伴"(SCL)"非常"收到"没有提及！"   它是否能够避免干扰？   如果是、这是否不是"指向(可能/可能)加速(可能简化)的内部器件解决方案？"
• 每次"上电复位时是否会发生毛刺脉冲？"   那么呢？
• 发生"欠压/类似"时？

应该注意的是、"在每个"已知复位命令"(和 MCU 的恢复)之后、SDA 线路必须被恢复为开漏。

尽管在 MCU 生产的六年多里、"干扰的影响"可能会被证明是最小的、因为很少(也许没有)具有类似的"发出这样的警报！"

最后、"在第二个(并联)上拉 R"[通过 GPIO 切换为高电平])可能更符合 I2C 标准(漏极开路)、同时(进一步)缩小产生问题的毛刺脉冲？    这将与供应商的"解决方案"完全相同、但通过将 GPIO 订购为"输入"而删除-当不需要时...

您好 CB1、

问得好、我已经找到了一些答案！

[引用 user="CB1_MOBIST"]开头的帖子指出：“Tiva 的 I2C 总线的 SDA 信号有问题”-但仍不清楚是否(除 PB3之外)进行了检查。   如果(另一个) SDA 功能引脚能够解决此问题-这似乎是一个出色的解决方案。[/引述]

我测试了多个 I2C 端口、并发现了所有端口上的行为。 不是100%全面扫描、但三个端口表示一个模式。

[引用 user="CB1_MOBIT]SDA 的"犯罪合作伙伴"(SCL)"非常"收到"没有提及！"   它是否能够避免干扰？   如果是、这是否不是、"指出加快(或许已简化)内部器件解决方案的方向？"

这家酒店的细节很棒！ SCL 实际上不需要开漏配置。 因此、我们有一个不同的配置 API 用于它： GPIOPinTypeI2CSCL

在此 API 中、使用了以下内容：

GPIOPadConfigSet (ui32Port、ui8引脚、GPIO_Strength _2mA、GPIO_PIN_TYPE_STD)； 

Ergo、与漏极开路相关的干扰没有问题。

[报价 USER="CB1_MOBIT)]每次"上电复位？"时是否会发生毛刺脉冲？   那么呢？[/报价]

从我可以看到的结果中、是的、每个器件复位都会受到影响。

[报价 USER="CB1_MOBIT"]并在出现"欠压/类似"的情况时？[/QUERPLET]

我没有测试 BOR、但根据观察结果、我假设它也会出现毛刺脉冲。

[引用 USER="CB1_MOBIT"]应该注意的是，"在每个"已知复位命令"(以及 MCU 的恢复)之后，SDA 线路必须恢复为开漏。

正确、但这应作为正确 I2C 配置后置复位的一部分自然发生、从而使器件进行重新配置。

拉尔夫的美好夜晚

感谢您-感谢您的"电池破裂"响应。

好的是(大多数)所有 SDA 候选引脚都经过了检查(未注明)、证明"难以接受"。

SCL -(实际上)只有"新增/改进的"(即额外速度模式)需要从"正常开漏模式"中删除 SCL 吗？   (这表明"全在这里"未能出席的一个问题！  尤其是 Moi！)   现在、在100KHz 范围内- IIRC -在您的'123器件上-我们已经通过了、"强制 MCU 的 SCL 线路"开漏"-这是成功的！   (这是员工探索的-并满足了客户对"多主控"I2C 的需求-在这种需求中、使用(除开漏之外)可能会导致"SCL 信号争用！"   (您可能希望考虑自己-我处于"欧洲时间计划"-必须保持一致且(几乎)一致@ 03：00 CST。)

您是否对我们的"抑制干扰"并联上拉建议有意见？   虽然与 SDA 无关、但 gurl 员工已使用该方法(不止一次)解决类似的干扰相关问题。   

此外、员工注意到这些 MCU 已接近(接近)十几岁、但其他类似的"DA 干扰报告"也没有影响我们的雷达... (购买时"二手"-折扣优惠...)   

这个周末-我们将在123块电路板上运行测试-如果它们遭受类似的影响、请进行观察并报告。

小心...

拉尔夫

非常感谢您迅速采取行动来支持此问题。 我们似乎同意开漏功能在复位时引起干扰。 我们已尝试您推荐的解决方案将 SDA 引脚配置为 GPIO_PIN_TYPE_STD、但现在我们观察到调用 GPIOPadConfigSet (GPIO_PORTB_BASE、GPIO_PIN_3、GPIO_FORMENT_2mA、GPIO_PIN_TYPE_STD) 会导致 SDA 引脚被驱动为高电平(尽管复位时不再有干扰、这很好)。 如果 I2C 器件在引脚配置为 GPIO_PIN_TYPE_STD 期间或之后发送零则会很糟糕。 我们更喜欢将引脚设置为 GPIO_PIN_TYPE_ANALOG、并确认其已失去数字功能、尤其是因为我们的固件保证 Tiva 部件在引脚配置为 GPIO_PIN_TYPE_ANALOG 期间不会传输或处理 I2C 传输。  在我们的测试中、为 GPIO_PIN_TYPE_ANALOG 配置引脚会在整个复位过程中使焊盘处于三态条件、直到我们的固件将引脚重新初始化为 GPIO_PIN_TYPE_OD 后复位。 如果您认为将引脚配置为 GPIO_PIN_TYPE_ANALOG 是错误和/或错误的、我们希望这样做。

为了更详细地说明，使用 PIN_TYPE_ANALOG 调用 GPIOPadConfigSet()实际上会导致 SDA 线路被驱动为高电平，类似于使用 GPIO_PIN_TYPE_STD 调用 GPIOConfigSet()，这不像我在上面解释的那样好。 这是因为 GPIOPadConfigSet()修改 GPIO 寄存器的顺序。 如果 ODR 位被首先清零、我们会看到当 ODR 被清零时 SDA 管脚驱动为高电平。 但是、如果我们首先清除 DEN、那么在随后清除 ODR 位时、我们不会看到 SDA 引脚(高电平或低电平)的驱动。 因此我们的固件不 会使用 GPIO_PIN_TYPE_ANALOG 调用 GPIOPadConfigSet()。 相反、我们先显式清零 DEN 位、然后清零 ODR 位。 这会导致无毛刺脉冲复位和一个正确的未驱动 SDA 引脚。

[编辑]我的权变措施中的操作顺序是反向的。

Doug、您好！

我们的调查重点是跟踪 ODR 位、但根据您的系统要求、我们在处理类似设置时没有问题、因为您已经解释了 STD 设置与您的系统相关的缺点。 模拟设置没有什么问题、似乎过多地更改引脚、但很显然、对于您的设置、您有理由这么做、这对我来说都是合理的。

您好 CB1、

[引用 user="CB1_MOBIST"]您是否对我们的"干扰抑制"并联上拉建议有意见？   虽然与 SDA 无关、但 gurl 员工已使用该方法(不止一次)解决类似的干扰相关问题。   [/报价]

不幸的是、我没有。 这不是我所熟悉的设置、因此我不想用任何一种方式来评论它的优点、但很欣赏这一建议、因为它是解决这一问题的另一种可能途径。

拉尔夫

明白。 感谢您对此问题的支持。 您(和您的团队)非常乐于助人。

道格

来自"外部"团队的您好、(再次)

选择：

[报价用户="Doug a"]为  GPIO_PIN_TYPE_ANALOG 配置引脚[/QUERP]

可能会导致"道路上的问题"、尤其是在(所选) SDA 引脚为"不兼容模拟！"时   (MCU 引脚的有限子集采用模拟操作。)

这是另一个值得考虑的事实。

我们集团的建议是、"通过"并联上拉电阻器(由自由 GPIO 驱动)的受控开关"来降低干扰的"有效影响"、从而实现了"长期标准、经实践检验的安全开漏 SDA 引脚配置的延续！"。   (实际上- ON (其他供应商的) ARM MCU -类似地尝试"强制非模拟引脚"进入模拟模式-导致了问题...)   员工回顾这些(误导)模拟"强迫"、而不是 SDA 救援。

是否应绕过"长期"风险回报？   几乎肯定-此类(异常)引脚配置没有"正常/习惯" MCU 测试/鉴定的好处。   您(可能)可以通过此类"强迫"的"公文"来保存-但实践会增加风险因素...