[参考译文] TCAN4550：TCAN4550

Akshay、

工程师已收到此帖子的通知、并将在 CST 2022年11月1日结束时作出响应。

此致、

Eric Hackett

您好、Akshay、

所有节点都使用单独的处理器、还是尝试使用多个具有相同处理器的 TCAN4550器件？  

通常、每个处理器节点都将通过单个收发器(TCAN4550)连接到 CAN 总线。  但是、我不清楚 TCAN4550器件是否连接到单独的处理器、而是好像它们位于同一个处理器上(至少是 A 和 B)、并且在控制 SPI 总线的器件上存在一些冲突。

如果它们位于同一个处理器上、则处理器器件配置出现错误、并且不同器件未使用单独的 SPI 总线。

如果它们位于单独的处理器上、您能说明哪个处理器节点(A、B 或 C)正在生成错误吗？  

此致、

Jonathan

器件(也称为节点) A、B 和 C 在同一 CANFD 总线中连接。 每个器件都有自己的主机处理器和 TCAN4550收发器。 主机处理器和 TCAN4550之间的 SPI 总线不与任何其他外设共享。

收发器 A 开始向节点 C 发送64字节长的 CANFD 有效载荷。观察到在节点 C 中接收到数据。然后并行收发器 B 也开始向节点 C 发送64字节长的 CANFD 有效载荷。它在收发器 A 和 B 中生成了给定的错误消息 内容。

tcan4x5x spi0.0 CAN2：_CAN_GET_ECHO_skb：错误！ 尝试访问 CAN_priv:：echo skb 超出范围(255/max 7) tcan4x5x spi0.0 CAN2：CAN_PUT_ECHO_skb：bug！ ECHO_SKb 被占用！

此外、第一个收发器 A 停止向节点 C 传输数据、但收发器 B 继续向节点 C 传输数据。观察到节点 C 仅从一个收发器 B 接收数据。有时、我们得到收发器 A 向节点 C 传输数据、 但收发器 B 停止向节点 C 传输数据

您好、Akshay、

我在器件级别支持 TCAN4550、这不是 Linux 支持论坛、也不是 Linux 驱动程序方面的专家。  但是、我可以帮助确定错误的根本原因。

节点 A 和 B 是否传输具有相同消息 ID 的消息？  应避免这种情况、因为它可能会在仲裁期间引起问题并生成消息错误。  您能否验证每个节点的 CAN 消息 ID 是否唯一？

此外、我是否正确地理解、如果只有1个节点(A 或 B)连接到节点 C、则可以无限期传输数据、而不会收到这种类型的错误、 只有当出现错误时、才会将第二个节点添加到总线？

错误是在第二个节点开始传输后立即发生、还是在错误出现之前一段时间内从两个节点传输的数据、如果是、该时间有多长？

您能否读取 TCAN4550器件上的状态寄存器和中断寄存器、以便我可以查看哪些故障位、RX/TX 错误计数器、RX/TX FIFO 级别等？

• h000C
• h0800
• h0820
• h0824
• h1018
• h1040
• h1044
• h1050
• h10A0
• h10A4
• h10ac
• h10B0
• h10B4
• h10C4
• h10CC
• h10D0

此致、

Jonathan

您好、Jonathan、

这些是您已经询问的寄存器值：

• h1018=300
• h1040=0
• h1044=300f
• h1050=1
• h10A0=9920001c
• h10A4=a1515
• h10AC=0
• h10B0=990a091c
• h10B4=0
• h10C4=20207
• h10CC=0
• h10D0=0

此致、

Akshay Naik

您好、Akshay、

您在 H1000至 h10FF 中提供的寄存器用于 MCAN 配置和状态寄存器。 我从您提供的 MCAN 寄存器中看不到任何与器件相关的问题、器件似乎没有收到高 TX/RX 错误计数、进入错误警告、被动错误或总线关闭状态、并且 TX/RX FIFO 未满。  

这些寄存器来自哪个节点？

您是否也可以提供其他寄存器？  这些是中断和诊断寄存器、可指示器件是否存在与 MCAN 控制器无关的问题、例如 SPI 错误。

• h000C
• h0800
• h0820
• h0824

您还可以就我提出的其他问题发表意见吗？

我的另一个问题是节点 A 和 B 是否也在同时接收消息、或者节点 A 和 B 是否仅发送消息、节点 C 是否仅接收消息？

谢谢、
Jonathan

您好、Jonathan、

将返回到您的寄存器相关查询。  我们观察到另一个观察结果、如下所述：

我们将数据从收发器(TCAN4550) A 传输到收发器(TCAN4550) C。同时收发器(TCAN4550) B 开始传输到收发器(TCAN4550) C。所有收发器都连接在同一总线上。

由于所有收发器都位于同一总线上、因此收发器 A 也会同时获取 RX 中断和 TX 中断。 由于收发器 B 在同一 CAN 总线上传输、RX 中断进入 A。 此时收发器 A 停止传输数据。 收发器 B 仍然继续传输数据。 我们在收发器 A 和收发器 B 中使用0 (零) ms 帧间延迟来传输数据。您能就此提出建议吗？

在收发器上传输数据时接收 RX 中断是否有问题？ 一次、接收和发送都是可能的？

此致、

Akshay

您好、Akshay、

我将参考以下文档、进一步讨论 TCAN4550如何发送和接收消息。  TCAN4550使用 Bosch 开发的 MCAN CAN FD 控制器 IP、 有关该控制器的更多详细信息、请参阅 MCAN 用户手册。

可在《TCAN45xx 软件用户指南》中找到一些示例的简单概述。

根据 CAN FD 标准协议和仲裁规则、当然可以与 TCAN4550同时发送和接收消息。  

当一条或多条消息被加载到发送节点的 TX 缓冲区中并且 TX 缓冲区添加请求(TXBAR)寄存器中的相应位置位时、TCAN4550将尝试在 CAN 总线上传输这些消息。  如果节点赢得仲裁(即具有最低的消息 ID)、则消息将在 CAN 总线上传输。  但是、如果节点丢失仲裁、TCAN4550将继续尝试、直到成功。

当一个节点没有主动发送消息时、它仍在接收在总线上传输的消息。  TCAN4550将传入消息 ID 与已保存的滤波器元素进行比较、如果它通过其中一个滤波器、则它将存储在该滤波器指示的 MRAM 存储器位置。  可以设置不同的滤波器来将特定的消息定向到不同的 RX 位置、例如 RX FIFO 0、RX FIFO1和专用 RX 缓冲器。  如果传入的消息 ID 未通过特定的滤波器、则根据通用滤波器配置(GFC)寄存器配置(0x1080)、它将被接受或拒绝。

TX 和 RX 缓冲区空间应该被分配在独立的非重叠存储器中、所以在发送和接收消息的同时没有冲突。  很明显、由于 CAN 不是全双工类型的总线架构、每次只能在总线上传输一条消息、 但"同时"是指 TCAN4550可以让 TX 消息排队等待发送、同时还可以接收和存储其他节点传输的消息。

我之前问过节点 A 和 B 是否使用单独的消息 ID 进行传输。  否则、可能会导致仲裁问题、两个节点可能会尝试同时传输具有相同消息 ID 的消息。  但是、如果两个节点的消息 ID 不同、 但一个节点的报文 ID 比另一个节点低、如果节点重复传输的帧间延迟很小或没有帧间延迟、则一个节点可能会阻止另一个节点根据仲裁成功发送报文。

我还询问并仍不清楚您是希望节点 A 和 B 仅传输数据、而只希望节点 C 接收数据、还是希望所有节点同时传输和接收消息。  如果不希望节点 A 和 B 仅传输而不接收来自另一个节点的数据，则应设置过滤器或常规过滤器设置以拒绝您不感兴趣的邮件。  这将防止节点在接收和处理不感兴趣的消息时浪费时间。  例如，您可以设置节点 A 来拒绝节点 B 发送的消息 ID，同样，节点 B 也可以拒绝节点 A 发送的消息 ID  

此外、您还可以在节点 C 中创建过滤器、以仅接收节点 A 和 B 发送的消息 ID、甚至将节点 A 发送的消息存储到 RX FIFO 0中、将节点 B 发送的消息存储到 RX FIFO 1中作为示例。  但您似乎没有配置任何滤波器元件、我建议您尝试在节点之间配置其中的一些元件、以处理在各个节点中生成的接收和中断。

如果节点 A 和 B 未使用唯一的消息 ID、则可能会产生错误、导致您看到的其他问题。

如果节点 B 使用较低的消息 ID 以不允许节点 A 赢得仲裁并发送消息的速率进行传输、这可能会解释节点 B 开始传输后节点 C 不接收节点 A 消息的原因。  您可以尝试通过控制寄存器(0x1018：14)的 TXP 位引入一个较小的传输暂停、该位置位时、开始下一次传输之间会产生2位延迟、以允许其他节点开始传输可能具有更高消息 ID 的消息。  您还可以尝试降低传输速率、以确保总线上有一些空闲时间、从而允许所有节点最终传输其消息。

此致、

Jonathan

您好、Jonathan、

我们非常感谢对我们的问题的详细解释。 谢谢 Jonathan。

正如您提到的消息 ID、我们使用来自收发器(TCAN4550) A 和收发器(TCAN4550) B 的不同消息 ID 进行传输、并且我们也在传输64字节有效载荷、而不会有任何帧间延迟。 节点 A、B 和 C 需要传输和接收。

我们观察到节点 B 阻止节点 A 成功发送消息、而节点 B 继续成功传输。 在这种情况下、我们停止了节点 B 的传输。即使节点 B 停止传输、节点 A 也无法发送数据。 您能不能建议这种观察的原因。

一旦节点被阻止、那么是否需要重置 TCAN4550才能再次成功传输？

正如您所建议的、 我们将通过控制寄存器(0x1018：14)的 TXP 位引入小发送暂停、并检查并更新您的状态。

此致、

Akshay

您好、Akshay、

我很高兴能提供帮助。  TCAN4550是一款需要了解和配置的相当复杂的器件、因此我将尽可能提供信息、以帮助减少解决所有问题所需的总体时间、 如果我们忽略了可能导致问题的线程中未分享的一些细节、也有助于激发更多想法。

一旦 TCAN4550将一条消息加载到 TX 缓冲器中并且 TXBAR 位被置位以启动发送过程、器件应该继续尝试发送这条消息、直到它成功、除非：

1. 控制寄存器(0x1018[6])中的禁用自动重发送(DAR)位置位。  当该位设置为1时、TCAN4550将尝试发送一次消息、无论成功与否、只发送一次消息。  根据您之前提供的寄存器值、该位设置为"0"、这是默认值、应导致器件自动重试失败的消息传输。
2. 控制寄存器(0x1018[0])中的初始化(INIT)位置位。  当该位置位时、禁止器件在 CAN 总线上发送数据。  
   1. 当器件更改为待机模式时、INIT 位自动置位
   2. 该器件接收到过多 CAN 错误并进入总线关闭(BO)条件(0x1044[7])。 当 TX 或 RX 错误计数器递增时、器件将首先进入被动错误(EP)(0x1044[5])、然后进入错误警告(EW)(1044[6])、然后进入总线关闭状态、将 INIT 位设置回"1"。  您可以尝试监视此寄存器和错误计数器寄存器(0x1040)、以查看器件是否由于总线上的其他节点活动而接收到错误。
   3. 接收到发送取消请求(0x10D4)

我目前无法想到会导致器件在正常运行期间停止传输的任何其他东西。  

但 TCAN4550不会以任何方式验证 MRAM 配置、因此如果 MRAM 存储器存在重叠部分(即 RX 和 TX 缓冲区重叠)、则 MRAM 数据可能会损坏。  简单地说、如果 RX 缓冲区与包含要发送的消息的 TX 缓冲区重叠、则在发送之前、新的 RX 消息可能会损坏 TX 消息。  

因此、最好计算 所使用的每种 MRAM 元素(TX 缓冲区、RX 缓冲区、TX 事件 FIFO、SID 和 XID 滤波器元素等)的起始地址和所需的字节数、并验证是否存在重叠段。  另请注意、如果器件一旦到达 MRAM 的末尾、就会回绕到 MRAM 的开头。  还应验证 MRAM 配置是否不超过可用的 MRAM 空间量。  

没有足够的 MRAM 来支持每种类型的 MRAM 元件的最大尺寸。  您必须确定应用所需的每种类型的 MRAM 元素的大小以及如何将其分配到 MRAM 空间中。

例如、忘记将 CAN 消息标头所需的字节添加到 TX/RX 缓冲区空间是一个常见的错误、它不仅仅是数据字段的大小。  这样的小错误会导致更难检测到问题、因此如果器件的 INIT 位未通过模式更改或 CAN 错误进行设置、则 MRAM 配置可能会出现问题。

此致、

Jonathan

您好、Jonathan、

我们在一条总线上连接了两个节点。 两个节点在同一总线上成功发送和接收数据、帧间延迟为19毫秒。 如果我们将帧间延迟减少到19毫秒以下、其中一个节点将停止传输。

是否有机会减少这种情况？

如果是、您可以告诉我们 如何减少。

此致、

Akshay Naik

您好、Akshay、

这对我来说已经开始听起来很重要、因为这可能是 SPI 接口的一个限制、并且无法在您需要的时间内获取处理器和 TCAN4550之间的所有 TX/RX 数据。  您的 SPI 数据速率是多少？您是否计算了通过 SPI 向 TX/RX 缓冲器发送完整 CAN 消息所需的总时间？  这将随消息的数据有效载荷大小、SPI 比特率、SPI 字节和事务之间的空闲时间等而变化

TCAN4550的 MCAN 控制器内部没有任何东西能够阻止它以较短的帧间延迟发送或接收消息、并且它符合 CAN FD 协议标准。  因此、我认为瓶颈在器件的 SPI 侧。

此致、

Jonathan

您好、Akshay、

很抱歉、我忽略了在我之前的帖子中添加改进建议。

TCAN4550能够进行多字 SPI 事务处理、通过相应地设置 SPI 标头字中的长度字段、可以在单个 SPI 事务中读取或写入多个连续的寄存器。  这减少了对包含地址的完整32位字的需求、该字将在每次寄存器读取/写入时进行传输、如果在多个寄存器读取/写入之间包含字间延迟、则将 SPI 时间缩短50%以上。

MRAM 存储器空间也是如此、与每个32位数据字和新存储器地址的多个 SPI 事务相比、可以在单个 SPI 事务中将整个 CAN 消息读取或写入 MRAM 缓冲器。

遗憾的是、我认为当前的 Linux 驱动程序使用单字 SPI 事务、在这方面效率不是很高。  但在这方面还有很大的改进空间。  目前正在开发的这款 Linux 驱动程序有更高效的版本、但这项工作尚未完成、预计将在今年(2022年)年底之前完成。  到目前为止、报告的改进将效率提高了20-30%。  一旦将其上传到内核中、这将提供一定程度的改进。  但是、您可能还可以在自己的平台上找到其他可以提高效率的领域。

我在器件级别支持 TCAN4550、而不一定在 Linux 级别支持、因此我不太熟悉所有 Linux 驱动程序如何与 TCAN4550配合使用。  但其他需要改进的方面可能来自处理器如何以及何时检索 RX 消息。  除了在每个 RX 消息上设置中断、在连续的 MRAM 存储器空间中拉取几个放置在 RX FIFO 中的 RX 消息可能更有效、从而进一步减少检索这些消息所需的总 SPI 时间。  有一个 RX FIFO 水线位可被置位、一个中断位可被用于这个目的(寄存器0x1050中的 RF0W 和 RF1W 也被复制并在寄存器0x0824中报告)。

将 SPI 数据速率提高到可支持的最快速率、并在处理器如何处理数据方面寻求额外的效率、也可以提高性能。

此致、

Jonathan

您好、Jonathan、

我们在2个节点之间同时发送和接收数据。  我们将在两个节点上的帧之间提供20ms 的帧间延迟。  传输将在一个节点中经过一段时间间隔后停止。 器件仍将接收数据、但无法传输。

除此之外、我们还从不同的 ID 接收数据、而我们没有传输这些 ID。 例如、我们使用 ID 111传输数据、但我们将使用 CAN ID 444接收一个数据。 传输最终将停止。

请告诉我们是什么导致了此问题？

此致、

Akshay

您好、Akshay、

在看不到器件的状态和配置位的情况下、很难说出到底是什么导致了问题。  您能否读取停止传输的节点上的器件寄存器、以便在出现此问题时查看器件中发生了什么情况？  我想看到的寄存器已经在这个线程中列出。

如果在一个节点中发生传输错误、器件可能会使自己无法参与降压通信。  但是、如果它仍然可以接收帧、但不能发送帧、那么这可能不是总线关闭状态。  但错误计数器和状态位将指示这一点。

器件还可能进入受限工作模式、在该模式下、它能够接收数据和远程帧并对有效帧进行应答、但不会在总线上发送数据、远程、活动错误或过载帧。  当处理器将控制寄存器中的 ASM 位设置为"1"时、或者当 TX 处理程序无法及时从消息 RAM 中读取数据时、器件可以自动进入此模式。  

该器件还具有总线监控模式、允许其接收有效的数据帧、但无法开始传输。  但这不是器件可以自动输入的内容、必须由处理器进行配置。

有关这两种模式的更多信息、请参阅先前 在此主题中链接的《MCAN 用户手册》。

您对接收 CAN ID 的第二个观察结果与您传输的 CAN ID 不同、这一点很有趣。  CAN ID 0x111和0x444之间的差异是2位的位移。  我不确定不会生成错误帧且满足有效帧不会生成错误标志并被丢弃的所有其他要求的消息中如何发生2位的位移位。  但是、这确实会导致可能的时钟问题。

由于这两个节点由两个独立的时钟源运行、因此它们必须足够接近不发生发送和接收错误的相同绝对频率、并且必须满足 CAN 标准中定义的时钟要求。  如果时钟频率相差太大、则发送位的位宽可能与在稍微不同的时钟频率下运行的接收节点预期的位宽不匹配、这可能导致接收节点在错误的位置对该位进行采样。

PLL 生成的时钟也容易出错、因为 PLL 频率在尝试保持锁定到基准时钟时可能会稍微漂移。  一些 PLL 具有窄窗口、可确保频率始终处于有效 CAN 频率容差窗口内、而其他 PLL 可能会漂移在有效 CAN 频率容差窗口之外。

您的时钟是如何提供给 TCAN4550器件的？  它们是使用晶体、还是由处理器或时钟发生器 IC 内的 PLL 生成？

在时钟问题之外、我不知道什么会导致您所报告的 ID 问题。  但是、由于传输停止、两个节点之间的时钟容差问题可能会导致足够的 RX 和 TX 错误、从而导致器件进入总线关闭状态。

此致、

Jonathan

您好！

请参阅以下器件寄存器读取

• h1018=300
• h1040=0
• h1044=300f
• h1050=3
• h10A0=9920001c
• h10A4=30a19
• h10AC=0
• h10B0=990a091c
• h10B4=0
• h10C4=40407
• h10CC=0
• h10D0=0
• h000C=8
• h0800=c80004a8
• h0820=40081
• h0824=0

我们  尚未启用控制寄存器中的 ASM 位。 我们提供40MHz 的外部晶振频率和20MHz 的 SPI 频率。

此致、

Akshay

您好、Akshay、

感谢您提供寄存器值。  

我注意到、您的中断寄存器显示看门狗超时(WDTO) 0x0820：18、这也设置了全局错误(GLOBALERR) 0x0820：7和全局电压、温度或 WDTO (VTWD) 0x0820：0位。  您的看门狗操作(WD_ACTION) 0x0800：17：16配置仅指示器件设置中断标志、如果引脚配置为反映 WD、则将该引脚拉低。  

我不知道看门狗超时是导致处理器停止传输的原因、还是您打算使用看门狗计时器。  但是、如果您使用看门狗计时器、那么该计时器未被触发的原因也可能是处理器停止传输的原因。

如果您不打算使用看门狗、则以将中断引脚保持在低电平为例、可能会导致处理器错过其他中断事件。  

您可能需要在禁用看门狗定时器的情况下再次尝试测试、以查看整体结果是否有任何变化。  这是通过将看门狗启用(WD_EN) 0x0800：3位设置为"0"来完成的。  我将注意到、默认情况下、它设置为"1"、但在启用第一个看门狗触发事件后、计时器不应启动。  因此、为了使您的计时器超时、您必须至少提供了一个触发事件。

如果您不想完全禁用看门狗计时器、您可能需要尝试增大计时器窗口。  通过看门狗定时器(WD_TIMER) 0x0800：29-28位、它当前仍设置为最短和默认值60ms。  它可以增加到600ms、3s 或6s。

我在寄存器中没有看到任何其他指示错误可能原因的东西、例如高 TX 或 RX 错误计数器。

我还将注意到、在所有工作条件下支持的最大 SPI 频率为18MHz。  在20MHz 下运行可能会起作用、但不能保证这一点。  可能存在一些与 SPI 相关的问题、例如设置和保持采样错误、该问题可能会破坏数据或无法设置寄存器或无法向存储器加载或从存储器读取 CAN 消息。  我没有看到报告任何 SPI 错误、但它可能会以某种方式说明您观察到的错误消息 ID。

您是否还可以将 SPI 频率降低至小于或等于18MHz、以供测试查看是否有任何变化？

此致、

Jonathan

您好、Jonathan、

我们在 Rx FIFO 中启用了25级水标记。 假设 RX FIFO 没有填满25个数据、在特定时间之后、将发生看门狗超时、并且它将读取可用的 Rx FIFO 数据。 我们将使用看门狗来实现此目的。 根据您的建议、我们禁用了看门狗并同时完成了传输和接收。 结果相同、传输在随机时间停止。 然后、我们通过将看门狗计时器更改为600ms、3s 和6s 进行了测试。 结果相同。 然后、我们使用各种 SPI 频率变化(<=18MHz)进行了测试。 结果相同。

此致、

Akshay  

您好、Akshay、

好的、感谢您对如何使用看门狗的阐述。  这是有道理的。

TX 缓冲区添加请求(TXBAR)寄存器 h10D0=0、这意味着没有设置为发送消息的 TX 消息缓冲区。  TCAN4550将只发送 TXBAR 中相关位设置为"1"的消息缓冲器。  

为了使 TCAN4550恢复发送、处理器需要将 TXBAR 寄存器 h10D0中的某些位设置为"1"。  由于我没有看到任何 TX/RX 错误被报告、因此看起来处理器可能不会提供连续传输的新消息。 或者有一些错误阻止 TXBAR 位被置位。  

但是、TCAN4550似乎工作正常、只要寄存器 h10D0等于0x0、我就不会期望它发送消息。

如何将处理器配置为持续向 TCAN4550 TX 缓冲器提供消息并设置相关的 TXBAR 位？  您能否验证这是否按预期工作？

此致、

Jonathan

您好、Jonathan、

我读取寄存器值01C0并接收到值0x7000D34。 这表示 TX FIFO 队列大小为7。 TX 配置寄存器表示发送 FIFO/队列大小可以达到32、但每当我将其设置为大于7时、都会遇到内核紧急错误。  

是否有什么想法导致此问题？

此致、

Akshay  

您好、Akshay、

虽然我不确定 Linux 驱动程序是如何进行错误检查的、但我怀疑您的 MRAM 设置已超过器件中可用的内存空间。  

TCAN4550只有2KB 的 MRAM 存储器、可根据您的要求进行分配和分区。  某些应用可能需要更多 RX FIFO 空间、而其他应用可能需要更多 TX FIFO 空间。  或者、某些处理器可能需要大量 RX 消息滤波器元件、以允许处理器仅接收和响应特定的消息。  

TCAN4550确实可以支持多达32个缓冲元件和一个 TX 事件 FIFO、该 FIFO 支持多达32个元件来跟踪成功的消息传输。 除了另外64个专用的 RX 缓冲元件外、还有两个 RX FIFO、每个 FIFO 还可支持多达64个缓冲元件。  该器件还可以具有多达128个标准 ID (SID)和64个扩展 ID (XID)滤波器元素。

但是、器件无法同时支持所有这些元素的最大数量、并且作为用户、您必须对 MRAM 空间进行分区并对器件进行配置、使分配不会重叠或超过可用空间。  TCAN4550中没有错误检查来验证您的配置、因此您必须确保配置正确。  TCAN4550需要大于17KB 的内存来支持每种类型元件的最大配置。  由于它只有2KB、因此您在进行配置时需要记住这一点。

每种类型的 MRAM 元件都有一个起始地址、元件数量或缓冲器、 TX 和 RX 缓冲区元素也有一个数据字段大小值、因此、如果仅使用8字节数据有效载荷作为示例、则不会浪费64字节的存储器。

我相信 Linux 驱动程序会将此内容抽象出来、并根据您要使用的元素数量来处理内存分配。  但您需要检查以确保它已正确完成此操作。  如果存储器段重叠、或者如果存储器超过可用的最高地址、器件将回绕到 MRAM 存储器的开头、并且它可以覆盖分配给其他类型元素的数据。

您应该验证并优化 MRAM 分配、然后查看错误是否消失。  需要注意的一些事项包括：

• RX FIFO 缓冲区大小应足够大、以跟上传入的消息速率、但不应过大。  
• RX 和 TX 缓冲区数据字段大小应设置为支持接收消息中包含的最大大小、该最大大小可能不是64字节。  使用64字节可以确保它们可以支持任何 CAN FD 消息、但这会为每个缓冲器元件分配64字节的存储器、此外还为每个元件中的消息标头分配所需的字节。
• 如果您只使用其中一个 RX FIFO、请检查这两个 FIFO 是否都未配置。
• 如果不使用 TX 事件 FIFO、它是否分配了可释放的内存？
• 等等

有关这些类型的 MRAM 元件的更多详细信息、请参阅 MCAN 用户手册。  这与我之前在本主题中与您共享的链接相同。  但是、本手册的第2.4.1节讨论了消息 RAM (MRAM)的分配、这是一个很好的资源。

此致、

Jonathan

您好、Jonathan、

您的回复对我们非常有帮助。

最初我们使用的是 Bosch，MRAM-cfg =<0x0 3 2 32 10 1 32 7>。 现在我们使用的是 Bosch、MRAM-cfg =<0x0 3 2 32 10 0 26 12>。 通过使用此功能、我们能够以更少的数据包间帧延迟同时进行长一段时间的传输和接收、但我们仍然面临着长时间后停止传输的问题。 还注意到数据丢失。

当我们计算出、新配置使用的 MRAM 总大小仅为2KB 中的0.54KB。 当我将 Tx 缓冲区大小增加到12个以上时、传输将最终停止。 类似地、当我同时增加 RX FIFO 1时。 您能不能告诉我们阻止了什么。 我们计划配置将近90%的 MRAM 以获得更好的性能。

此致、

Akshay  

Akshay、

感谢您在工程师外出度假期间的持续耐心等待。

此致、

Eric Hackett  

您好、Akshay、

当通信停止时、您是否仍然像以前一样遇到内核严重错误？  您是否还检查了 TXBAR 寄存器0x10D0以查看处理器是否设置了要发送的任何 TX 缓冲器？  我提出的原因是、之前返回的 TXBAR 寄存器值全为0、表示 TCAN4550没有启用 TX 缓冲器来发送。 只要 TCAN4550已启用 TXBAR 寄存器中的 TX 缓冲器、并且器件未处于总线关闭状态、TCAN4550就会按照 CAN 仲裁规则尝试发送消息。

我怀疑应用程序代码中可能会有一些东西在收到错误后阻止处理器启用 TXBAR 寄存器中的 TX 缓冲位。  您能否确认处理器在收到任何错误后将继续尝试发送新消息、并共享 TXBAR 0x10D0寄存器值以确保它是非零值？

如果在通信停止后 TXBAR 寄存器没有任何置位位位、那么这就像是应用软件问题的一个问题。  检查 TXBAR 寄存器应确认这是器件还是应用软件问题。

此致、

Jonathan

您好、Jonathan、

TXBAR 寄存器的值为0。

除此之外、我们还有几个问题、如下所示：
*在2个节点之间的同时传输过程中、可行的延迟是多少？
*如果传输意外停止、则在两个节点之间同时传输时、是否有任何错误指示方法可以帮助我们再次重新启动传输？

此致、
Akshay Naik

您好、Akshay、

如果 TXBAR 寄存器的值为0、则 TCAN4550没有使能发送的 TX 缓冲消息。  由于某种原因、处理器已停止尝试发送新消息。  这不是 TCAN4550器件问题、而是处理器代码中的问题、我在确定出现这种情况的原因时没有太多帮助。

[引用 userid="472709" URL"~/support/interface-group/interface/f/interface-forum/1166061/tcan4550-tcan4550/4467191 #4467191"]*在2个节点之间的同时传输期间，可行的延迟是多少？

我不能完全确定如何解释这一问题。

CAN 协议将 CAN 总线上消息之间的时间定义为"帧间间隔"(IFS)、等于3个标称位时间。  当两个节点尝试同时传输时、一个节点将赢得仲裁并开始传输其消息、另一个节点将在第一个节点的消息完成后等待3位时间、然后才能传输其消息。

但是、我想您可能会尝试问我、处理器在发送重复消息之间需要多大的延迟、以避免发送或接收溢出事件产生某种形式的错误或错过的消息。  如果是、则会因以下几个因素而异：

• 消息的长度(数据字段的长度可以是0-64字节)
• SPI 数据速率、字内间隔或 SPI 通信中的空闲时间、例如 SPI 驱动器在这些序列之间以较小的延迟将 SPI 字分成较小的8、16或32位序列
• 芯片选择信号变为低电平和 SPI 数据开始之间的时间、以及 SPI 数据结束后和芯片选择再次变为高电平的时间。
• SPI 读取或写入中的字数。  某些 SPI 驱动程序使用单字 SPI 写入和读取、需要一个包含要访问的寄存器或 MRAM 存储器单元地址的32位字。  但是、TCAN4550支持在单个 SPI 序列中对连续寄存器或 MRAM 存储器位置进行猝发写入和读取、该序列由 SPI 报头中的"Length"字段以及要访问的第一个寄存器或 MRAM 存储器位置的地址进行设置。  这种突发方法通过消除除第一个地址字之外的所有地址字来减少总体 SPI 通信、并可将 SPI 时间缩短近50%。  许多 SPI 驱动程序已经被写入以支持突发模式、但是您当前使用的 Linux 驱动程序可能只支持单字方法。
• 处理器生成消息、接收消息、检查中断以及响应中断所需的开销时间
• 处理器的执行和时钟速度
• 等等

通过在 SPI 信号上使用示波器或逻辑分析仪进行测量、可以更轻松地确定系统的速度。  发送一条消息并捕获为该消息传输的所有 SPI 数据。  这将为您提供传输单个消息所需时间的基本时间。  然后、您可以尝试从同一节点发送两条连续消息、以测量处理器的任何延迟或开销时间、需要考虑这些延迟。 同样、您也应重复接收消息的过程。

这将为您的系统提供更准确的计时、您可以使用它来计算系统中可以实现的最大消息速率以及您需要的消息之间的延迟。  这也将有助于指出如果时间看上去比预期的时间长的话可以改进的一些领域。

[引用 userid="472709" URL"~/support/interface-group/interface/f/interface-forum/1166061/tcan4550-tcan4550/4467191 #4467191"]如果传输意外停止，则在两个节点之间同时传输时，是否有任何错误指示方法可以帮助我们重新启动传输？

我不知道可用于此目的的错误指示、但可能需要执行一些操作。

第一个想法是监控一些其他与 TX 缓冲器相关的寄存器。  当通过置位 TXBAR 位使能一个新的消息发送时、器件将置位 TXBRP (0x10CC)寄存器中相应的 TX 缓冲请求挂起位。  成功完成传输后、这些位将被清零、器件将设置 TX 缓冲器传输发生 TXBTO (0x10D8)寄存器。  定期读取这些寄存器值将使您能够了解消息在传输过程中的状态以及是否有消息等待传输。  如果没有待处理的消息、这可能表示您的已停止传输错误条件。

有一个 TX 缓冲区传输中断使能 TXBTIE 寄存器(0x10E0)和一个 TX 缓冲区消除结束中断使能 TXBCIE 寄存器(0x10E4)、可用于在特定报文已发送时通知处理器。  没有新中断可能表示传输已停止、或者可以一对一的方式跟踪每个消息。

TX 事件 FIFO、可配置为跟踪传输事件并需要确认才能清除。  没有新的 TX 事件 FIFO 事件可能表示传输已停止、或者可以一对一的方式跟踪每个消息。

您之前提到过、您使用看门狗计时器进行 RX FIFO 监控、但您可以使用看门狗计时器监控传输。  如果在处理器每次尝试发送消息时清除了看门狗、则如果处理器停止尝试发送消息、您可以获得看门狗超时、然后您可以使用看门狗超时作为再次开始传输的指示。  这可能是看门狗的更好选择。

此致、

Jonathan

您好、Jonathan、

感谢详细的解释。 我们将对此进行检查。

同时、更新后的驱动程序是否有任何更新。 请在准备就绪前通知我吗？

此致、

Akshay Naik

您好、Akshay、

我知道当前版本上仍有测试在运行、以验证更新显示了对可实现且稳定的最大总线负载的改进、但我不知道它是否可供分发。  

我将为您检查最新状态。

此致、

Jonathan

您好、Jonathan、

更新后的驱动程序测试完成后 、您可以向我们分享驱动程序的最终版本。 同时、 是否可以在更新的驱动程序被测试时共享它、以便我们可以对其进行测试？  

此致、

Akshay

您好、Akshay、

我们与合同开发人员的下一次更新将于周一进行。  我将与他们核实可以分享的内容。  

此致、

Jonathan

您好、Jonathan、

我们正在浏览有关 TCAN 和 MRAM 配置的几个链接、我们需要对下面列出的几个问题进行澄清：

1) 1) MRAM 配置：

   * MRAM 配置的宽度为32位、可配置为最多4352个字、如下图所示：

   *但根据 TCAN4550数据表、此处提到2K 字节的 MRAM 可完全配置为用于 TX/RX 缓冲器/FIFO、如下图所示。        但是、如果我们观察到之前的图像、其大小可能大于 TX/RX 缓冲器/FIFO 的大小。 请就此进行解释。

提供了 M_CAN 用户手册的链接供您参考：
M_CAN UM： https://www.bosch-semiconductors.com/media/ip_modules/pdf_2/m_can/mcan_users_manual_v330.pdf

2) 2) TX 事件 FIFO：

   *您还可以向我们提供有关 M_CAN UM (图像1)中提到但未在中通知的 TX 事件 FIFO 的一些信息        TCAN 数据表如下图所示：

   *我们还将讨论下面提到的另一个 TI 链接、其中提到了 TX 事件 FIFO。 那么、您能否告诉我们要参考的文档、并为我们提供有关 TX 事件 FIFO 的更多信息。

TI 链接： www.ti.com/.../sllu270.pdf

3)文档

   *请与我们分享链接/文档、它可能会为我们提供有关水印液位、看门狗计时器和 MRAM 的更好信息                 配置。

此致、

Akshay

您好、Akshay、

首先、我们的驾驶员状态更新会议被推至本周的星期三、因此我还没有驾驶员状态更新。

1) 1) MRAM 配置：

关于 MRAM 配置问题、简单的答案是 MCAN IP 能够处理比 TCAN4550中嵌入的内存块更大的内存块。

MCAN CAN FD 控制器 IP 由 Bosch 开发、并获得 TI 许可使用。  它通常嵌入到微处理器、FPGA 等中、具有可使用的更大存储块。  TCAN4550是一款小得多的器件、只能支持2k 存储器。  因此、与 TCAN4550的存储器块中配置的地址相比、MCAN IP 能够支持每种类型的更多存储器元件的地址。

TCAN4550中也没有错误检查来检查的重叠块和总大小。  您需要验证配置是否正确、否则某些存储器单元可能会被意外覆盖、并导致难以调试的错误。  另请注意、如果 MRAM 配置超过2k 块、地址会自动回绕到块的开头。

对于如何为各种 TX/RX/Event Buffer/FIFO 和消息 ID 过滤器元素等配置2k 块、没有限制或要求  但它必须位于2k 块内。

2) 2) TX 事件 FIFO：

TCAN4550使用了 Bosch 开发的 MCAN IP、因此 MCAN 用户手册应视为 TI 发布的数据表和文档中信息的补充信息。  TI 参考此 MCAN 信息并复制其自身出版物中一些更重要的关键部分、但将所有信息复制到 TCAN4550数据表并不实际或可能。

TI 未对 MCAN 寄存器进行任何修改、因此 TCAN4550数据表和 MCAN 用户手册相互补充。  唯一的区别是在 TCAN4550中、MCAN 寄存器地址的偏移量为0x1000。  例如、CCCR (控制)寄存器在 MCAN 用户手册中的地址为0x18、在 TCAN4550器件中的地址为0x1018。

TI 文档中的 MCAN 信息更侧重于正确配置基本通信和设置。  但是、事件处理是应用程序中可能使用或不使用的更高级别方面。  许多应用程序不会尝试跟踪状态并为在总线上成功传输的每条消息记录时间戳、但某些应用程序可能希望这样做。  

有关 TX 事件处理的具体详细信息，请参阅博世 MCAN 用户手册的第3.5.8节。  我认为本文档非常清楚、如果使用 TX 事件 FIFO、器件将创建一个 TX 事件 FIFO 元素、其中包含每个成功发送的消息的详细信息、包括消息 ID、消息标记和时间戳。  第2.4.4节概述了这些 TX 事件 FIFO 元素。

使用此方法的一些原因是为了跟踪低优先级报文是否正在忙线总线上传输、而在这种情况下、较低优先级报文很可能会失去对较高优先级报文的仲裁。  

3)文档

我认为您已经看到了三个最重要的导入和相关文档。 但是、我们还提供了有关看门狗和时钟优化的应用手册、这些都是很好的资源。

TCAN4550-Q1数据表： https://www.ti.com/lit/gpn/tcan4550-q1

《TCAN4x5x 软件用户指南》： https://www.ti.com/lit/pdf/sllu270

M_CAN 用户手册： https://www.bosch-semiconductors.com/media/ip_modules/pdf_2/m_can/mcan_users_manual_v330.pdf

《TCAN4550看门狗配置指南》： https://www.ti.com/lit/pdf/slla455

TCAN455x 时钟优化和设计指南： https://www.ti.com/lit/pdf/slla549

此致、

Jonathan

您好、Akshay、

我有 Linux 驱动程序的更新、TCAN4550器件的更新已完成、并且我们有一些现有驱动程序的补丁文件、如果您想自行应用补丁、可以与您共享这些文件。  

目前正在对驱动程序进行一些额外的更新、以使其与我们仍在开发中的一些新器件兼容、这些更新预计将在2月底运行。  

完成这些更新后、所有更新都将更新并提供给 Linux 社区。  

如果您对修补程序文件感兴趣、请告诉我、我可以将它们发送给您。

此致、

Jonathan

您好、Jonathan、

感谢 Jonathan 的更新。

您可以向我们共享更新的驱动程序。 我们将对其进行测试、并告知您结果。

此致、

Akshay Naik

您好、Akshay、

我刚刚向您发送了一封包含补丁文件的电子邮件。  希望他们能为您服务

此致、

Jonathan

您好、Jonathan、

感谢您提供补丁文件。 我们将在驱动程序中更新它、一旦获得测试结果、我们将通知您。

对中断计时器有一些疑问、 如下所示：

• 我们认为看门狗可用超时为60ms、600ms、3s 或6sec。 是否有将其设置为低于该值的可能性？
• 以及您提到的所提供的补丁  
  • Rx-usecs-IRQ： 如果接收到的帧数小于 Rx-frame-IRQ，则在手动触发中断处理程序之前等待的微秒数。 一个小数将导致更多的中断处理程序运行。 大量数据将增加接收单个帧的延迟。
  • TX-usecs-IRQ： 与 Rx-usecs-IRQ 相同，只是在发送方向上。
•  Rx-usecs-IRQ、TX-usecs-IRQ 和看门狗计时器是否相同？ 因为根据解释、Rx-usecs-IRQ 或 TX-usecs-IRQ 的功能与看门狗定时器的功能相同。 如果不是相似的、您可以向我们简要介绍一下这些计时器吗？
• 但我们还观察到、在您提到的命令"Eethtool -C CAN0 TX-usecs-IRQ 40000 Rx-usecs-IRQ 40000 Rx-frames-IRQ 6 TX-frames-IRQ 10" 中、Rx-usecs-IRQ 似乎设置为40000、即40ms、小于看门狗定时器。  

请告诉我们是否有遗漏的东西。

此致、

Akshay  

您好、Akshay、

[引用 userid="472709" URL"~/support/interface-group/interface/f/interface-forum/1166061/tcan4550-tcan4550/4497706 #4497706")我们认为看门狗可用超时为60ms、600ms、3sec 或6sec。 是否有将其设置为低于该值的可能性？

否、60ms 是配置寄存器中可用的最短看门狗超时设置。

[引用 userid="472709" URL"~/support/interface-group/interface/f/interface-forum/1166061/tcan4550-tcan4550/4497706 #4497706"]

• 以及您提到的所提供的补丁  
  • Rx-usecs-IRQ： 如果接收到的帧数小于 Rx-frame-IRQ，则在手动触发中断处理程序之前等待的微秒数。 一个小数将导致更多的中断处理程序运行。 大量数据将增加接收单个帧的延迟。
  • TX-usecs-IRQ： 与 Rx-usecs-IRQ 相同，只是在发送方向上。
•  Rx-usecs-IRQ、TX-usecs-IRQ 和看门狗计时器是否相同？ 因为根据解释、Rx-usecs-IRQ 或 TX-usecs-IRQ 的功能与看门狗定时器的功能相同。 如果不是相似的、您可以向我们简要介绍一下这些计时器吗？
• 但我们还观察到、在您提到的命令"Eethtool -C CAN0 TX-usecs-IRQ 40000 Rx-usecs-IRQ 40000 Rx-frames-IRQ 6 TX-frames-IRQ 10" 中、Rx-usecs-IRQ 似乎设置为40000、即40ms、小于看门狗定时器。  

[/报价]

首先请注意、您参考的这些注释来自开发固件的承包商。  Rx-usecs-IRQ 和 TX-usecs-IRQ 不是像看门狗计时器那样的 TCAN4550器件级计时器、而是在驱动程序固件本身中实现的计时器。

为了优化 SPI 流量并提高整体效率、我认为添加了这些计时器来解决以下情况。

使用 TCAN4550中的 FIFO 水印阈值作为处理器通过 SPI 与 TCAN4550进行通信的 IRQ 的触发器、而不是为每个发送和接收的消息生成中断、可以减少 SPI 流量的总量、因为可能会有大量中断 并使处理器保持忙碌状态。  但是、如果 FIFO 元素的数量没有达到水线位、处理器可能需要等待很长时间才能发送或接收额外的消息、并触发 IRQ 来检查 FIFO。  这是不可取的。

为了防止这种情况发生、可以手动触发 IRQ 以强制读取 TX 事件、并且应定期启动 RX FIFO 以检查 FIFO 中是否存在低于水线限值的消息。  但是、这种情况的发生频率也会影响整体 SPI 效率、因为它需要 SPI 流量来检查新元素。

开发人员对 Rx-usecs-IRQ 和 TX-usecs-IRQ 的特定注释仅指示处理器在手动检查 FIFO 之前应等待多长时间。  "短"时间会导致大量额外的 SPI 流量、因为手动检查频率更高、 "长"时间将导致在 FIFO 中接收到消息与手动检查 FIFO 后处理器最终读回消息之间的延迟更长。

需要在水印等级和这些手动计时器之间建立平衡、以减少中断产生的整体 SPI 流量、并且在尚未达到水线位时不会等待太长的时间来接收 FIFO 中的消息。

此致、

Jonathan