[参考译文] TCAN4550-Q1：运行 tcan4550 1-3小时、会出现无法发送的问题

您好 Hangziang,

寄存器读数不会显示任何设置的中断、状态或错误计数器位、这些位会提供有关通信错误原因的任何信息。  日志和显示器读数确实显示器件进入总线关闭状态并正在重新启动。  

当总线上发送或接收的 CAN 消息过多且损坏或损坏时、会出现总线关闭情况。  出现这种情况的常见问题与总线信号完整性不良导致错误地对位进行采样、或者由于高速时钟或电压电平受到干扰而导致的。  当在运行一段时间后出现问题时、这可能意味着由于系统发热而导致某些器件发生与温度相关的变化、并导致性能变化。  

您是否在 TI 生产的电路板(例如 TCAN4550EVM)上使用 TCAN4550-Q1、或在自己设计的电路板上使用它？  如果它不是 TI 板、那么您能否提供与 TCAN4550相关的原理图部分以供查看？

此致、

Jonathan

您好！

1、上面提到的"CAN0"对应于原理图中的"CAN1"接口、"CAN1"上的端子电阻器连接到另一个远距离收发器位置、如下所示：

2 μ s 当、的器件无法发送时、它可以正常接收数据、这应该与 TCAN4550芯片的晶体振荡器和电源无关、否则无法正常接收数据

您好 Wulu、

感谢您提供原理图信息。  我要指出的是、串联22 Ω 电阻器通常位于 OSC1引脚上、而不是 OSC2引脚上、因为 OSC1引脚是跨导放大器的输出、向晶体提供电流。 但是、我认为这不会导致您的错误。

请参阅 TCAN455x 时钟优化和设计指南应用报告 (链接)、了解更多信息。

当出现大量传输错误时、这通常与尝试在总线上进行通信的不同 CAN 节点之间的位时序配置不兼容有关。  您能否验证所有其他总线节点的确切位时序配置、并确保它们与 TCAN4550-Q1使用的位配置完全匹配？

此外、您是否可以在示波器上捕获 CAN 消息、以便我们可以查看物理 CANH 和 CANL 信号是否存在任何问题、以解释消息为什么会生成错误？

我注意到、在两个60.4 Ω 终端电阻器之间有一个0.1uF (100nF)电容器。  这可能太大、常见值为4.7nF 或0.047uF。  较大的电容可能会滤除部分信号并防止这些位达到完全隐性电平、从而导致位采样错误。

CAN 总线上是否只有一组终端电阻器、或者是否有两组终端电阻器？

此致、

Jonathan

您好、Jonathan Nerger、

1 μ s、在正差分通信的情况下测量 CAN 总线波形、但在通信异常的情况下无法暂时测量该波形。

总线上总共有九个器件、只有我的器件 CAN0在发送数据：时具有以下波形

以下八个负载也上电时、某些器件在波形如下时也会开始通信：

2、在两个60.4 Ω 终端电阻器之间有一个0.1uF (100nF)电容器

当出现问题时、首先直接使用的120Ω 电阻如下、没有60.4Ω 电阻和100nF 电容器、并且您在上图中看到的状态稍后会发生变化、因此设备只能接收和无法发送的异常状态将在以这两种方式使用大约2小时后发生。

3、CAN 总线上是否只有一组端接电阻器、或者是否有两组端接电阻器？

是的、我的总线的另一端有一个端子电阻器、我的两个 TCAN4550器件的使用如下：

您好 Wulu、

为什么它们仅使用 CAN 标准中要求的一半 CAN 总线终端？  应该有两组120欧姆终端、产生60欧姆(典型值)的总电阻负载。  这些终端电阻器还能够吸收和抑制总线上的反射能量并提高信号完整性。

它们接收到的发送错误可能是由于 CAN 总线负载和端接不当造成的。

他们能否向总线添加第二组终端电阻器、看看这样是否解决了传输错误？

此致、

Jonathan

您好、Jonathan Nerger、

器件1的电路板上还有一个120Ω 电阻器、如原理图中所示

很抱歉、我误解了端接位置。  我得到纠正。

示波器图仍显示、显性和隐性电压电平应足以正确对这些位进行采样。 由于有关寄存器日志文件的信息有限、并且没有生成错误的已传输帧的示波器图、因此我不确定导致错误的原因。

回顾前面的信息、我看到位的采样点设置为87.5%。  我相信 Linux 驱动程序会计算并分配要用于创建与所需速率匹配的位周期的时间量子(或高速时钟周期)。  它还通过分配要在采样点之前和之后使用的时间量子来计算采样点。  对接近钻头末端的钻头进行采样可能不适用于所有应用程序、通过提前调整采样位置可能会获得更好的结果。  您可以尝试移动采样点并查看是否有任何改进。  这可以通过调整标称位时序和预分频器寄存器(0x101C)的 NTSEG1和 NTSEG2字段中分配的时间量子之比来实现。

此致、

Jonathan

我们尝试将总线上所有器件的采样点更改为0.80、但问题仍然发生。

我建议监视错误计数器寄存器0x1040和协议状态寄存器0x1044并记录这些寄存器值、以尝试捕获 RX 和 TX CAN 消息中出现错误的原因。

此致、

Jonathan

您的意思是、我们需要从 CAN 器件开始工作的那一刻起记录这两个寄存器吗？ 记录间隔是多长时间？

以下是​​问题发生后我获取的两个寄存器值

出现问题时、CANsend 无法成功发送数据(candump 未看到数据包、ip -d -s link 显示 CAN0未看到发送的数据包增加)

您好 Hangziang,

Unknown 说：

您是否意味着我们需要从 CAN 设备开始工作的那一刻起记录这两个寄存器？ 录制间隔有多长时间？

我的意思是、为了确定导致 CAN 消息错误的原因、我们需要尝试捕获一些实时错误计数器和状态寄存器值、这些值将报告特定类型的错误。  寄存器0x1040是错误计数器寄存器、将包含发送和接收错误计数器值(TEC 和 REC)。  如果这些计数器中的任何一个超过255、器件将进入总线关闭(BO)条件、器件将自行断开与 CAN 总线通信的连接。

寄存器0x1044是协议状态寄存器、它将包含在最后一条消息中检测到的 CAN 总线错误类型的错误代码。  因此、如果我们可以为出现错误的消息捕捉此寄存器的值、那么我们可以确定总线上发生的错误类型、并希望设法找出如何防止它们发生。

以下是​​问题发生后我获取的两个寄存器值

您读回0x104E 而不是0x1044、这不会返回正确的值。  此外、0x1040 = 0x00000000显示 TEC 和 REC 错误计数器均为0、因此这不提供任何有用信息。

Unknown 说：

发生问题时、cansend 无法成功发送数据(candump 未看到数据包、ip -d -s link show can0未看到发送的数据包增加)

我的专业知识涉及器件级 TCAN4550、但我不是 Linux 专家。  如果 TCAN4550存在问题以及其配置、我们将需要监控并记录器件在问题发生之前、期间和之后通过寄存器提供的信息。  如果可能、请尝试将以下寄存器值监控到某种形式的日志文件中、以便我们可以尝试确定错误的根本原因。

0x000C

0x0800

0x0820

0x0824

0x1018

0x1040

0x1044

0x1050

0x10A4 (如果使用 RX FIFO 0)

0x10B4 (如果使用 RX FIFO 1)

0x10C4

0x10CC

0x10D8

如果器件由于累积过多错误而停止发送并进入总线关闭状态、则处理器需要通过清除控制寄存器(0x1018[0]= 0)中的 INIT 位、或发出硬件或软件复位并像初始上电配置一样完全重新配置所有器件寄存器来重新初始化 CAN 通信。

此致、

Jonathan

我每100ms 读取一次0x1040和0x1044寄存器、并在发生更改时记录、并获取该值

格式为[小时、分钟、秒、毫秒](更改后寄存器值为0x1040、0x0144)

问题发生在下午14:51:43左右

场景：器件 A 通过 tcan4550向 CAN 总线上的器件 B 发送心跳数据包。 该过程一直持续、直到器件 B 发现它已丢失来自器件 A 的心跳数据包。此时、我们发现器件 A 仍可以通过 tcan4550正常从总线接收数据包、但无法成功发送数据包。

在过高的频率下监控更多的寄存器将影响 tcan4550的正常交互过程、因此其他寄存器暂时不会受到监控。

您可以在数据表中找到这两个寄存器的位说明、并且根据 ISO 11898 CAN 标准协议定义并更新了 CAN 错误记录计数器(CEL)、接收错误计数器(REC)、发送错误计数器(TEC)、数据阶段最后一次错误代码(DLEC)和最后一次错误代码(LEC)。

[133702209] CEL = 0、REC = 255、TEC = 0、BO = 0、EW = 1、 EP = 1、DLEC =与上次读取相比无变化、LEC =格式错误

[133753088] CEL = 0、REC = 107、TEC = 0、BO = 0、EW = 1、 EP = 0、DLEC =与上次读取相比无变化、LEC =与上次读取相比无变化

[133753121] CEL = 0、REC = 59、TEC = 0、BO = 0、EW = 0、 EP = 0、DLEC =与上次读取相比无变化、LEC =与上次读取相比无变化

[133753251] CEL = 0、REC = 8、TEC = 0、BO = 0、EW = 0、 EP = 0、DLEC =与上次读取相比无变化、LEC =与上次读取相比无变化

[133753440] CEL = 0、REC = 0、TEC = 0、BO = 0、EW = 0、 EP = 0、DLEC =与上次读取相比无变化、LEC =与上次读取相比无变化

[133805142] CEL = 1、REC = 0、TEC = 0、BO = 0、EW = 0、 EP = 0、DLEC =与上次读取相比无变化、LEC =无错误

[133805274] CEL = 0、REC = 0、TEC = 0、BO = 0、EW = 0、 EP = 0、DLEC =与上次读取相比无变化、LEC =与上次读取相比无变化

[133900798] CEL = 1、REC = 0、TEC = 0、BO = 0、EW = 0、 EP = 0、DLEC =与上次读取相比无变化、LEC =与上次读取相比无变化

[133900933] CEL = 0、REC = 0、TEC = 0、BO = 0、EW = 0、 EP = 0、DLEC =与上次读取相比无变化、LEC =与上次读取相比无变化

[145445684] CEL = 2、REC = 0、TEC = 0、BO = 0、EW = 0、 EP = 0、DLEC =与上次读取相比无变化、LEC =与上次读取相比无变化

[145445823] CEL = 0、REC = 0、TEC = 0、BO = 0、EW = 0、 EP = 0、DLEC =与上次读取相比无变化、LEC =与上次读取相比无变化

从该日志中可以看到、基于 REC 值、最初存在很多接收错误。  有时 CEL 会递增。  但没有显示传输错误或您无法在此日志中传输消息的原因。

前一个寄存器值文件显示为 TX FIFO 分配了一个 TX 缓冲器元素。  您可能需要监控 TX FIFO 状态寄存器、请求挂起寄存器和发生传输事件寄存器、以确认消息是否已加载到 FIFO 中并正确发送。  如果由于某种原因无法发送消息、则您的驱动程序可能无法将新消息加载到您分配的唯一 TX 缓冲区中、从而导致您观察到无法传输消息。

尝试监控寄存器0x10C4、0x10CC、0x10D8。

您还可以尝试增大 TX FIFO 的大小以包含多个 TX 缓冲器元素。

此致、

Jonathan

大家好、我已经重新记录了寄存器、格式现在是[小时、分钟、秒、毫秒](更改的寄存器值​​为"0x1040"0x1044"0x10c4"0x10cc"0x10d8")、问题发生在下午14：53左右。

e2e.ti.com/.../tcan_5F00_reg.log.20250419_5F00_141114658.txt

您好：

我已经查看了寄存器日志、并为我看到的值创建了一个细分表。

0x1040错误计数器寄存器
0x0 = CEL=0、REC=0、TEC=0、REC 低于128错误无源电平
0x1100 = CEL=0、REC=17、TEC=0、REC 低于128错误被动电平
0x112C00 = CEL=17、REC=44、TEC=0、REC 低于128错误无源电平
0x113000 = CEL=17、REC=48、TEC=0、REC 低于128错误被动电平
0x214300 = CEL=33、REC=67、TEC=0、REC 低于128错误被动电平
0x2900 = CEL=0、REC=67、TEC=0、REC 低于128错误被动电平
0x2C00 = CEL=0、REC=44、TEC=0、REC 低于128错误被动电平
0x5200 = CEL=0、REC=82、TEC=0、REC 低于128错误被动电平
0x7A00 = CEL=0、REC=122、TEC=0、REC 低于128错误无源电平
0x7B00 = CEL=0、REC=123、TEC=0、REC 低于128的误差无源电平
0x7D00 = CEL=0、REC=125、TEC=0、REC 低于128的误差无源电平
0x80000 = CEL=8、REC=0、TEC=0、REC 低于128错误无源电平
0xF00 = CEL=0、REC=15、TEC=0、REC 低于128错误被动电平
0xFF00 = CEL=0、REC=255、TEC=0、REC 高于128错误被动电平

0x1044协议状态寄存器
0x710 = DLEC=自上次消息以来无变化、LEC=无错误、作为接收器运行
0x708 = DLEC=自上次消息以来无变化、LEC=无错误、空闲
0x70F = DLEC=自上一条消息以来无变化、LEC=自上一条消息以来无变化、空闲
0x717 = DLEC=自上一条消息以来无变化、LEC=自上一条消息以来无变化、作为接收器运行
0x718 = DLEC=自上一条消息以来无变化、LEC=自上一条消息以来无变化、空闲
0x71F = DLEC=自上一条消息以来无变化、LEC=自上一条消息以来无变化、作为接收器运行
0x74F = DLEC=自上次消息以来无变化、LEC=自上次消息以来无变化、空闲、错误警告状态
0x750 = DLEC=自上次消息以来无变化、LEC=无错误、作为接收器运行、错误警告状态
0x769 = DLEC=自上次消息以来无变化、LEC=填充错误、空闲、错误被动和错误警告状态
0x76A = DLEC=自上次消息以来无变化、LEC=格式错误、空闲、错误被动和错误警告状态
0x76F = DLEC=自上次消息以来无变化、LEC=自上次消息以来无变化、空闲、错误被动和错误警告状态
0x772 = DLEC=自上次消息以来无变化、LEC=表单错误、作为接收器运行、错误被动和错误警告状态

0x10C4 TX FIFO/队列状态
0x1 = TX FIFO 空闲级别=1
0x200000 = TX FIFO 空闲级别= 0、TX FIFO 已满

0x10CC TX 缓冲区请求待处理
0x0 =没有任何 TX 缓冲区有消息待处理传输
0x1 = TX 缓冲区0有一条消息待发送

0x10D8 TX 缓冲区添加请求传输发生
0x0 =没有 TX 缓冲区发生传输
0x1 = TX 缓冲区0发生了消息传输

对于1453xxxxx 范围内所有时间戳的日志值,我只看到一个显示异常值的条目,该条目位于时间戳[145359846]。  在此条目中、CAN 错误记录(CEL)值设置为8、这意味着有8条消息包含 CAN 协议错误。  但是、REC 和 TEC 计数器已经递减到0、因此我不知道是发送还是接收了包含协议错误的消息、而器件已恢复正常活动。

我还注意到、寄存器0x10C4中的多个日志条目上的 TX FIFO 已满、这可能是只分配一个 TX 缓冲区、消息传输正在等待仲裁。 这不一定是问题、但必须先成功发送该消息、然后才能将新消息加载到缓冲区中。我相信在使用 Linux 驱动程序时、如果尝试访问由于当前所有现有缓冲区元素都已满而尚未分配的缓冲区元素、则可能会返回存储器访问错误。

根据此日志、我可以说的是、您似乎偶尔会遇到一些错误突发、这些错误可能表明某些外部噪声源会影响总线。  日志中的所有错误似乎都在接收器中、并且在日志开始时有一些初始错误、然后在时间戳[141835439]和[142018009]与时间戳[14210003]处的单行之间。

此致、

Jonathan

您好：

现在有一种新现象。 使用 CAN0大约五小时后、当器件完成并进入待机模式时、CAN0将暂停发送和接收数据。 当再次开始使用器件时、它还表明 CAN0只能接收、而不能发送。 请帮助检查问题是什么？

您好 Wulu、

请提供器件寄存器列表以供审核。  在不了解状态和配置寄存器值的情况下、我不知道如何帮助您确定问题的原因。  

请读取并创建一个日志或列表、其中包含以下配置、状态和中断寄存器值：

0x000C

0x0800

0x0820

0x0824

0x1018

0x1040

0x1044

0x1050

0x10A4 (如果使用 RX FIFO 0)

0x10B4 (如果使用 RX FIFO 1)

0x10C4

0x10CC

0x10D8

此致、

Jonathan

e2e.ti.com/.../tcan_5F00_reg.log.20250507_5F00_101320063.txt
你好,这一次问题再次出现在大约10:44:25。 此日志存储寄存器列表("0x000c""0x0800"0x0820"0x0824"0x1018"0x1040"0x1044"0x1050"0x10a4"0x10c4"0x10c4""0x10cc")

您好、数据日志未显示 TCAN4550无法传输的原因。  错误计数器寄存器不会显示错误、配置和控制寄存器显示其处于正常模式、MCAN 已初始化并能够在 CAN 总线上进行通信。

我注意到 TX FIFO/队列状态寄存器0x10C4会将 TX FIFO 显示为具有1个空闲 TX 缓冲区元素、或者该元素已满。  它最后一次在日志中显示它已满时是时间戳[104214317]。  此后不久、TX 事件 FIFO 显示它在时间戳[104215224]有一个新的事件元素。  此后、MCAN 中断寄存器中不再设置 TX 事件 FIFO 中断位、TX FIFO 空闲级别始终显示为1、这意味着 TX FIFO 没有要发送的消息。

TCAN4550已停止发送 CAN 消息的原因可能是因为处理器未将任何消息加载到 TX FIFO 中、因为 TX FIFO 始终为空、并且 TX 缓冲区添加请求待处理寄存器0x10CC 始终显示没有添加任何消息用于传输。

请验证处理器是否正确地将消息加载到 TX FIFO 缓冲器元素中、并设置 TXBAR 寄存器0x10D0中的 TX 缓冲器添加请求缓冲器编号。

此致、

Jonathan