[参考译文] AM2634：MCAN 使用 CANFD 和传统 CAN 时的错误帧

您好、Terry、

您能否提供有关“启用 AM2634 同时发送/接收 CAN FD 和经典 CAN“更改内容的更多信息？
考虑到硬件设置在特定模式下按预期运行、硬件设置似乎是正确的。

CAN-FD 在同一 CAN 总线上支持常规 CAN 消息、因此仅在配置 MCAN_TX（收发器）块时才应应用对 CAN-FD 与非 CAN-FD 的控制。

您能否提供适用于 F280039x 器件（按预期工作）的类似代码/配置以及 AM2634 代码/配置？

此致、

Zackary Fleenor

要启用 AM2634 发送/接收 CAN FD 和传统 CAN、意味着一些通道将消息配置为 CAN FD 帧、而一些其他通道将消息配置为传统 CAN 帧、这两种类型都在 CAN 总线中启用收发器。

下面是 AM2634 中的配置代码和寄存器值、您能帮助检查是否需要优化？   

您好、Terry、

很难查看屏幕截图中的代码、是否可以使用如下所示的“插入“函数将文本复制并粘贴到块中？

嗨、Fleenor

客户公司计算机无法发送文本文件、因此只能捕获图片以显示注册表。  

抱歉、我所说的信道应该是邮箱编号、客户为 CANFD 配置了单独的邮箱、或者如下代码所示、这只是代码的一部分、也是我在上面的帖子中附加的完整配置代码。    请帮助验证此用法是否正常？  

或者、我们是否有示例固件在 AM2634 中配置 CAN FD 和 CAN 类？ 我们能否通过这个示例来验证性能

嘿、Terry、

感谢您分享您能做的事情。 我不知道这里有一个示例、但我将向 SDK 团队创建一个请求单。

我有几个后续问题可以帮助调试问题。

对于 CAN-FD 功能、仲裁比特率和数据比特率是否相同？ 如果没有、它们是什么？

CAN 功能期间的数据比特率是多少？

您能否共享适用于 F280039x 器件的等距代码？

在测试期间、接收器功能是否继续按预期工作？ （其他器件可以发送 CAN 或 CAN-FD 消息、而 AM2634 会正确接收这些消息？）

协议切换的顺序很重要吗？ 即、它是在正常 CAN 模式下启动时工作、然后在切换到 CAN-FD 模式时失败、还是在以 CAN-FD 模式启动时工作、然后在切换到 CAN 模式时失败？

设备能否切换回原始模式并恢复正确的传输？

感谢您提供更多信息。

此致、

Zackary Fleenor

嗨、Fleenor

请检查 AM2634 比特率设置、如下面的捕获所示、F280039 几乎是相同的设置。 唯一的区别是标称比特率的预分频器值在 AM2634 上为 15、在 F280039 上为 7、数据比特率的预分频器在 AM2634 上为 1、在 F280039 上为 0。   

请检查 F280039 的代码配置。    

FD 和 Claasis 帧按照独立顺序在 CAN 总线中发送、无需开关逻辑。 基本上、传统帧按固定周期发送、FD 帧根据操作以更高的频率发送。 FD 和 Classic 帧都可以继续发送和接收、有时会报告错误帧。 AM2634 将报告很高的频率误差、而 280039 几乎不报告错误。  

客户想再次确认 AM2634 和 F280039 的 MCAN 模块是否完全相同、因为他们已经制造了 60 组产品并计划在下周发布给汽车 OEM、因此迫切需要在下周前确认 AM2634 是否需要任何不同的设置。

您好、Terry、

是的、AM2634 和 F280039 的基本内核 MCAN IP 是相同的 Bosch IP、底层数据/寄存器结构和相关配置参数没有区别。

他们是否可以在正常运行期间和故障/错误帧操作期间探测 CAN_[H：L]和 MCAN_[TX：RX]信号？

此致、

Zackary Fleenor

嗨、Fleenor

我们能否基于 AM2634 在差分邮箱中为 FD 和 Classic CAN 设置一个示例、以验证它是否可以正常工作、而没有错误帧？ 可能不需要太多时间、因为我们已经有单独的示例、只需将其合并到一个 MCAN 项目中、波特率的 配置可以与客户设置相同。

嘿、Terry、

本周我要检查经典 CAN 示例的带宽有限、但我已验证 CAN-FD 是否按预期工作、而不会生成错误帧。 用于两个 MCAN 通道的 CAN TRX IC 相同、即每个通道都有一个指定的收发器。  

您能否配置第二个 MCAN IP 来运行 CAN-FD 模式并将当前的 MCAN IP 专用于使用传统 CAN、而不是在单个 MCAN IP 上在传统 CAN 和 CAN-FD 之间进行切换？

此致、

Zackary Fleenor

嗨、Fleenor

是的、两个 MCAN 通道使用相同的 CAN TRX IC、客户配置第二个 MCAN IP 是面临挑战、因为硬件已经固定、板中只有一个 CAN TRX IC 连接一个 MCAN IP、因此 CAN-FD 和传统 CAN 帧必须由一个 MCAN IP 使用。  

我们针对错误帧时刻捕获如下波形、双通道信号在 TRX IC 中为 CAN 总线、红色信号在 AM2634 上为 CAN TX 引脚。 如果有任何问题、请帮助查看？

感谢您发送编修。 乍一看、没有什么明显的迹象。 用于确定使用经典 CAN 还是 CAN-FD 的软件控制是什么？ 发生该切换时、应用程序是否会注意重置和重新配置整个 MCAN IP 以实现交替运行模式？  

本质上、需要显式调用 MCAN_Config 和 MCAN_Init 函数、以执行每种工作模式（传统 CAN、CAN-FD）、以及在更改配置寄存器时遵守将 MCAN IP 置于软件初始化模式的要求。

您能否确认在发生切换时用于执行切换和初始化/重新初始化步骤的机制？

此致、

Zackary Fleenor

您好、Terry、

我刚才想到的另一点是、由于器件之间的 MCAN IP CLK 不同 (80MHz 与 40MHz)、F280039x 和 AM263x 配置之间的数据时序段和发送器延迟补偿值应该是唯一的。 AM263x MCAN 的 CAN-FD 时序参数值不正确可能会导致这种错误情况。

您能否通过以下应用手册和相关的 XLS 工具再次检查这些内容：

https://www.ti.com/lit/an/sprac35/sprac35.pdf

http://www.ti.com/lit/zip/sprac35

另一个选项是更新时钟 API 并将 AM263x MCAN 源时钟强制为 40MHz。

此致、

Zackary Fleenor

嗨、Fleenor

客户软件不会重置或重新配置 MCAN IP、在开始时会将一些邮箱配置为 CAN-FD、将另一个邮箱配置为 CAN-Classic、然后当他们想要发送 CAN-FD 或 CAN-Classic 消息时、只需将消息放入正确的邮箱缓冲区并启动该邮箱。 您可以在上面的帖子中检查配置代码。

您是否认为 MCAN IP 无法支持客户的当前使用情况、他们必须重置 MCAN IP 并将其重新配置为交替模式？ 但是、客户固件可以在 F280039 上运行良好、为什么只会在 AM2634 中出现问题？

链接中的应用手册和 XLS 工具会查找 ECAN 和 DCAN、它是否也符合 MCAN？  

客户在 SysConfig 中配置 MCAN 时序段并通过 SysConfig 检查、如果有任何问题、您能否在上面我的文章中查看设置值？  

更新时钟 API 并将 AM263x MCAN 源时钟强制为 40MHz 是一个好主意、我们也可以这样做、尽管我们没有找到关系 API 函数、您是否知道如何实现？   

嘿、Terry、

是的、在这种情况下、无论底层 CAN IP 如何、时间段计算仍然适用。 将主机 CLK 速度从 40MHz 更改为 80MHz 会使预期的位时序配置发生变化。 此处的 SysConfig 实现尚未对时序参数进行任何验证、仅根据用户输入生成代码。 用户需要确认正确的配置值、但我们确实计划在将来的版本中对此进行改进。

 SOC_rcmSetPeripheralClock() 函数可用于控制 MCANx 源时钟。 有关其他 RCM（复位时钟管理器）控件/功能的更多详细信息、请访问以下链接。

https://dev.ti.com/tirex/explore/content/mcu_plus_sdk_am263x_10_02_00_13/docs/api_guide_am263x/group__DRV__SOC__RCM__MODULE.html

此致、

Zackary Fleenor

嗨、Fleenor

根据您的建议、我们已尝试在 AM2634 中将 MCAN 时钟修改为 40MHz、并为 AM2634 和 F280039 配置完全相同的位时序参数、但 AM2634 仍将报告错误帧。

经过更多调试后、我们发现问题可能与 FIFO 的使用有关、 我们执行验证以将以下代码放入 main.c 的循环例程、然后将发生错误帧、导致问题外观、因为调用 WriteMsgRam 以过多的频率填充 FIFO。 无论是通过 CAN FD 还是通过 CAN 经典格式发送、无论在客户板或 AM2634 EVM 板上运行、只要以下代码继续在主循环上运行、就会发生错误帧。

如果以下代码有任何问题、您可以帮助回顾一下吗？ 为什么下面代码中的“if (TxFs.fifoFull == 0)“不阻止 FIFO 填充频率过高？ 为什么它会导致错误的烦恼?

嘿、Terry、

客户可以评估 freeLvl  并确定 FIFO 中是否有可用空间来存储整组 TX 消息、而不仅仅是检查 fifoFull。

请提供 MSG RAM 和 TX 配置的屏幕截图、以供进一步评估。

此致、

Zackary Fleenor

嗨、Fleenor

上面的是用于发送的 FIFO 配置。 当我继续调用 MCAN_vTransmit 以发送 CAN 数据时、将发生错误帧。 减少 MCAN_vTransmit 也会减少错误帧数。 为什么发送过多 CAN 数据会导致错误帧？

/*最大 TX 缓冲区+ TX FIFO（可组合配置）为 32 */
#define APP_MCAN_TX_BUFF_CNT (0U)//0
#define APP_MCAN_TX_FIFO_CNT (CANTxMailNO+2)///(0)//(APP_MCAN_STD_ID_FILTER_CNT+APP_MCAN_EXT_ID_FILTER_CNT)//(5U)//5//采用FIFO发送 μ s
/*可配置的最大 TX 事件 FIFO 为 32 */
#define APP_MCAN_TX_EVENT_FIFO_CNT (CANTxMailNO+2)

/*可 采用FIFO 0接收 的最大 RX FIFO 0 为 64 *///μ s
#define APP_MCAN_FIFO_0_CNT 10//(APP_MCAN_STD_ID_FILTER_CNT+APP_MCAN_EXT_ID_FILTER_CNT)//(5u)
/*可以配置的最大 RX FIFO 1 为 64 和
*内存的其余部分被分配给 RX 缓冲区,再次是最大大小 64 */
#define APP_MCAN_FIFO_1_CNT (0U)

静态 void Drv_Mcan MsgRamConfigParams (MCAN_MsgRAMConfigParams * msgRAMConfigParams)
｛
int32_t 状态；

MCAN_initMsgRamConfigParams (msgRAMConfigParams)；

/*配置用户所需的 msg ram 参数*/
msgRAMConfigParams->LSS = MCAN_STD_ID_FILTER_CNT；
msgRAMConfigParams->LSE = MCAN_EXT_ID_FILTER_CNT；
msgRAMConfigParams->txBufCnt = APP_MCAN_TX_BUFF_CNT；
msgRAMConfigParams->txFIFOCnt = APP_MCAN_TX_FIFO_CNT；

/*选择缓冲器/FIFO 模式*/
msgRAMConfigParams->txBufMode = MCAN_TX_MEM_TYPE_BUF；
msgRAMConfigParams->txEventFIFOCnt = APP_MCAN_TX_EVENT_FIFO_CNT；
msgRAMConfigParams->rxFIFO0Cnt = APP_MCAN_FIFO_0_CNT；
msgRAMConfigParams->rxFIFO1Cnt = APP_MCAN_FIFO_1_CNT；

/*选择 FIFO 阻塞模式*/
msgRAMConfigParams->rxFIFO0OpMode = MCAN_RX_FIFO_OPERATION_MODE_BLOCKING；
msgRAMConfigParams->rxFIFO1OpMode = MCAN_RX_FIFO_OPERATION_MODE_BLOCKING；

STATUS = MCAN_calcMsgRamParamsStartAddr (msgRAMConfigParams)；
DebugP_ASSERT (status == CSL_PASS)；

返回；
}

/********************************************************************************************
**函数名称: MCAN_vTransmit
*功能描述:发送CAN数据
*输入:数据缓存
*输出:ture 成功
**最后修改: LINJUNSHENG 2024年01月19日
****************************************************************************************** /
uint16_t MCAN_vTransmit (const uint8_t* txdata、uint32_t u32Id、uint8_t u8Len)
｛

MCAN_TxBufElement txMsg；
uint16_t i = 0u；
Uint16_t txMsg_XTD = 0；
uint16_t txMsg_FDF = 0；
uint16_t 邮箱= 0；
/

for (I = 0；I<CANTxMailNO；I++)
｛
if (CanTxCfg[i]。msgid = u32Id)
｛
txMsg_XTD = CanTxCfg[i]。txMsg _XTD；//
txMsg_FDF = CanTxCfg[i]。txMsg _FDF；
邮箱= CanTxCfg[i]邮箱；
休息；
}
}

if (txMsg_XTD == 1) 扩展帧 μ s
｛
txMsg.id =(uint32_t)(u32Id)&0x1fffffff；//标识符值。
txMsg.XTD = 1U；// 29 位标准标识符。
}

否则标准帧/μ V
｛
txMsg.id =((uint32_t)(u32Id))<< 18U；//标识符值。
txMsg.XTD = 0U；// 11 位标准标识符。
}

txMsg.RTr = 0U；//发送数据帧。

txMsg.esI = 0U；// CAN FD 格式的 ESI 位仅取决于错误
//被动标志。
txMsg.DLC = u8Len；// CAN + CAN FD：发送帧具有 0-8 个数据字节。
I IF (txMsg_FDF = 1)//CAN FD 格式
｛
txMsg brs = 1U；//以比特率发送的 CAN FD 帧
//切换。
txMsg.FDF = 1U；//以 CAN FD 格式发送的帧。
}
暴露
｛
txMsg.CAN brs = 0U；//在无比特率的情况下发送 CAN FD 帧
//切换。
txMsg.FDF = 0U；//以 CAN 格式发送的帧。
}
txMsg.efc = 1U；//存储 Tx 事件。
txMsg.mm = 0xAAU；//消息标记。

for (I = 0；I < u8Len；I++)
｛
txMsg.data[i]= txdata[i]和 0xFF；
}

MCAN_TxFIFOStatus TxFS；
MCAN_getTxFIFOQueStatus (gMcanBaseAddr、&TxFS)；

if (TxFS.fifoFull=0)
｛
发送采用FIFO μ V
MCAN_writeMsgRam (gMcanBaseAddr、MCAN_MEM_TYPE_FIFO、TxFS.putIdx、&txMsg)；//
MCAN_txBufAddReq (gMcanBaseAddr、TxFS.putIdx)；
}
暴露
｛
返回 0；
}

返回 1；

}

嗨、Zack

附件 AM2634 MCAN 示例代码在 CC-EVM 上运行、以   按序列传输 FD 和经典 CAN 封装。  

具有不同 CAN 盒的客户测试示例代码、并发现以下行为：

• 条件 1、CAN 盒支持 CAN FD 功能并启用 CAN FD 功能、通信正常以显示 FD 和经典 CAN 封装
• 条件 2、  CAN 盒支持 CAN FD 功能、但仅启用 CAN 经典功能、CAN 工具无法显示任何封装
• 条件 3、 CAN 接线盒不支持 CAN FD 功能、CAN 工具将在一段时间内显示错误帧

在下面的捕获是条件 2（左）与条件 1（右）、您认为行为是否正常、您是否可以帮助验证您这边是否存在相同的行为？

 e2e.ti.com/.../3225.mcan_5F00_external_5F00_read_5F00_write_5F00_am263x_2D00_cc_5F00_r5fss0_2D00_0_5F00_nortos_5F00_ti_2D00_arm_2D00_clang.7z

嘿、Terry、

很遗憾、我无法访问他们在这里使用的 ZCANPRO 软件工具、并且我找不到任何可靠的文档来查看该工具的功能。

但是、根据提供的条件、该测试按我的预期运行。

如果仅启用传统 CAN 功能、则会忽略 CAN-FD 格式的数据包。 我不明白为什么在这种情况下会忽略常规 CAN 消息。 我需要他们使用的有关软件工具和硬件 CAN 盒的更多信息来提供额外分析。

我通常使用 PCAN-View 软件通过提供的“跟踪“功能来评估 CAN 总线数据、但我始终使用 CAN-FD 硬件配置选项、而不是传统 CAN 配置选项。

我将检查结果,当使用经典的 CAN 只能让你知道,但这将特定于我的测试环境。

此致、

Zackary Fleenor

您好： Zackary Fleenor、

我不明白为什么在这种情况下会忽略常规 CAN 消息。

我理解这一点、并在 PCAN View 工具上进行了测试。

在我的测试中,我只收到一条常规 CAN 消息,之后没有常规 CAN 消息。

我怀疑这是因为在代码中、我们首先传输常规 CAN、然后传输 CAN-FD 消息。

因此、在成功将第一条常规 CAN 消息发送到另一端后、将为 CAN-FD 消息生成错误帧、因为工具设置为仅接收常规 CAN 消息。 因此、重试后 、可能会导致总线关闭并停止通信。

也许这就是我们无法接收常规 CAN 消息的原因。

--
此致、
Jagadish。