• 状态 Resolved
  • 已锁定 已锁定
  • 回复 6 回复
  • 订户 0 订户
  • 视图 422 视图
  • 用户 0 会员在此处
选项
选项
相关

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] TCAN1051V-Q1：TCAN151V CAN 总线通信问题

admin
Guru**** 2390735 points
Other Parts Discussed in Thread: SN65HVD230
请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/interface-group/interface/f/interface-forum/992843/tcan1051v-q1-tcan151v-can-bus-communication-issue

器件型号：TCAN1051V-Q1
主题中讨论的其他器件：TCAN1051、 SN65HVD230

您好！

我遇到了一个 TI TCAN 1051干扰 CAN 总线的问题。 下面是测试设置：

这是通过连接未供电的 DUT 进行仿真的、其中 TCAN1051收发器用于已供电的 CAN 仿真器。  在这种情况下、CANH 和 CANL 信号都在技术规格范围内。  

然后为 DUT 供电、在3.3V 之前先为5V 供电、CANH 和 CANL 被拉至低电平、这将影响 CAN 总线上连接的其他器件将读取的消息。

 

CAN 收发器 TCAN1051不应将总线拉至低于其规格。

请告知 CAN 总线以这种方式工作的原因是什么？ (例如从2.5V 拉至1.2V？？？)

此致、

Felix

  • 0
    TI__Guru**** 2390735 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    Felix、

    感谢您将此内容引入 E2E。 为 VCC 供电、但不为 VIO 供电会使器件处于受保护模式、此时总线阻抗发生变化、但不应将总线拉至1.2V。 、

    我已通知此器件的专家该主题、他们将相应地作出响应。

    此致、

    Eric Hackett  

  • 0
    TI__Guru**** 2390735 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Felix、

    正如 Eric 所说的、这种电源配置将使 TCAN1051进入保护模式、使总线引脚处于高阻抗状态。 在该状态下、该收发器不会主动将总线偏置到2.5V、而只会提供接地的高阻抗泄漏路径。 此保护模式下的泄漏路径比完全未通电状态更重要。 但是、在大多数系统中、不允许通信不应足够重要。  

    总线上的其他有源收发器可能会继续将总线偏置为隐性电压(~2.5V)。 但是、这些偏置有意较弱、因此它们不会与任何试图将显性状态驱动到总线的收发器进行竞争。 由于这种弱偏置、总线上的小泄漏路径会对隐性电压产生显著影响。 我们可能在您的系统中看到、由于 TCAN1051在保护模式下的泄漏增加、总线上的一个有源收发器无法将隐性电平偏置为2.5V。 在提供5V 电压之前、器件会以更小的泄漏路径断电、因此仿真器收发器不会出现偏置隐性电平的问题。 当两个电源都处于活动状态时、仿真器和 TCAN1051协同工作、将总线偏置至2.5V、并且不存在明显的泄漏路径。 如果在 TCAN1051处于保护模式时总线上有更多的收发器处于活动状态、则每个活动收发器都会产生偏置、并且可以实现更接近2.5V 的隐性电平。  

    最后、我想声明、在大多数系统中、从2.5V 降低的隐性电平不会影响信号完整性。 由于协议在两条 CAN 线路的差分端工作、因此只要 CANH 和 CANL 的间隙保持相同的水平、就会保持信号的完整性。 由于隐性电平较低、这些信号发生非对称转换可能会影响以超高数据速率运行、具有复杂网络拓扑或特别关注发射的系统。  

    请告诉我这是否清楚、如果您对这可能对您的设计产生何种影响有任何疑问。  

    此致、
    Eric Schott

  • 0
    TI__Guru**** 2390735 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Eric：

    我们的设置实际上只是将 TCAN1051收发器直接连接到 CAN 仿真器的 EUT。  没有 CAN 总线连接 CAN 设备，这意味着只有 TCAN1051将总线拉至低电平。  请参阅下面捕获的2个波形。  一旦 VCC (5V)上电、CAN_H 和 CAN_L 就会失真、并且仅在 VIO (3.3V)启动后恢复。  CAN 波形的失真是不可接受的、因为连接到 CAN 总线的其他器件可能会丢失关键数据。  这是不可接受的。

    此致、
    Felix

  • 0
    TI__Guru**** 2390735 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Felix、

    我知道这些波形并不表示正常的 CAN 网络。 这是因为一半的网络处于受保护模式。 一旦将该器件放置在与其他有源节点连接的总线上、其他偏置收发器将能够适应欠功率 TCAN1051的泄漏。 这将导致网络按比例更加活跃(2个受电节点、1个受保护节点)、并且失真将显著降低。  

    在该系统中、通信是否打算在此受保护状态期间进行？ 在大多数不实现局部联网的 CAN 系统中、一旦检测到总线通信、所有连接的 CAN 节点都将变为活动状态。 是否计划在 CAN 总线上存在其他流量的情况下使用 TCAN1051节点通过此斜坡上电？ 如果是、在该状态期间、预计有多少个节点处于活动状态？

    此致、
    Eric Schott

  • 0
    TI__Guru**** 2390735 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Eric：

    该器件可被视为售后市场产品、可安装在具有不同 CAN 器件的系统上。  我们之前遇到过类似的问题、CAN 总线受到 CAN 收发器启动的影响和失真、这在缺少关键信息时导致了重大问题。  因此、最好的方法是避免 CAN 失真和中断。

     安装 TCAN1051的器件可与系统其余部分分别加电/断电、因此问题是该器件将影响此配置中的 CAN 总线。  连接到 CAN 总线的器件可以相互独立供电，因此我们的 TCAN1051器件根本不会影响 CAN 总线。  

     要回答这些问题、应在 TCAN1051上电/处于受保护状态时进行通信。  CAN 总线上的流量应继续、TCAN1051不应影响 CAN 总线。  该器件将安装在不同的系统上、这些系统可能连接不同数量的节点。

    在这种情况下、您是否建议我们在这种情况下使用备选 CAN 总线 IC？ 我在论坛 (+)上看到了 TCAN1051V-Q1：STM32f091接口无法正常工作-接口论坛-接口- TI E2E 支持论坛 提到了另一个 CAN 总线  sn65hvd230 没有此类问题。  

    正如我提到的、这是售后产品、我们真的不知道最终网络中将有多少 CAN 节点。

    不确定这是否有帮助？

    此致、

    Felix

  • 0
    TI__Guru**** 2390735 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Felix、

    感谢您描述这将在您的终端设备中引起的问题。  

    我认为切换到3.3V 收发器可能是一种有效的解决方案、因为这样可以消除器件部分供电的情况(3.3V 收发器仅使用一个 Vcc 源)。 但是、如果目标是对总线的影响最小、3.3V 收发器可能也不是最佳解决方案、因为这些器件将无法提供与5V 收发器相同的 CANH 显性电压。 这与受保护的 TCAN1051的泄漏电流一样、对总线的影响很小、但听起来这是这个实现方案的一个重大问题。  

    对于5V CAN 收发器的理想无源行为、我建议使用非 V 型号的 TCAN1051 (引脚5为 NC)、以便在上电期间不会进入保护模式。 如果需要3.3V 逻辑输入、则需要在 RXD 线与控制器之间包含一个外部电压转换器(可以是一个简单的 FET、它将上拉至 Vio)。 TXD 输入与 VIH 阈值为2V 的3.3V 输入逻辑兼容。 此解决方案是否听起来适用于此设计？

    此致、
    Eric Schott