[参考译文] TCAN4550：TCAN4550/Microchip PIC32 不发送 FD 数据包

您好、Sid G、

这是一个有趣的问题。  器件能够一直开始重复传输的唯一方式是总线静默且总线上没有其他器件处于正常工作状态。  如果 CAN FD 消息在不支持 CAN FD 的总线上发送、则非 FD 节点将看到 CAN FD 包含错误、并在 CAN FD 消息上发送错误帧。  最终、CAN FD 发送节点的发送错误计数器将超过最大限值、该节点将进入总线关闭状态并使其不再参与总线通信。  如果总线上只有两个节点、其中一个节点进入总线关闭状态、则另一个节点将发送到静默总线中、并允许它重复尝试发送消息、但永远不会接收到确认或错误帧。

验证 FD Operation Enable (FDOE) 以及控制寄存器 0x1018[9：8]中的比特率切换使能 (BRSE) 位是否都设置为“1"（“（假设（假设您也在 FD 消息上使用比特率切换）。

然后、还要验证标称值和数据位时序寄存器值是否相同、并且与寄存器 0x101C 和 0x100C 中的 CAN FD 消息比特率设置相匹配。  如果这些位不同、则器件不会正确地对这些位进行采样并生成错误。

我不知道您在 FD 消息中使用了多少数据字节、但要确保 TX 缓冲区元素有足够的空间来保存完整的数据消息长度。  Tx 缓冲区元素大小配置寄存器确定在存储器中为 TX 缓冲区元素分配了多少数据字节。  此设置应足够大、以保存最大的邮件；如果不确定、则应仅设置为最大 64 字节大小。  如果您没有分配足够的空间、那么您的处理器将覆盖一些可能导致错误的其他元素。

验证 TX 消息缓冲区元素是否为 FD 消息正确设置了 FD 格式 (FDF) 和比特率切换 (BRS) 位以及正确的数据长度代码 (DLC)。

假设您的器件具有相同的配置设置并且 TX 消息位格式正确、那么两个器件应该能够与传统 CAN 或 CAN FD 消息通信。  

如果可能、尝试读取和记录器件中断、状态和错误计数器寄存器、以确定器件的状态、以便确定导致当前情况的事件序列 (0x0820、0x0824 或 0x1050、0x1018、0x1040、0x1044)。

您还可以通过读取 TX FIFO/队列状态、请求挂起和传输发生寄存器 (0x10C4、0x10CC、0x10D8) 来监控 TX 消息传输。

我怀疑您会发现重复尝试发送消息的节点将“TX 缓冲区请求挂起“寄存器中的相应位设置为 1、而另一个节点将进入总线关闭条件、并设置控制寄存器 0x1018[0]= 1 中的 INIT 位。

除了数据表之外、我还推荐这两个指南以获取更多信息。

TCAN45xx 软件用户指南 （链接）

M_CAN 用户手册 （链接）

此致、

Jonathan

尊敬的 Sid：

感谢您提供配置代码、我没有看到任何明显的信息来解释为什么 FD 消息在经典消息时不起作用。

你确实说了一些引起我注意的事情：

我有一个示波器连接到总线捕获信号、我确实看到第一个帧发生了 ACK。 Ack 测量的宽度为 12us、但不会生成中断、并且消息开始重复、就像在总线关闭之前一样。

从代码中显示、标称位时间设置为 500kbps。  如果正确、则单个标称位周期为 2us。   

ACK 时隙仅为 2 位时间宽、它为 ACK 位提供一个位时间、为第二个位时间作为 ACK 定界符、始终为隐性。  这样就可以接收总线远端其他器件发出的 ACK 位（该 ACK 位可能在定界符脉冲期间到达）。

因此、使用 500kbps 时、ACK 位最多不应超过 4us。  但是、通过简单的设置、您应该会在消息末尾看到一个额外的 2us ACK 位。

我认为您看到的是“错误帧“、而不是“ACK"，“，它、它是 6 位时间后跟 8 个隐性位定界符。  CAN 协议将总线上发送的连续 1 或 0 的最大数量定义为 5。  如果正常数据需要超过 5 个连续的 1 或 0、控制器将向消息添加一个极性相反的“填充位“、接收节点将根据协议自动删除这些填充位。  

因此、6 个连续显性位将被视为错误、这就是特意将其用作错误帧的原因。  您对 12us 的测量恰好与 6 位错误帧 (6 位* 2us = 12us) 匹配。

当向消息抛出错误帧时、所有接收节点都会丢弃该消息、并且各种发送和接收错误计数器会递增。  这可能是为什么您没有收到新的消息中断、并最终根据错误计数器使节点进入总线关闭状态。

出现错误的最常见原因是导致采样错误的位时间配置不兼容。  有时、使用比特率切换时、如果实际采样点%不同、则会导致问题。  这是因为开关的比特率越快、消息中 BRS 位的采样点就越出现、具有不同采样点的节点会将速率切换视为位错误。  但这是一般性意见。

示波器上的标称位宽和数据位宽能否与您正在编程的位时间相匹配？  同时确保 PCAN-USB 具有相同的设置。

我知道您在收到 CAN FD 消息时遇到问题、但您也在将 CAN 或 CAN FD 消息从 TCAN4550 传输到 PCAN-USB 时遇到问题吗？

是否可以在消息发送或接收后读取协议状态寄存器和错误计数器寄存器 (0x1040 和 0x1044)、以获取有关检测到的错误类型以及调整了什么错误计数器的其他信息？

此致、

Jonathan

Jonathan、

  7 月 4 日,我不得不在一个充满家庭成员的小屋中度过两周的超时时间。 现在、我回来尝试对 FD 的情况进行解码。  我创建了一个可以在传统模式下通过 FD 总线发送的命令、 允许打印协议状态寄存器 (PSR) 和错误计数器寄存器 (ECR)。 我首先通过仅设置 CAN FD 位将传统消息转换为 FD 消息、然后发送导致总线错误的消息；复位总线并将消息转换回传统消息、然后再次发送该消息并读取 PSR reg = 0x0000708、ECR reg = 0x00201F00。 这次设置 FD 位、然后比特率开关通过 FD 总线发送锁定的消息、将消息转换回 FD。 将消息恢复为传统模式并发出、这次 PSR = 0x00000248 且 ECR = 0x00197E00。

  SID

尊敬的 Sid：

我希望你喜欢你的家庭假期和 7 月 4 日的假期！

PSR reg = 0x0000708、ECR reg = 0x00201F00

LEC= 3'b000 -->由于 LEC 已通过成功接收或发送而复位、因此未发生错误

DLEC = 3'b111 ->自上次读取寄存器以来无变化。  （当设置了 BRS 标志的 CAN FD 格式帧已无误地传输（接收或发送）时、应清除为 3'b000。）

当具有 CAN FD 格式帧时、该字段将清零
其 BRS 标志集已无误地传输（接收或发送）。

REC = 31

CEL = 16

PSR = 0x00000248、ECR = 0x00197E00

LEC= 3'b000 -->由于 LEC 已通过成功接收或发送而复位、因此未发生错误

DLEC = 3'b010 -->格式错误：接收帧的固定格式部分格式错误。

EW = 1 -->至少有一个错误计数器达到了 96 的 Error_Warning 限值

Rec = 126

CEL = 25

因此、您肯定是接收帧时出错、PSR 寄存器指示了格式错误、这意味着在位期间存在固定值的采样错误。

CAN 帧的以下元件被视为静态字段、因为它们的数据电平始终为隐性。

• CRC 分隔符
• 确认分隔符
• 帧结束字段
• Intermission Field

这些组件用于检查帧的一致性、并且当这些组件中的任何一个包含显性位时、都会检测到格式错误。

时钟容差和/或不同的位时序配置通常会导致这些类型的错误、但可能还有其他因素。  您之前提到已连接示波器、因此是否能够共享 CAN 消息和错误帧的示波器图？  当接收节点检测到错误时、应立即在总线上抛出错误帧、因此 6 位错误帧的位置可以帮助我们确定哪些静态位字段导致了错误。

您还提到过您使用的是 PCAN-USB 接口、我也可以使用这个工具。  您能否分享此工具的 PCAN 位时序配置设置？  

您是否还能分享在作为 FD 传输时导致错误的测试消息所用的特定 CAN/CAN FD 消息？  我可以尝试复制并检查错误。

如果可能、如果您可以对每个寄存器进行读回并将其作为简单列表提供、我也可以加载相同的 TCAN4550 寄存器配置。  这样我就可以使用与您相同的 PCAN 和 TCAN4550 配置。

此致、

Jonathan

Jonathan、

  PCAN 和 TCAN4550 均设置为标称 500K 位/秒、数据 2M 位/秒 TCAN 初始化文件已在之前发送、它随其开发包一起提供。 我从 PCAN 发送到地址 0x120 的数据是两个字节 0x1100、这是发送到远地点的命令来打印 PSR 和 PCR。 我向命令中添加了一条 FD 消息、在这种情况下、总线会锁定、就像它从 PCAN 发出一条 FD 消息一样。 我将从示波器上下载一张该消息的照片、希望它能很好地看到。

尊敬的 Sid：

如果我不清楚,我很抱歉。 我想问的是 PCAN 的实际位时序配置、包括时钟频率 (20MHz、40MHz 或 80MHz)、采样点百分比、TSEG1 TSEG2、预分频器、同步跳转宽度设置等、可创建 500K/2M 比特率的比特率。

由于比特率和采样点位置更快、CAN FD 应用对位时序配置和采样点更加敏感。  建议所有 CAN FD 节点具有相同的位时序配置、以确保在相同的位位置对这些位进行采样、并且如果使用 BRS、所有节点中会同时发生比特率切换。  比特率切换出现在消息中 BRS 位的采样点、如果采样点配置不同、或者 tq 的数量不同（由于时钟频率或预分频器不同）、则可能会发生采样和位错误。

由于 TCAN4550 和 PCAN 在“理论上“配置为同时接受传统 CAN 和 CAN FD 消息、因此我们需要排除位时序配置作为消息传输中出现位错误的原因、这需要对高级 500k/2M 说明之外的设置进行更详细的评估。

您提供的 TCAN 初始化文件包含 TCAN4550 的此信息、但能否验证 PCAN 是否配置了相同的值？

/*配置 CAN 总线速度*/
TCAN4x5x_MCAN_TCANNomTiming Nominal_Timing_Simple =｛0、0、0｝；//使用 40MHz 晶体进行 500k 仲裁 ((40E6 / 2)/(32 + 8)= 500E3)
TCANNomTiming.NominalBitRatePrescaler = 2；
TCANNomTiming.NominalTqBeforeSamplePoint = 32；
TCANNomTiming.NominalTqAfterSamplePoint = 8；

TCAN4x5x_MCAN_TCANDataTiming =｛0、0、0｝；//具有 40MHz 晶体的 Data_Timing_Simple FD (40E6 /(15 + 5)= 2E6)
TCANDataTiming.DataBitRatePrescaler = 1；
TCANDataTiming.DataTqBeforeSamplePoint = 15；
TCANDataTiming.DataTqAfterSamplePoint = 5；

[/报价]

如果您正在使用提供的 PCAN-View、则该设置允许您自定义配置。  

如果您按复制参数到剪贴板按钮、您将获得一串计时参数、如下所示。  此字符串也用于 PCAN USB 工具的其他接口方法、例如 SDK 等

f_clock=40000000、nom_brp=2、nom_tseg1=31、nom_tseg2=8、nom_SJW=8、data_brp=1、data_tseg1=15、data_tseg2=4、data_SJW=1

对于传输的消息、我是否使用以下消息信息正确理解您？

传统消息格式

具有 BRS 消息格式的 CAN FD：

位时序的另一个可能原因是晶体振荡频率超出规格。  晶体频率直接用于创建构成 CAN 位周期的时间量 (Tq)。  因此、如果晶体以不正确的频率振荡、CAN 位周期也会超出规格、这也可能导致采样误差。  在这个新的构建中、可能值得验证晶体振荡频率是否正确、并且多年来晶体或负载电容一直没有变化。

此致、

Jonathan

Jonathan、

  以下是与 您所示内容不同的峰值计时设置屏幕截图。

SID

是的、您的 Pcan 设置与我的设置相匹配、但有时我没有设置位速率开关、但出现同样的故障。

Jonathan、

  恭喜、当我匹配能够发送和接收 FD 数据包的设置时。 首先,我发现,我不能像你显示的屏幕上拉我认为你必须有一个更高版本的 pcan 视图,所以我更新了 pcan 视图,并能够做出更改,所以时间在 PCAN 侧是问题,不是主板或软件只是过时的工具。 非常感谢您的帮助。

  SID

Jonathan、

  还有一个问题、您认为我们系统的最佳时序设置是什么？ 到目前为止必须是 TCAN4550 的标准。

  SID

尊敬的 Sid：

很棒！ 很高兴我能帮助您解决这个问题。

理想的时序设置取决于总线和系统、这些设置要求通常由系统设计人员进行设置、以确保所有节点都以相同的或兼容的设置运行。  如本例所示、带有 BRS 系统的 CAN FD 中的采样点差异可能会导致问题、但如果未使用 BRS、则问题不大。

每条线束以及线束上节点的位置都会因在总线上传播的信号反射而产生不同级别的振铃噪声。  通常、建议采样点%接近位周期的末尾、例如>80%。  这在理论上允许由显性/隐性转换引起的振铃足够衰减、从而正确对该位的适当隐性或显性电平进行采样。  在确定特定系统的最佳设置时、需要考虑许多因素。  不同系统的最佳设置也可能不同。

您可以在网上找到一些已发布的文章和论文、这些文章和论文对该主题进行了更详细的讨论。  我知道的一个例子是 针对 CAN FD 位时序的建议 （链接）CAN in Automation (CiA) 新闻简报 1/2018 中的文章。  

一般而言、80%的采样点是一个很好的起点。  如果需要优化、使用较小的时间量子（或每位更多的时间量子和较小的预分频器）也可以进行更多微调调整。  但最终您将需要使用与您要使用的系统兼容的设置、因此我建议您尝试找到使用您的产品的任何标准或系统级要求、并尝试遵循这些要求、尤其是使用 BRS 时。

此致、

Jonathan