[参考译文] TCAN4550-Q1：CAN 收发器发送/接收消息

您好、Leon、

SPI 写入时返回的全局状态字节为0xA0、这会显示正在设置 CAN 错误(CANERR)位。  这是中断寄存器0x0820中 CAN 静音(CANSLNT)和 CAN 卡在显性(CANDOM)位的逻辑或。  您应该读取该寄存器来确定哪个位负责设置 CANERR 标志。

请注意、如果 CAN 活动(隐性到显性转换)的时间超过大约1秒、CANSLNT 位将置位。

我不确定您是否仅为我提供一些 SPI R/W 信息以询问有关 CANERR 的问题、但您提供的第二次写入显示了长度字段为4个字、但没有任何数据。  对于长度字段4、您应该在写入和读取中有一个额外的16字节数据。

此致、

Jonathan

你(Jonathan)好

"`m、我没有充分表达自己的意思。 在 调用  函数  Init_CAN 之后、我遵循 TCAN 演示 、如图中所示：  

寄存器0x0820显示数据(R：0x00 0x00 0x04 0xa0)、该寄存器为  CANSLNT。  

ClearInterruptsAll
W：0x61 0x10 0x50 0x01 0xff 0xff 0xff 0xff 0xff 0xff
R：0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
W：0x61 0x81 0x74 0x04
R：0xA0 0x00 0x00 0x00
W：0x05 0x10 0x00 0x00
R：0x00 0x00 0x00 0x00
W：0x00 0x38 0x00 0x00
R：0x00 0x00 0x00 0x00
W：0x88 0x77 0x66 0x55
R：0x00 0x00 0x00 0x00
W：0x00 0x00 0x00 0x00
R：0x00 0x00 0x00 0x00
W：0x41 0x08 0x20 0x01
R：0xA0 0x00 0x00 0x00
R：0x00 0x00 0x04 0xa0
W：0x61 0x81 0xbc 0x06
R：0xA0 0x00 0x00 0x00
W：0x04 0x8c 0x00 0x00
R：0x00 0x00 0x00 0x00
W：0x00 0x3a 0x00 0x00
R：0x00 0x00 0x00 0x00
W：0x44 0x33 0x22 0x11
R：0x00 0x00 0x00 0x00
W：0x00 0x00 0x00 0x00
R：0x00 0x00 0x00 0x00
W：0x00 0x00 0x01 0x23
R：0x00 0x00 0x00 0x00
W：0x00 0x00 0x00 0x3a
R：0x00 0x00 0x00 0x00
W：0x61 0x10 0xd0 0x01 0x00 0x00 0x00 0x02
R：0xA0 0x00 0x00 0x00 0x00 0x00 0x00 0x00
W：0x61 0x10 0xd0 0x01 0x00 0x00 0x00 0x01
R：0xA0 0x00 0x00 0x00 0x00 0x00 0x00 0x00

和独木舟接收帧如下所示：

寄存器0x0830显示 当我写入 Tx 缓冲区时 CANSLNT 被禁用。

W：0x41 0x08 0x30 0x01
R：0xA0 0x00 0x00 0x00

尊敬的 Leon：

如果在大约1秒内没有 CAN 活动、CANSLNT 位将被置位、这可能表示存在诸如电线断开或切割等错误  一旦活动恢复、该位应被清除。

填充错误可能来自 TCAN4550和 CAKE 设置之间的位时序配置差异。  请确认 TCAN4550的设置与独木舟配置的设置相匹配。  此外、确保总线没有其他物理问题、并且两端都有终端电阻器。  CANH 和 CANL 之间的总线电阻总共应为60欧姆。

如果位时序和采样位置设置不同、或者 CAN 总线存在某种程度的问题而降低信号完整性、则可能会出现采样问题。

但是、填充错误是指检测到6个或更多具有相同值的位、这是协议所不允许的。  代码中的数据数组应该会防止这种情况发生、或者器件应该在需要时自动插入一个填充位。  因此、如果器件正常工作、并且位时序正常、则如果数据具有6个或更多的连续1或0、则应插入一个额外的位、以防止出现此错误。

您是否可以捕获 CANH 和 CANL 波形、以便我们可以看到在您传输消息时器件产生什么？

此致、

Jonathan

你(Jonathan)好  

我使用示波器来测量 CANL 和 CANH 的电压范围。当我发送一条消息时、 CANL 和 CANH  的电压范围为2.0V - 2.8V。

I 写入 Tx 缓冲区、如下所示：

我 通过逻辑分析捕获 CANH 和 CANL 波形。 但数据非常 奇怪。  它几乎始终为1

CAN 帧解码器：

e2e.ti.com/.../decoder_2D002D00_240605_2D00_163127.txt

Error Corrected： I 使用示波器测量 CANL 和 CANH  的电压范围时、当我发送一条消息时、 CANL 和 CANH  的电压范围为2.0- 2.8V。

 CANL 和 CANH 为2.0V 至2.8V。 它是上电后的电压、而不是  发送消息。

当我 发送一条消息时、 示波器  会捕获 CANH 和 CANL 波形、如下所示：

尊敬的 Leon：

您能否为我提供您的代码配置 TCAN4550的所有寄存器值的寄存器转储(读回值)、以便我可以查看最终的器件配置？

是否尝试发送全部为0xFF 字节的数据有效载荷？  演示代码中的数据缓冲区数组没有0xFF 字节、也不传输64字节帧、所以我想验证 CAN 消息的预期值是多少？  您是否能够在发送之前读回 TX 消息缓冲器的内容、以便将其与您想发送的内容进行比较？

TX 缓冲区中用于您尝试传输的消息的字节是多少？  我想确认所有位都正确。

如果 TX 缓冲区中的任何内容存在差异、则我们可能无法发送有效的 CAN 帧、或者我们可能存在地址问题并尝试从不同的 TX 缓冲区发送消息。

另一个很好的调试工具是使用逻辑分析仪将 SPI 读写通信捕获到日志中。

此致、

Jonathan

Jonathan、您好！

您可以 通过 file_log.txt 查看最终的器件配置。   

2.我 不是   尝试用所有的0xFF 字节发送数据有效负载、我尝试两个消息：

    uint8_t data[8] = {0x55, 0x66, 0x77, 0x88};     // Define the data payload
    header.DLC = MCAN_DLC_8B;                       // Set the DLC to be equal to or less than the data payload (it is ok to pass a 64 byte data array into the WriteTXFIFO function if your DLC is 8 bytes, only the first 8 bytes will be read)
    header.ID = 0x144;                              // Set the ID
    header.FDF = 1;                                 // CAN FD frame enabled
    header.BRS = 1;                                 // Bit rate switch enabled
    
        /* Let's make a different CAN message */
    data[0] = 0x11;
    data[1] = 0x22;
    data[2] = 0x33;
    data[3] = 0x44;                                 // Define the data payload
    header.DLC = MCAN_DLC_16B;                       // Set the DLC to be equal to or less than the data payload (it is ok to pass a 64 byte data array into the WriteTXFIFO function if your DLC is 8 bytes, only the first 8 bytes will be read)
    header.ID = 0x123;                              // Set the ID
    header.FDF = 1;                                 // CAN FD frame enabled
    header.BRS = 1;                                 // Bit rate switch enabled
    header.EFC = 0;
    header.MM  = 0;
    header.RTR = 0;
    header.XTD = 0;                                 // We are not using an extended ID in this example
    header.ESI = 0;                                 // Error state indicator

3. 发送前 TX 消息缓冲区的内容:   

W：0x41 0x81 0x74 0x24

TX 缓冲区数据、星型地址：0x8174
R：0xA0 0x00 0x00 0x00
R：0x05 0x10 0x00 0x00
R：0x00 0x38 0x00 0x00
R：0x88 0x77 0x66 0x55
R：0x00 0x00 0x00 0x00
R：0x00 0x00 0x00 0x00
R：0x00 0x00 0x00 0x00
R：0x00 0x00 0x00 0x00
R：0x00 0x00 0x00 0x00
R：0x00 0x00 0x00 0x00
R：0x00 0x00 0x00 0x00
R：0x00 0x00 0x00 0x00
R：0x00 0x00 0x00 0x00
R：0x00 0x00 0x00 0x00
R：0x00 0x00 0x00 0x00
R：0x00 0x00 0x00 0x00
R：0x00 0x00 0x00 0x00
R：0x00 0x00 0x00 0x00
R：0x00 0x00 0x00 0x00
R：0x04 0x8c 0x00 0x00
R：0x00 0x3a 0x00 0x00
R：0x44 0x33 0x22 0x11
R：0x00 0x00 0x00 0x00
R：0x00 0x00 0x01 0x23
R：0x00 0x00 0x00 0x3a
R：0x00 0x00 0x00 0x00
R：0x00 0x00 0x00 0x00
R：0x00 0x00 0x00 0x00
R：0x00 0x00 0x00 0x00
R：0x00 0x00 0x00 0x00
R：0x00 0x00 0x00 0x00
R：0x00 0x00 0x00 0x00
R：0x00 0x00 0x00 0x00
R：0x00 0x00 0x00 0x00
R：0x00 0x00 0x00 0x00
R：0x00 0x00 0x00 0x00
R：0x00 0x00 0x00 0x00

MRAM 配置：

e2e.ti.com/.../File_5F00_log.txt

尊敬的 Leon：

我会查看您的寄存器配置信息、然后跟进我的任何其他问题和建议。

此致、

Jonathan

尊敬的 Leon：

很抱歉耽误你的时间、但是我检查过您的寄存器配置。  

我注意到您要将发送延迟补偿偏移(TDCO)设置为0xE、而将发送延迟补偿过滤器(TDCF)设置为0x0。  

通常、最好始终将 TDCO 和 TDCF 设置为相同的值。  TDCF 值设置 CAN FD 位中的最小二级采样位置(SSP)、如果该值为低电平、则 TDCO 位置将不会正确设置 SSP、从而可能导致位错误。

看起来是在传输消息、并且 CANH 和 CANL 的电压电平看起来是正确的。  您共享的信号部分看起来与许多连续数据位一致、这些数据位需要添加周期性填充位。  但信号不足以让我准确确定我在查看 CAN 消息的哪一部分。

我对寄存器配置进行解码、使标称数据速率为500kbps、数据速率为2Mbps。  这是你的意图吗？  在消息传输过程中是否看到更快的比特率？

我回顾了该主题、我不清楚我们要尝试解决什么问题。  您的问题是否仅与 CANERR 位被置位的原因有关、或者是否存在其他阻止您发送和接收消息的问题？  

您能否重申需要解决的具体问题？

谢谢！

Jonathan

你好、Jonathan。

"我对您的寄存器配置进行解码、标称数据速率为500kbps、数据速率为2Mbps。  "那你打算怎么办?"

是的、我的 目的是 对500kbps 标称数据速率和2Mbps 数据速率进行配置。  

我的主要问题是、我希望我的代码在开发板上运行、以实现 CAN 消息的 传输和接收。  

现在的问题是、我配置了硬件并根据 TCAN 演示代码写入 Tx 缓冲区、但发送到总线的消息始终具有强大的 CNA 错误。 我不n`t 问题在哪里。

我注意到您要将发送延迟补偿偏移(TDCO)设置为0xE、而将发送延迟补偿过滤器(TDCF)设置为0x0。  

将 DCO 和 TDCF 设置为相同的值后、CANOKE 测试出现填充错误。

我 根据 TCAN 演示代码发送了消息、但 捕捉 CANH 和 CANL 波形很奇怪。  大多数都是1 (隐性)。  

我不知道接下来该怎么做。

此致、

Leon

尊敬的 Leon：

谢谢、我现在对整个问题有了更好的了解。  我将指出另外两个您可能已经或尚未看到的有用文档。

TCAN45xx 软件用户指南

MCAN 用户手册

好的。  首先、您能告诉我您正在使用哪款开发板吗？  它是由 TI ( TCAN4550EVM 或 BOOSTXL-CANFD-LIN)创建的吗？

您能否验证 CANH 和 CANL 之间 CAN 总线两侧是否有120欧姆端接？

Unknown 说：

将 DCO 和 TDCF 设置为相同值后、独木舟测试出现数据错误。

这是否意味着在 TDCO = 14时将 TDCF 设置为0时没有收到 CAN 错误？  或者、无论 TDCF 设置如何、您仍然收到错误吗？  当它们设置不同时、我通常会看到 CAN 错误、但当它们设置为相同的值时则不会看到。  所以误差的原因可能与 TDCO/F 设置无关。  但是、这很重要、因为如果设置不正确、会导致错误。  《MCAN 用户手册》详细介绍了这两个设置如何创建辅助采样点。

您是否已验证独木舟位时序是否与 TCAN4550配置相匹配？  如果位速率相同、但所用时间份额数不同、并且采样点在位周期中处于不同位置、则 CAN FD 报文中可能存在位错误。  这是因为从标称比特率切换到数据比特率发生在消息中 BRS 位的采样点。  如果节点之间的采样点不同、则一个器件可能会在另一个器件就绪并生成错误之前切换到 FD 模式。  因此、始终建议 CAN 总线上的所有节点采用相同的设置。

您是否可以接收来自独木舟的消息而没有错误、或者在尝试接收消息时是否也收到错误？  我们需要检查 RX 消息和 TX 消息是否都产生了错误、或者仅针对一个方向产生了错误、以便我们可以找到根本原因。

您能否提供正在传输的整个 CAN 消息的示波器图？  由于 CANH 和 CANL 是差分的、因此最好在示波器上具有相同的 GND 参考位置、这样波形就会正确对齐、而不会出现分离。

您是否还可以在测试期间监控或记录以下寄存器、以便我们具体查看设置了哪些中断、状态和错误计数器位？

0x0820 -器件中断

0x0824或0x1050 - MCAN 中断

0x1018 -控制寄存器(监控 INIT 位)

0x1040 -错误计数器寄存器(CAN 发送和接收错误计数器)

0x1044 -协议状态寄存器(CAN 特定状态信息、包括错误代码)

0x10A4和0x10B4 - RX FIFO 0和 RX FIFO 1状态寄存器

0x1098和0x109C -新数据寄存器(如果使用专用 RX 缓冲区)

0x10C4 - TX FIFO/队列状态寄存器

0x10CC - TX 缓冲区请求待处理(查看消息是否处于待发送状态)

0x10D8 -发生了 TX 缓冲区添加请求传输(查看消息是否成功发送)

在调试期间监控这些寄存器值将有助于查看设置了哪些位和失败了哪些位。  如果消息收到 CAN 错误、则查看错误代码可以告诉我们它是什么类型的错误。

如果错误过多、器件会处于错误警告、错误认可和总线关闭状态之间。  您可以通过将 Control 寄存器中的 DAR 位置为禁用自动重新发送功能、从而减慢此过程、以便当寄存器0x10D0中的 TX Buffer Add Request 位置位时、器件仅尝试发送一次消息。

此致、

Jonathan

当我 在 Control 寄存器中设置 DAR 位来禁用自动重传：

e2e.ti.com/.../DAR_3D00_1.txt

尊敬的 Leon：

感谢寄存器数据。  中断寄存器中的 PEA 位表明当使用标称位时间时、仲裁段中存在协议错误。  

最后一个错误代码值是5 - Bit0Error。  在消息(或确认位、活动错误标志或过载标志)传输期间、器件想要发送一个显性电平(数据或标识符位逻辑值为"0")、但监测到的总线值为隐性。

发送错误计数器显示了很多错误、这些错误继而导致总线关闭状态、在这种状态下器件会使自己不再在 CAN 总线上进行通信、并将控制寄存器中的 INIT 位重新设置为1。  第一条日志显示总线关闭情况、该情况可能源于器件反复尝试发送消息、导致每次尝试失败后产生新的传输错误。

第二个日志是当您禁用自动重新传输时、它显示存在传输错误、但不足以进入总线关闭状态。

因此、物理 CAN 总线可能出现问题(例如端接不正确、接线不正确等)、或节点上器件之间的配置可能出现问题(例如不同的位时序配置等)

可能会产生问题的一个问题是标称比特率与更快 CAN FD 数据比特率之间的切换。  现在、您是否能够尝试在没有比特率切换的情况下进行通信、方法是将 TX 消息标头中的 BRS 位设置为"0"、以便消息仅以标称比特率传输？  如果这是无错误的、那么很可能会在标称比特率和数据比特率之间进行转换、从而产生发送错误。

此外、如果您可以查看传输期间的 CAN 消息波形、并验证位时间与比特率匹配、位值与协议匹配并达到正确的振幅级别等、或者消息中是否存在正在发生错误的特定位、则可以帮助我们确定错误的原因。  

此致、

Jonathan