[参考译文] TCAN4550：TCAN4550

尊敬的 Akshay：

由于已有一段时间、另一个线程由于不活动而被锁定、您能再次提醒我当前的性能状态吗？  我记得有多个节点尝试发送和接收消息、在一段时间后、其中一个节点将停止传输。  这仍然正确吗？

如果你能再次给我一个基本的概述你的观察,什么需要解决将是有帮助的。  驱动程序经过更新，提高了消息吞吐量并提高了效率，但如果在一段时间后仍看到一个节点静默，则可能与驱动程序无关。  此外、如果是这种情况、您能否再次提醒我、从您的测试开始到测试停止运行之间的时间间隔是多少？

谢谢。
乔纳森

尊敬的 Jonathan：

是的、方案与您所介绍的方案相同。  

但我尚未测试该情形。

我相信我已经分享了我们的  Bosch、MRAM-cfg =<0x0 3 2 32 10 0 26 12>(在较早的线程中)、我们正在使用这些方法来测试这些场景。 但在更新的驱动程序中、相同的配置似乎不起作用。 每当我们尝试采用上述配置插入 TCAN 模块时、它都会显示一个错误 "tcan4x5x spi0.0：MRAM 配置(3980)的总大小超过 MRAM (2048)"  和 TCAN 初始化 失败。  

因此我修改了 Bosch、MRAM-cfg =<0x0 0 0 15 6 5 1 1>  不超过2048字节、并顺利初始化 TCAN。 但在采用这种配置时、如果执行时间超过10分钟、器件将停止接收数据、即使只有一个节点在传输数据。  

所以 我在想是否有任何其他配置,我可以尝试,这样我的接待工作解决任何问题。 工作完成后、我将继续看看您之前提到的另一个场景。

我希望这能让您清楚地了解情况。 如果您需要更多说明、敬请告知。

此致、

奈克·阿克谢

尊敬的 Akshay：

我已经对之前的 Bosch 配置所需的 MRAM 空间进行了一些计算、mRAM-cfg =<0x0 3 2 32 10 0 26 12>、看起来这应该适合我的计算。  我必须进行这项检查、因为假设 RX 和 TX 缓冲区元件配置为完整的64字节数据有效载荷、那么您之前的配置应该是总 MRAM 的50%左右。

只要 MRAM 分配能够容纳所有没有重叠的元素、并且有足够的元素供处理器及时接收、存储和读取消息、并避免溢出情况、我就不知道配置会有何差异。  如果 RX FIFO 或缓冲区已满、并且处理器无法及时清除、则可能会拒绝新的报文。  

您能否读回所有器件寄存器、以便我们可以查看配置、状态/中断和错误计数器寄存器、从而重新了解新版本驱动程序的器件状态？

我想看看是否有任何正在设置的状态或中断位、或模式是否已更改、或者是否有任何 TX/RX 错误可能导致器件进入错误警告或总线关闭状态。  我还想确认驱动程序是否正确分配了您的 MRAM 空间、因为新旧版本的计算似乎不同。

此致、

乔纳森

尊敬的 Jonathan：

很抱歉耽误你的时间。

我能够更改 MRAM 配置。 但我陷入了另一个问题、下面介绍了该问题：

1) TCU 连接到 VCM (车辆控制模块)。  TCU 将请求帧传输到 VCM、如图1所示。 每当 VCM 收到该请求时、它就会响应响应帧、如图1所示。 但是、有时从我们的 TCU 器件接收时会错过响应、如图1所示。  当 TCU 执行 TX 请求时、我还使用峰值 CANFD 设备监测所有流量、峰值看到的请求帧为100%、响应帧为100%。 因此、TCU 成功发送、但有时会在 TX 之后马上错过 RX 消息。

2)有时请求消息也包含一些未知数据、如图2所示。  

是否知道导致此问题的原因？ 如果我们错过了什么,请告诉我们。

此致、

奈克·阿克谢

嗨、Akshay、

支持此问题的工程师目前已外出。 他会在下周再来回答您的问题。

此致、

插孔  

尊敬的 Jonathan：

在调试获取未知数据这一问题时、我发现存在一个全局滤波器配置寄存器(GFC)、其中接受不匹配的帧。 我们无法修改它、因为它 受写保护。  

有没有任何方法可以修改它、因为我认为这可能会解决获取未知数据的问题。

感谢你的帮助。

此致、

奈克·阿克谢

您好、Jack、

好的、感谢您告诉我。

此致、

奈克·阿克谢

尊敬的 Akshay：

当我离开办公室的时候,我为延误道歉。  

仅当控制寄存器 h1018中的 INIT 和 CCE 位设置为"0"时、受保护的寄存器才受写保护。

这可以防止在器件处于正常模式并主动参与可能导致通信错误的 CAN 通信时更改配置。

要更改受保护的寄存器、您必须首先将 INIT 和 CCE 位设置为"1"。  请注意、这也许需要几次寄存器写入来设定两个位、这是因为 CCE 位也要求 INIT 位为"1"、它也可以被设定为"1"。  因此、在 INIT 和 CCE 位都被设定为"1"时、对控制寄存器写入至少2次、然后将您的配置更改任何受保护的寄存器、然后在恢复正常操作之前、至少将 INIT 位设置回"0"。

正如您所提到的、拒绝任何未通过特定滤波器标准的消息将会阻止它们进入 RX FIFO、并且应该会减少中断次数以及 FIFO 溢出和丢失消息的机会。

您能否告诉我、在进行此 GFC 更改后您是否仍然看到其他问题？

此致、

乔纳森

尊敬的 Jonathan：

没问题。 Jack 已经告诉我有关您休假的信息。  

我将尝试上述方法、并告知您状态。 同时、我们的客户报告了另外一个问题、如下所述：

使用以下命令初始化 CAN2：

"IP link set CAN2 txqueuelen 100 up type can bitrate 500000 dbitrate 2000000 fd on"

在初始化 CAN2之后、如果我们尝试以2ms 或小于2ms 的帧间延迟来传输数据、则传输会停止、并显示消息  

"tcan4x5x spi0.0 CAN2：总线关闭"

"写入：没有可用的缓冲区空间"

只有当我们尝试给 txqueuelen 大约100或小于100时，才会发生这种情况。 但我尝试给 txqueuelen 大约25000和执行同样的情况,我没有遇到任何问题,如上所述和传输成功发生。

您能 指导我们解决哪些问题吗？

此致、

奈克·阿克谢

尊敬的 Akshay：

当其中一个 TX 或 RX 错误计数器超过 CAN FD 协议标准中定义的255时、会出现"总线关闭"情况。  这些错误帧通常指示总线上的某种信号完整性问题、或总线上发送节点和接收节点之间的位时序配置不匹配。  

当器件尝试发送消息并且总线上的另一个接收节点检测到错误时、该接收节点将抛出错误帧、这将导致发送节点中止消息传输并使发送器错误计数器(TEC)增加。  由于这条消息未成功发送、器件将其保留在 FIFO/队列中、并再次尝试重新传输、直到成功发送并从接收节点接收到一个应答(ACK)。  

由于您还会收到一条"写入：没有可用的缓冲区空间"消息、因此我认为这是因为 TX 缓冲区装满了等待传输的消息、因为该节点不断收到导致总线关闭情况的发送错误。

您可以检查错误计数器寄存器0x1040来读取 Tx 和 RX 错误计数器(TEC 和 REC)、以查看是否有错误、以及哪些节点获得 TX 错误、以及哪些节点看到 RX 错误。

我不知道队列长度会如何单独导致总线关闭状态。  相反、我知道传输错误如何阻止队列清空并保持填满。  我会验证总线连接并检查出现错误的原因、例如信号完整性较差、或者总线上的某个节点具有不同的位时序配置等。

此致、

乔纳森

尊敬的 Jonathan：

感谢您向我们介绍这个问题。

我们的一位客户尝试执行另外一个场景、如下所示：

CAN 初始化是在使用服务进行引导时完成的、如果向器件提供了 CAN 流量、则器件会挂起、有时无法完全引导。 当它完全启动时、在挂起之前、我通过提供 "顶部" Command 和我观察到 CAN 的中断增加了 CPU 使用量(如下图所示)、因为这导致性能大幅下降。

简单地说：如果在引导设备后执行相同的方案、则可以正常工作。

任何有关可能导致此问题的想法。

此致、

奈克·阿克谢

尊敬的 Akshay：

我不确定、我必须确切地了解启动序列期间在寄存器级发生的情况、但这些是我的想法。  

正确我、如果我的理解不正确、但我基本上理解您的问题、即 TCAN4550会在引导序列期间由于 CAN 总线活动而产生中断、这会减慢处理器速度并阻止器件正确引导。

如果控制寄存器(0x1018)中的 INIT 位设置为"0"、并且工作模式和引脚配置寄存器(0x0800)中的 MODE_SEL 位设置为"10"(对于正常模式)、TCAN4550将仅参与 CAN 总线活动(通过发送或接收消息)。  寄存器0x0800的脚注还通知当 MODE_SEL 位发生变化时、会自动设置 INIT 位。

器件的 MCAN 配置寄存器(例如位时序和 MRAM 分配)要求将 INIT 位设置为"1"、因此在 TCAN4550配置完成之前、MODE_SEL 字段应设置为"01"用于"待机模式"。  仅当 TCAN4550已完成配置或引导序列时、对于正常模式、MODE_SEL 字段才应设置为"10"。

您能否进行检查以确保 MODE_SEL 字段在整个引导序列中保持在待机模式、并且仅在序列结束时更改为正常模式？

此致、

乔纳森

尊敬的 Jonathan：

上述简报非常有助于解决我们的启动问题。

但我们还面临下列其他问题：

1)挂起问题：

 当我们使用提供的有效流量启动电路板、然后初始化 CANFD 时、它会开始接收数据。 但是接收只会持续几个小时(4到5个小时)、然后 TCU 再次挂起并重新启动。 我们还观察到、中断占用了前一个线程中共享的图像等大部分 CPU 使用量。 导致此问题的原因可能是什么？

2) 断开 CAN 链路时、TCU 挂起或复位：

我注意到、当 TCU 正在传输 CAN TX 消息时、从 CAN 总线的其余部分物理断开 TCU 会导致 TCU 自行复位或挂起。 有什么想法可能会吸引这一点吗？

3) 3)答案缺失：

我们测试的场景如下：

有2个 TCU 通过 CAN 总线连接。

• TCU1发送 ID 为0x31的5字节标头数据。 TCU2接收该数据并发送响应、如下一点所述。
• TCU1接收1个字节0x79作为步骤1的响应(由 TCU2发送)、也具有 ID 0x31
• 接收到数据后、TCU1 在 ID 0x31上发送4个完整的64字节/帧或总共256字节的帧。 TCU2接收该数据并发送响应、如下一点所述。
• TCU1接收1个字节0x79作为步骤3的确认(由 TCU2发送)、也带有 ID 0x31
• 尽可能快地重复1-4、直到更新完成、这个周期可运行几千次来进行大更新。 如果 TCU 在几秒钟后在步骤2或4中未看到响应、它应该会中止整个过程。 在对其进行测试时、我们会观察到某些消息丢失、并且在 candump 实用程序中看不到。 您能为我们提供相关指导吗？

很抱歉、我提出了很多问题。 您能否帮助我们尽快解决这些问题、因为这些对我们来说是非常重要的？

此致、

奈克·阿克谢

尊敬的 Akshay：

很高兴我能帮助您解决您的启动问题。

1)挂起问题：

TCAN4550可以生成大量中断、特别是针对接收到的每个消息生成一个中断。  如果您只关心特定的消息 ID、您可以过滤掉这些消息、允许设备丢弃任何未过滤的消息、并减少这些消息的中断。 您是否使用任何类型的消息 SID 或 XID 过滤？  在生成不必要中断的应用程序中、是否有任何您可以忽略的消息通信？

2)断开 CAN 链路时、TCU 挂起或复位：

我能想到任何 CAN FD 节点将自身从总线中移除的唯一原因是错误计数高、并且器件已进入 CAN FD 规范中定义的总线关闭状态。

3) 3)答案缺失：

收到数据后，TCU1在 ID 0x31上发送4个完整的64字节/帧或总共256字节的帧。 TCU2接收该数据并发送下一点所述的响应。

您能解释一下是在每个64字节帧后还是只在4个完整64字节帧完成后才有响应吗？  基本而言、我希望确保我了解它接收到的每个 TCU1帧是否有来自 TCU2的响应帧、或者在接收到来自 TCU1的4个帧后是否只有来自 TCU2的响应帧。

如果在从 TCU1接收到4个帧后 TCU2只有响应、这是如何触发的？  TCU2中是否有计数器对接收的帧进行计数、或对接收的总字节进行计数等？

当我把这个问题作为一个整体来思考时、我认为可能会有一些错误帧最终导致总线关闭和/或丢失数据。 或者、可能存在总接收数据的计数和确认方式方面的错误、这会导致 TCU 不再进行通信、例如一个 TCU 认为数据已完成、 另一个电源是等待更多数据来触发您提到的中止序列。  我只在推测、

是否有办法监视 CAN 总线错误计数器、以查看是否有一些增量错误计数最终导致总线关闭状态？

在确认之前、是否可以通过某种方法来验证 TCU2节点是否接收到正确的字节？

此致、

乔纳森

尊敬的 Jonathan：

请找到我的突出显示答案：

1)挂起问题：

您是否使用任何类型的消息 SID 或 XID 过滤？  在生成不必要中断的应用程序中、是否有任何您可以忽略的消息通信？

我们当前未使用任何 SID 或 XID 滤波。 我们只是读出 CAN 总线上的所有消息。

2) 断开 CAN 链路时、TCU 挂起或复位：

我将检查这一点、并告知您有关状态的信息。

3) 3)缺少响应  

您能否说明在每个64字节帧后还是仅在4个完整64字节帧完成后才有响应？如果在从 TCU1接收到4个帧后 TCU2只有响应、这是如何触发的？  TCU2中是否有计数器对接收的帧进行计数、或对接收的总字节进行计数等？

响应是在接收到4个完整的64字节帧之后。 我们开发了一个处理这种情况的应用。

是否有办法监视 CAN 总线错误计数器、以查看是否有一些增量错误计数最终导致总线关闭状态？

是的、我们有一个 PCAN 仿真器、使用它我们可以 跟踪错误计数。

如果您需要更多信息、请告诉我。

此致、

奈克·阿克谢

尊敬的 Akshay：

如果您不关心总线上的额外通信量、您可能需要创建消息过滤器来减少不必要的中断并释放处理器负载。

除了验证错误计数并检查已接收的正确字节数和帧外、我不知道还需要从 TCAN4550器件级别看什么。  

此致、

乔纳森

尊敬的 Jonathan：

感谢您的建议。 将尝试创建消息过滤器并测试方案。

下面列出了我还有一个问题：

我们已在 SPI 驱动器内部添加了时间戳读取、然后我们观察到每次传输之间的延迟为~0.9ms。

我们探测了 CS、CLK、MOSI 和中断引脚。 在探测中、我们观察到每0.8ms 发生一次中断、2个连续 CS 低电平与高电平之间的间隙为0.9ms (不是单一 CS 低电平与高电平之间的间隙、您可以看到 CS 线路流变为高电平与低电平、然后存在长间隙)。 我们还能够在接收侧每0.9ms 接收一次数据。 多个 也同时触发。 请参阅以下轨迹。

即使在触发多个时钟、CS 引脚后、也能在接收端接收到1个数据、并且中断会长时间保持高电平。 该预期中断是否会长时间保持高电平？

我们观察到、当 CS 变为低电平和高电平时、4字节数据正在传输。 是否可以在单个 CS 上传输超过4个字节、使其变为低电平和高电平。

我们观察到的一个更有趣的现象是、在没有传输任何数据的情况下、我们将从探测线路 CS、中断、时钟获取脉冲。 下面是它的线迹。

您能告诉我们这里可能会出现什么问题吗？

此致、

奈克·阿克谢

尊敬的 Akshay：

即使在触发多个时钟后，CS 引脚也能在接收端接收到1个数据，并且中断长时间保持高电平。 该预期中断是否会长时间保持高电平？

通过 SPI 写入清除了所有位后、将释放中断引脚。  根据 ISR 例程处理此问题的方式、它可能会导致中断线保持低电平、如图所示。 我看到在中断线为低电平时 CS 将低电平切换2到3次、这可能会导致 SPI 读取状态和中断寄存器、然后执行 SPI 写入以清除设置的位。  我们需要更详细地分析中断引脚为低电平时发生的 SPI 通信、我们可以更轻松地将逻辑分析仪连接到这些引脚以解码数据。

我认为中断线路可能会保持在低电平、直到完成清除中断所需的所有 SPI 读取和写入。

我们观察到，当 CS 变为低电平和高电平时，4字节数据正在传输。 是否可以在一个 CS 上传输超过4个字节，使其变为低电平和高电平。

是的、TCAN4550支持针对连续寄存器地址和 MRAM 存储器位置的多字 SPI 传输、例如一个 RX 或者 TX 缓冲器。  这样就无需为每个需要传输的数据字(或4个字节)发送一个地址、并且可以极大地提高效率。  这是通过将 SPI 序列的"length"字段设置为需要传输的数据字的数量来完成的。  数据表中的"读取"和"写入"图通过使用示例展示了这一点、其中长度字段设置为2、并在 CS 线路为低电平时传输总共8个数据字节。  要清除、长度字段表示需要传输的数据字的长度、不包括具有读取/写入操作码和地址及长度字段的数据字。

因此、您可以将长度字段设置为与 CAN 消息的总长度或需要读取或写入的连续寄存器相匹配、 只需提供与要发送的第一个数据字相对应的第一个寄存器或 MRAM 位置的起始地址。

如果位数(SPI 时钟周期)与根据长度字段预期的位数不匹配、则 TCAN4550将引发 SPI 错误。

我们观察到的一个更有趣的事情是没有传输任何数据，我们正在从探测行 CS、中断、时钟获得脉冲。 下面是对应的跟踪。

您所指的"脉冲"是否是与您监视的引脚附近布线的其他信号的串扰耦合？  我需要看到更多放大的波形以便进一步注释。  由于您的示波器设置为捕获多个 CS 周期、因此可能无法获得监控位级波形的分辨率、并且此示波器配置可能还会出现一些采样或混叠问题。  我还建议使用较小的水平分辨率(放大)配置查看波形、以便更好地查看所看到的脉冲是否。

此致、

乔纳森

尊敬的 Jonathan：

感谢您提供的信息。

您是否可以对 TCAN wrt SPI 的流程进行简要说明？

任何文档也会有所帮助。

此致、

奈克·阿克谢

尊敬的 Akshay：

我们有一份 TCAN45xx 软件用户指南 、其中包含了该器件的整体操作和配置。  它还包含一些有关如何发送和接收 CAN 消息的分步示例。  这旨在帮助解释具有裸机编码应用程序的器件、从而对操作器件所需的 SPI 流程有非常好的概述。  我首先要推荐这份文档。

此致、

乔纳森

尊敬的 Jonathan：

感谢您提供的信息。 它将对我们有很大帮助。

我们已从以下 GitHub 链接下载 m_can 驱动程序：

GitHub 链接: github.com/.../m_can

集成此驱动程序后、在运行此驱动程序时、我们面临分段故障问题。 您能告诉我们可能遇到了什么问题吗？

此致、

奈克·阿克谢

尊敬的 Akshay：

遗憾的是、我不是 Linux 开发人员、我的专业知识与 TCAN4550器件级相关。  我可以对有关器件配置设置的问题提供帮助、但对驱动程序本身的帮助不大。

TCAN4550本质上将 M_CAN IP 与 CAN FD 收发器集成、然后使用 SPI 接口包络所有这些内容。  某些 SPI 寄存器直接通过 M_CAN 传递、而其他寄存器用于 TCAN4550的其余部分、例如收发器模式控制、状态和中断等。

我的理解是、现有的 tcan4x5x Linux 驱动程序本质上是以相同的方式构建的、并将 M_CAN 驱动程序包装到全面控制器件所需的附加 SPI 寄存器。  为了提高效率、最近对此驱动器进行了一些修订。

此致、

乔纳森

尊敬的 Jonathan：

感谢您的快速回复。  

您能告诉我们可以在哪里发布 m_can 相关疑问吗？ 是否有支持机制、可以发布 m_can 的相关问题？

此致、

奈克·阿克谢

尊敬的 Akshay：

m_can 驱动程序向上流动到 Linux 内核、因此受到 Linux 社区的支持。  由于我不是 Linux 开发人员、所以我不知道在哪里向您提供此类支持、并且我对任何 Linux 支持论坛都不熟悉。

不过、如果您的问题与如何配置 M_CAN IP 或如何从概念层面进行操作更相关、我仍然可以帮助您解决这类问题。  对于 Linux m_can 驱动程序本身、我只是无法提供太多的帮助。

此致、

乔纳森

尊敬的 Jonathan：

我们非常感谢您的帮助。

下面列出了我还有一个问题：

• 我们已禁用 MCAN 驱动程序的环回和本地回声支持。 此后、当终端节点未连接到 TCAN 时、我们在"数据相位启用"中收到协议错误。 是这样吗？ 该误差是否与回送或回声有关？

此致、

奈克·阿克谢

尊敬的 Akshay：

这可能是因为 CAN 总线上没有额外的节点来"确认"正在发送的消息。  当控制器处于"回送"模式时、mcan 将自己发送的报文视为接收的报文、忽略确认错误。

此致、

乔纳森

尊敬的 Jonathan：

非常有帮助。

我们正面临一个未响应的问题。 具体情况说明如下：

我们将 PCAN 连接到 TCU、从 PCAN 我们将10000数据传输到 TCU。 但 TCU 只能接收大约7000个数据。 其余数据将丢失。 有任何想法可能会出现什么问题？

此致、

奈克·阿克谢

尊敬的 Akshay：

我想检查几个想法。

• 报文速率太快、处理器无法清除新报文、导致出现 RX FIFO 或缓冲区溢出、进而导致报文被丢弃
  • 这可能是最可能的事件。  尝试增大和减小消息传输频率、以查看接收到的消息数量是否分别增加和减少。  此外、如果您使用 RX FIFO、您可以监测中断寄存器中的 RF0L 或 RF1L 位来查看是否丢失消息。
• 消息会由于协议或信号完整性错误而生成错误帧
  • 除非使用 DAR 位禁用了自动重新传输功能、否则会导致报文尝试重新传输。  您可以监视错误计数器寄存器中的发送和接收错误计数器(TEC 和 REC)。
• 消息正在被过滤
  • 如果使用任何类型的消息过滤，请确保传送的消息包含将通过接收器过滤器的 ID。

此致、

乔纳森

尊敬的 Jonathan：

感谢您提供的信息。 非常有帮助。

我在64字节数据接收方面面临问题。 我观察到 CAN 接收的消息丢失了。  

只有在接收64字节的数据时才会观察到这种情况。 如果我尝试接收8字节的数据、没有问题。

对8个字节的接收进行了超过14小时的测试、没有观察到缺失的响应。 但是、当我尝试仅接收64字节的数据时、我观察到响应被错过了。

您能告诉我可能遗漏了什么吗？

此致、

奈克·阿克谢

尊敬的 Akshay：

如果我理解正确的话、您只有在有64字节数据有效载荷的情况下收到70%的消息。  是这样吗？

我们将 PCAN 连接到 TCU，从 PCAN 我们将10000个数据传输到 TCU。 但 TCU 只能接收大约7000个数据。 其余数据将丢失。 有任何想法可能会出错吗？

如果我的理解是正确的、那么我只能认为 CAN 消息传输之间的间隔有点太快了。  通过 SPI 在 TCAN4550之间传输64字节数据至处理器所需的时间比8字节更长。  这将导致器件需要更长的时间来确认 RX FIFO 中的消息、这可能会导致 RX FIFO 上溢条件和丢失消息。

您是否正在监视中断寄存器中的 RF0L 或 RF1L 位以查看消息是否丢失？  如果您设置了水印填充级别、RF0W 或 RF1W 将被设置。  此外、RF0F 和 RF1F 位应反映一个完整的 RX FIFO。  所有这些位都表明接收报文的速度超过了处理速度。

您是否能够调整 CAN 消息之间的时间间隔？  如果是这样、是否有区别、即增加消息传输之间的延迟是否会导致较少的消息丢失？  或者、无论传输间隔如何、您仍然会看到相同数量的丢失消息？

如果没有看到任何与 RX FIFO 级别相关的中断位、并且时序没有改变结果、则可能存在其他一些配置问题、以解释缺少30%的64字节消息。

此外、您测试中的消息是完全相同(即相同的 ID 和数据长度/值)、还是它们的 ID、数据长度和值不同？

此致、

乔纳森