[参考译文] TCAN4550：BRSE 位：写保护

您好、Akshay、

TCAN455x 软件用户指南中概述了设置 BRS 位的过程 、如果您尚未通读、这是一个很好的查看资源。  我在这篇文章中分享的图片来自本文档。

但是、基本来说、只有当器件处于初始化(初始化)模式时、才可以更改"受写保护"配置位、该模式在控制寄存器(0x1018)的 INIT 位设置为1时发生。  您还需要将配置更改使能(CCE)位设置为1、以允许设置这些位。  但是、为了使其被置位、INIT 位必须已经被置位为1。  因此、如果你需要将 CCE 和 INIT 位都设置为1、这可能需要对控制寄存器进行多次写入、以允许 INIT 位设置为1、然后第二次写入将允许 CCE 位设置为1。  然后、一旦 CCE 位被设置为1、所有写保护位都可以被设置、包括 BRSE 和 FDOE (FD 操作使能)位。  FDOE 位也需要置位以允许 CAN FD 模式、以便发生比特率切换。

只要设置控制寄存器中的 FDOE 和 BRSE 位、并不一定会导致所有 CAN FD 消息以 FD 格式和比特率开关进行传输。  这些位仅允许传输该格式的消息。

TX FIFO/缓冲元件头文件中的 FDF 和 BRS 位也需要设置为1、以便该消息以 FD 格式和比特率开关进行传输。

此致、

Jonathan

您好、Jonathan、

设置 CSR 位后、器件将变为待机模式。 但是、根据指令、必须将其清除、但当我尝试清除 CSR 位时、这种情况并不会发生。 根据用户指南中的指令、必须将其清除。 请告诉我们必须做些什么吗？

此致、

Akshay  

您好！

 以下是我们 的观察结果：

1) 1)测试配置和观察到的问题：

• 2TCU 连接到 PCAN。 PCAN 是发送器、其中一个 TCU1正在接收 PCAN 工具发送的数据。 在 TCU2中、CANFD 未初始化。
• 当 PCAN 工具在启用 BRS 位的情况下发送数据帧时、TCU1正在接收 CANFD 帧。 但在这种情况下、当我们在 TCU2中初始化 CANFD 时、会生成错误帧、并在 PCAN 工具中观察到错误帧。
• 但是、如果我们在 PCAN 工具中禁用 BRS 位的情况下执行上述相同的情形、那么我们不会在 PCAN 工具中观察错误帧。
• 下面给出了从带有 BRS 位的错误帧的 CRO 中获取的快照：

• 下面给出了从不带 BRS 位的 CRO 获取的快照：

2) 2)查询：

• 在冒烟之后和 iplink 之前、TCAN 在哪种状态下出现？ 它是处于待机模式还是正常模式？
• BRS 设置的错误帧的原因是什么？ 是否存在驱动程序问题？
• 错误帧是从驱动程序生成的吗？

3) 3)可能的解决方案：

• 我们在 论坛中询问了有关该驱动程序的另一个问题、我们正在等待该驱动程序的修复。 我们何时可以从第三方获得驱动程序修复？ 此查询供您参考(TCAN4550：在 tcan 模块的 insmod 期间生成的错误代码)。
• 在测量仪表中、驾驶员侧是否可以执行任何操作、以便我们可以从一侧查看。

此致、

Akshay

您好、Akshay、

1) 总线上的所有注释都应启用相同的设置和功能。  如果 CAN FD 帧在总线上传输、则所有节点必须启用 FD、否则未启用 FD 的节点将在消息上抛出和错误帧。  

同样、如果 FD 消息以更快的数据速率传输、则所有节点必须启用 BRSE 或等效位速率开关设置、并且必须具有相同的数据位时序设置。  否则、未启用 BRSE 或具有不同数据位时序设置的节点将在消息上投射错误帧。  

由于错误帧是在节点尝试与不同配置进行通信时生成的、因此根据 CAN FD 协议和标准、显示系统在该测试期间按预期工作。

2) 根据这个问题、我假设您是指 TCAN4x5x Linux 驱动程序。  这是一个器件支持论坛、我不确定驱动程序何时将 TCAN4550器件从待机模式转换为正常模式。  但是、TCAN4550始终上电进入待机模式。  只有当处理器将工作模式和引脚配置寄存器0x0800[7：6]中的 MODE_SEL 位置1并将其设置为正常模式(2'B10)时、它才会从待机模式转换为正常模式。

BRS 错误的原因是 CAN 总线上的所有节点的设置都不相同、因此它们能够以比仲裁速率更快的数据速率处理 CAN FD 消息。

错误帧是在器件级别生成的、因为 CAN FD 协议违反了总线上不同节点的不兼容设置。

3) 您引用的线程已分配给另一位工程师、但我只读了该线程。  TI 与第三方合作、通过优化 SPI 通信来消除空闲时间并提高数据带宽、从而改进 TCAN4x5x Linux 驱动器。  此驱动程序更新不是为了解决您面临的问题。

要解决在 TCAN4550转换为正常模式时生成的错误帧、必须首先确保控制寄存器0x1018[9：8]中的 BRSE 和 FDOE 位都设置为"1"、还必须确保标称(仲裁)位时序(寄存器0x101C)_和数据位时序 (寄存器0x100C)配置为与总线上其他节点相同的值、正如我刚才所解释的那样。  如果这些设置与总线上的其他节点不匹配、则会生成错误帧。

请注意、配置为支持具有比特率切换功能的 CAN FD 消息的器件不会在传统 CAN 消息(非 FD 消息)上投射错误帧 以及不使用比特率切换的 CAN FD 消息、因为消息标头专门指示节点消息是非 FD、FD 还是已启用 BRS。  

因此、对于 FD 操作、应启用 BRSE 和 FDOE 位、并针对总线上使用的适当数据速率设置 NBTP 和 DBTP 时序值。  这应防止在将器件切换到正常模式时出现错误。

此致、

Jonathan

您好、Jonathan、

感谢您的详细描述。 这解决了我们的问题。

但我们在延迟方面又面临一个问题、以下是观察结果：

1) 1)已使用 PCAN 工具连接 TCU。 已尝试在 PCAN 工具的每个帧之间以500ms 的延迟发送 CANFD 帧、并且数据正在 TCU 侧接收。

2)然后将 CANFD 数据帧之间的延迟降低至50ms、并且 正在接收数据。  

3) 3)将 CANFD 数据帧之间的延迟减小到2ms、并且在 TCU 侧接收到延迟。

4) 4)当我们将其减少到1ms 时、TCU 的数据接收停止、TCU 进入挂起状态。

5) 5)另一个观察结果是、如果我们直接将数据帧之间的延迟从500ms 减少到5ms 或2ms、我们会再次观察到挂起问题。

6) 6)我们还观察到、当数据帧之间的延迟为1ms 时、TCU 侧没有发生用于数据接收的中断。

我们希望在 TCU 上以50微秒的延迟接收数据。

请告诉我们导致这种情况的原因、并告知我们解决方案。

此致、

Akshay  

您好、Akshay、

我很高兴能帮助您解决 FD/BRSE 问题。

在短期内、您的延迟问题和观察结果将更难解决、因为这些是与系统相关的较大问题。  因为所有通过 TCAN4550进行的 CAN 通信也必须通过 SPI 总线、因此在确定可实现的最大消息速率时、需要将其视为一个因素。

MCU 驱动程序对消息的传输或接收速度有很大影响。  TCAN4550支持对连续寄存器或存储器位置进行多字 SPI 读取和写入、以减少为包含数据的每个单独存储器位置传递地址的开销。  减少 SPI 开销将减少不必要的位、从而缩短完成 SPI 写入/读取过程所需的总时间。  这将减少延迟并提高最大波特率。

此外、还需要考虑 MCU 如何检测新消息并做出响应。  中断位通常用于向 MCU 发出设备需要服务的信号。  一旦 MCU 读取中断寄存器以确定有新的 RX 消息、 然后、它将需要确定读取新消息的存储器地址、然后需要确认它已读取消息以释放新消息的存储器位置。  整个过程所需的时间会对最大波特率产生影响。

如果 MCU 无法以足够快的速度处理 RX 消息以防止 RX FIFO 或缓冲区填满、则器件将拒绝新消息或覆盖最早的消息(取决于器件的配置方式)并导致数据丢失。  这基本上是您在减少消息之间的空闲时间和停止接收中断时所面临的问题。  我会推测您的 RX FIFO 已满。

我相信您使用的是 tcan4x5x Linux 驱动程序、它是 mcan 驱动程序的打包版本、用于处理 SPI 通信。  正如我之前的帖子以及其他主题中提到的、此 Linux 驱动程序目前正由 TI 参与的第三方供应商进行更新。  电流驱动器仅使用单字 SPI 写入/读取、因此不是很有效、会限制可实现的最大波特率。  将重新写入此驱动程序以使用多字 SPI 写入/读取、并在 CAN 总线上支持更高的最大波特率。

此驱动程序开发计划在本月末开始。  唯一的临时解决方案是在开发新驱动程序的同时尝试对本地系统的驱动程序和系统代码进行一些优化。  

这是对您观察到的情况的解释、我希望我能有一个简单的快速修复方法来推荐给您。  但这是现有 Linux 驱动程序的电流限制。

此致、

Jonathan

Jonathan

您好、Jonathan、

如先前的答复中所述、我们何时可以期待这一更新的第三方驱动程序？

此致、

Akshay  

您好、Akshay、

该驱动程序目前正在开发中、我们预计驱动程序将在一个月或2022年10月上旬至中旬推出。  

此致、

Jonathan

您好、Jonathan、

感谢您的更新。

对于延迟测试、我们在 TCAN 驱动器中尝试了不同的水位标记。  

我们已将 RX FIFO 中的水线位设置为25。 在这种情况下、只有在 RX FIFO 填满25个数据后、才会在电路板中接收数据。

假设我们在 达到水线位之前停止发送数据、如果中断没有发生、那么我如何从其中读取未完成的缓冲区数据。

除 SPI 中断外、是否还有任何看门狗计时器中断选项可用？

此致、

Akshay

您好、Akshay、

有一些中断位可以使能、用于指示新消息已到达 RX FIFO/缓冲器、还有一些中断位用于指示已接收到一定数量的 RX 消息并已达到水线位。

如果我理解正确、您当前未启用 RXF0N、RXF1N 和 DRX 位来指示何时收到新消息。  相反、您仅启用了 RF0W 和/或 RF1W、以便在达到水线位时向您发出警报。

如果您依赖要生成的中断来读取 RX 消息、这是唯一的两个选项。  您可以针对每条新消息发出警报、仅在达到水线位时、或两者兼而有之。

器件中没有内部计时器或其他函数可用于提醒您收到低于水线位的新消息、这些消息已在指定时间内接收但未读取。  唯一的另一个选项是 MCU 读取 RX FIFO 状态寄存器、而新数据寄存器检查是否有新消息、这是一种软件轮询方法。

MCU 负责检查消息、您需要实施某种形式的计时器来轮询未达到水线位之前可能已收到的新消息。

此致、

Jonathan

您好、Jonathan、

是否对更新的驱动程序进行了更新？

此外、我在测试 CAN-FD 时还观察到了几个问题、具体如下所示：

1) 1)我们正在测试从 TCU 到 TCU 的数据传输。  

2) 2)当我们使用命令"cangen CAN2 -g 1 -b -D 00000000000000000000 -L 8 -I 555"将数据从一个 TCU 传输到另一个 TCU 时、我们观察到以下打印内容：

"tcan4x5x spi0.0 CAN2：在 TX 忙时调用 hard_xmit
tcan4x5x spi0.0 CAN2：在 TX 忙时调用 hard_xmit
tcan4x5x spi0.0 CAN2：在 TX 忙时调用 hard_xmit
写入：没有可用的缓冲区空间"

并且未从其他 TCU 接收到数据。

请告诉我如何解决此问题？

此致、

Akshay

您好、Akshay、

我对该驱动程序没有任何更新、因为预计该驱动程序将在10月初至中旬才可用。

我不是 Linux 专家、在器件级别支持 TCAN4550、因此我不熟悉驱动程序详细信息。  TCAN4x5x 驱动器基本上是社区中已经开发的 MCAN 驱动器的 SPI 包装程序。  但是根据错误信息、您似乎已经填充了 TX 缓冲区/FIFO。

当一条消息被写入 TX 缓冲器/FIFO 元素且该缓冲器的相应位被发送时、器件将尝试按照 CAN 协议在总线上发送该消息以进行仲裁。  成功发送报文后、缓冲元件将被清零并可用于新的报文。

因此、如果写入缓冲区空间用完、器件在总线上传输消息时会出现问题、要么总是仲裁失败、要么可能是其他原因。  

如果消息被成功发送、您可能尝试发送比总线支持的速度更快的消息、或者您需要启用更多 TX 缓冲区。  您可以在存储器 RAM (MRAM)空间中启用多达32个 TX 缓冲器元件。

您还可以在尝试发送新消息之前监视 TX 缓冲区/FIFO 的状态、以跟踪传输和可用空间。  我不确定如何通过 Linux 驱动程序执行此操作、但有多个状态、待处理和 TX 事件跟踪寄存器可用于此目的。

如果您有可用的 MRAM 空间、您可以尝试增加您配置的 TX 缓冲区元素的数量以创建额外的写入缓冲区空间。

此致、

Jonathan

您好、Jonathan、

   TCAN 驱动器可以通过 SPI 支持有关数据包间最小延迟的任何想法？

此致、

Akshay  

您好、Akshay、

这在一定程度上是特定于系统和驱动程序的、可能会因 SPI 数据速率和格式(单字与多字)、处理器速度、读取/写入消息之间的应用代码循环时间等而异 消息中的总字节数也会影响处理消息所需的时间。  我看到了很大的差异、因此我无法提供特定的数字。

我从另一个促使我们更新驱动程序的应用程序中看到、从 MRAM 缓冲器读取68字节消息(64字节数据+ 4字节标头)所需的时间大约为140uS、而当前的 Linux 驱动程序已知效率低下。  这涉及到等效的 SPI 时钟频率或大约4MHz 的吞吐量、即使 SPI 速率设置为16MHz。  这是由于整个 SPI 序列内的累积空闲时间。  

通过查看 SPI 总线、可以在示波器或逻辑分析仪上测量处理器在消息之间所需的时间。  您还可以测量处理消息所需的时间。  将这两个选项组合在一起、您就可以获得处理系统上的消息所需的全部时间。

TCAN4x5x 驱动器主要是围绕 MCAN 驱动器的 SPI 包装器。  SPI 驱动器的低效率是驱动器更新的主要重点、但我不知道 MCAN 驱动器的低效率是否也会得到改善。

一旦新驱动程序可用、速度和吞吐量就应该大大提高。

此致、

Jonathan

您好、Jonathan、

感谢您的快速响应。

我们计划在 tcan 驱动程序中添加 WDT 中断。 WDT 中断是否也是与水印中断相同的 SPI 中断？

此致、

Akshay