[参考译文] F29H85X-MCAL SDK：CAN 驱动程序无法发送 TX 确认回调请求的帧

您好 François、

此 API 在 CAN ISR 中调用。 我记得检查是由上层而不是 CAN 驱动程序完成的。

您好：

我想我可以为这个问题添加一些背景。

您好 Elidio、

非常感谢您提供的更多背景信息。 这非常有用。

QJ Wang ：我们能否分析这个客户使用案例、找出故障的根本原因、并设计一个修复或解决方法？

此致、
François μ s。

您好 François、

我尝试使用 MCAL 驱动程序产生问题。

很遗憾、问题未解决。

问题相同、解决方法相同。

该例程仍然无法正确处理传输确认期间发送的挂起帧。

谢谢您、Elidio。

QJ Wang 、您能否就此问题展开调查？ 如果需要客户提供更多信息、请告知我们。

此致、
François μ s。

尊敬的 Elidio：

您是否使用了最新版本 (26.00.00) MCAL 驱动程序进行了测试？   

https://www.ti.com/secureresources/F29H85X-MCAL-SDK

或

安全资源|德州仪器 TI.com

您能否分享您的测试案例、以便我们轻松生成问题？ 谢谢

您好：

是的、我测试了最新版本的 MCAL 驱动程序 (26.00.00)、可以确认问题仍然存在。

某些帧在传输之前正在进行确认。

在我的当前用例中、我定期以 5ms、10ms 和 100ms 的间隔发送三个分段帧（每个帧由三个段组成）。 相应地分配优先级、5ms 帧具有最高优先级。

传输逻辑的结构如下：

• 每个帧的第一个段从任务发起。 如果较高优先级的帧未处于活动状态、则在 TX 确认 ISR 期间、任何较低优先级的帧都会暂停并在新帧完成后恢复。
• 如果更高优先级帧处于活动状态、则 TX 会确认该帧的最后一个段、从而触发新帧的传输。
• 在 TX 确认 ISR 中、处理程序配置为发送优先级最高的正在进行帧的下一个段。

我已经使用 Can_Example_Loopback 示例成功重现了此行为。

在这种情况下:每个帧的第一个字节包含其发送帧的计数器（应该是 FF, 0, 1 然后达到 2 但它不发送）

• 帧 21： 字节 0 包含帧 21 的计数器、  字节 1 包含帧 22 的计数器、 字节 2 包含帧 23 的计数器
• 帧 22 ：字节 0 包含帧 22 的计数器、  字节 1 包含 帧 22 的计数器
• 帧 23 ：字节 0 包含帧 23 的计数器

我获得意外行为（第 23 帧的计数器从 1 变为 3、第 22 帧和第 23 帧中断第 21 帧）

虽然我期望类似的东西（这是通过第一篇文章的修复实现的）

此致

e2e.ti.com/.../Can_5F00_Example_5F00_Loopback.zip

尊敬的 Francois：QJ 目前在现场与客户联系、无法支持 E2E。  我会看到我是否能找到另一个 SME、否则可能需要等待、直到他在 1.5 周内返回。

您好 Francois、

TXBAR： TX 缓冲区添加请求
向该位写入 1 表示硬件已准备好发送缓冲区中的数据。 硬件扫描缓冲区 进行发送后、它就会被清除。

TXBRP： TX 缓冲区请求待处理
硬件执行 Tx 扫描并意识到缓冲区已准备好进行传输后、设置 TXBRP 位。 仅在成功传输或取消后、该位才会清除。

TXBTO：发生 TX 缓冲区传输
当硬件成功发送消息时会设置此位、而当出现新的 TXBAR 时会清除此位。

理想情况下、当您处于任何给定 Tx 缓冲区的 If_Tx 确认状态时

TXBAR = 0（Tx 扫描后清除）

TXBRP = 0（成功传输会清除该位）

TXBTO = 1（指示传输成功）

因此、使用 If_Tx Confirmation、不太可能还设置 TXBAR 或 TXBRP。

 使用 MCAN_TXBTO 的状态调用 MCANAllTxBuffers 函数 Can_Check。

仅在成功传输后、才会调用 If_Tx 确认。 因此、软件不太可能提前派送 If_Tx Confirmation。

我将继续了解用例并进一步进行调试、同时、您能否在应用代码中检查以下要点。
#1。 避免在 If_Tx 确认中调用另一个 can_write、相反、您可以设置一个 Pending 标志并在设置了标志的情况下调用实际的 Can_Write In Can_Frame。 （尝试找出寄存器中的过时值）
#2. 在调用 can_write 之前递增数据字节。 （这是您要做的吗？）  

在调试过程中、您是否同时观察到了 TXBTO 和 (TXBAR 或 TXBRP) 设置？

您好：

感谢您的反馈。 我想阐明关于我的用例的几点：

#1 — 在任务中调用 Can_Write：这种方法可能有效、但对于我的应用来说不是可行的解决方案、因为它会严重限制 CAN 带宽。 虽然我的示例仅涉及 3 个部分、但实际实施可以实现更多。
#2 — 数据字节的相关性：示例中使用的特定数据字节与应用程序本身无关。 它只是在那里证明异常:如果没有修复,系统会为 3 个传输帧生成多达 5 个确认。 应用修复后、它会正确地为 3 个帧生成 3 个确认。

关于您的问题：“在调试过程中、您是否同时观察到了 TXBTO 和 (TXBAR 或 TXBRP) 设置？“

是的、完全如此。 观察这一确切情况就是在 Can_Check AllTxBuffers 中实现修复的原因。

为了验证该行为、我在 Can_Check AllTxBuffers 中针对该特定条件添加了一个诊断计数器、可以确认该计数器确实增加了。

由于在 ID 较低的帧正在发送时、具有高 ID 的 CAN 帧无法访问 CAN 总线、因此在高速率传输期间、预计会出现延迟和冲突。

此致

你好 Elidio Moas,

我无法重现设置了多个 BTO、BAR 和 BRP 位的相同错误场景。 （使用之前此线程中共享的示例代码）
您能否提供以下信息：

#1。 您如何为 CAN 实现专用区域、即 SchM_CAN_EXCLUDE_AREA_1/ Enter_Can_ SchM_CAN_EXCLUDE_AREA_1 Exit_Can_
#2. 您是在释放模式还是调试模式下运行？ （如果有任何特定于您的示例的编译器或链接器选项，请提供详细信息）
#3. 您是从 RAM 还是闪存加载应用程序？
#4. 我看不到 Os_Cfg 文件中配置的任何中断。 如何配置/初始化中断？ 您使用的中断类别是什么？ （了解中断，优先级，嵌套等所需的派单时间）

你好

#1 — 我使用 MCAL 中的存根、因此保护为 MCAL LIB_DINT/MCAL LIB_EINT

#2 --O2 或-O1 和 fastmath

#3-从 RAM 加载

4：中断为 CAN_MASA_ISR_CAT1_INT

我想提请您注意有关 Can_Check AllTxBuffers 功能的一个特定技术场景。

TXAllTxBuffers 使用一个从 Can_Check 迭代到 MSB 的 for 循环来解析 MCAN_TXBTO 寄存器 (txStat) 的副本、涵盖帧 0x20 至 0x23 的邮箱。

如果 我的伪任务针对 0x23 发出的请求挂起、则帧 0x21 最后一段的通知会为 0x23 触发新的传输请求。

此操作通过 Can_Write 设置 MCAN_TXBRP 和 txPendingStatus 中的相应位。

当 它成功清除硬件 MCAN_TXBTO 寄存器中的位时、循环使用的本地复制 (txStat) 不会更新。

因此、在同一循环的下一次迭代中使用过时值测试该位、这会错误地针对帧 0x23 触发 TX 确认通知。

这种情况只需要之前发送至少一段 0x23（设置 MCAN_TXBTO 中的相应位）。

找到我使用的随附 CCS 工作区。

此致。

e2e.ti.com/.../Can_5F00_Example_5F00_loopback_5F00_F29H85x.zip

你好 Elidio Moas,

请查找我对上述顺序的答复：

TXAllTxBuffers 使用一个从 Can_Check 迭代到 MSB 的 for 循环来解析 MCAN_TXBTO 寄存器 (txStat) 的副本、涵盖帧 0x20 至 0x23 的邮箱

-当我们进入 ISR 时,我们保存状态寄存器,并在整个 ISR 中使用相同的状态。 如果采集后状态发生变化、将在下一个 ISR 中处理。  

如果 我的伪任务针对 0x23 发出的请求挂起、则帧 0x21 最后一段的通知会为 0x23 触发新的传输请求。

-在 0x21 的 ISR 中、为 0x21 和 0x23 设置 BTO

-在 TxConfirmation 为 0x21 期间,启动 0x23 的新消息传输。 请注意、此时硬件已发送 0x23 上的旧消息、我们还必须收到旧传输的确认。 当启动 0x23 的新传输时、BAR 然后 BRP、BTO 将按顺序设置、并在后续 ISR 中进行处理。

此操作通过 Can_Write 设置 MCAN_TXBRP 和 txPendingStatus 中的相应位。

-新消息被接受,因为硬件缓冲区已准备好发送新消息。 旧消息已成功传输、只有确认待处理。

当 它成功清除硬件 MCAN_TXBTO 寄存器中的位时、循环使用的本地复制 (txStat) 不会更新。

-这是预期的,因为旧的 TX 消息实际上是由硬件发出的,因此用户必须收到它的确认。  

因此、在同一循环的下一次迭代中使用过时值测试该位、这会错误地针对帧 0x23 触发 TX 确认通知。

-此通知是正确的、因为 0x23 消息实际上是由硬件发出的。

______________________________________________________

#1。 我计算了通过硬件成功传输的消息数量和接收到的 TxConfirinations 数量、它们完全匹配。 没有额外的 TxConfirishes。

#2. 您看到了 TXBAR、TXBRP 和 TXBTO 的差异、因为您正在比较过时的 TXBTO 与最新的 TXBAR 和 TXBRP。

______________________________________________________

如果这能解决您的疑虑、请告诉我、如果不能、我们可以安排会面进行进一步讨论。

你好

如果使用更清晰的方法、则可以在 0x23 等待总线时发送一个帧 0x22。

我的重点是 在通知帧 0x21 期间使用 CAN_WRITE 发送帧 0x23。

因此、我期望 在 110µs (1000Mbps) 之后针对这个新帧发出通知。

这个新帧不会清除 txStat（因为发出最后一个正确的 0x23 通知）、并且直到出现下一个 ISR 为止。

txPendingStatus 已通过 CAN_WRITE 立即设置。

for 循环的当前迭代管理帧 0x21、然后下一次迭代将管理帧 0x22、下一次迭代将管理帧 0x23。

由于 (bitPos ==(canCtrlObj->txPendingStatus & bitPos )) 和 (bitPos ==(txStat & bitPos)) 为 true、此新 迭代将调用帧 0x23 的通知、即使尚未发送也是如此。

在该通知中、我应该能够发送帧 0x23 的新帧段、因为只有在帧 TX 完成时才应调用此通知。

但是、由于传输实际上并未完成、邮箱会保持忙碌、操作会失败。

此致

您是否希望在 TxConfirmation 中发送新消息、旧消息不应获得 txConfirmation、而只应接收新消息？

1.在几毫秒前收到对旧 0x23 帧的确认、这是正确的。
2、消息 0x21 的确认信息也按预期收到。
3.但是、在执行第 0x21 帧的 ISR 期间、我还收到了对新 0x23 帧（刚刚写入邮箱）的确认。

这是意外行为、因为仅在实际发送帧后才应发出帧 0x23 通知。

多年来、我们的内部软件在多个微控制器和 MCAL 提供商中一直能正常运行、因此我们预计不会出现此问题。

此致

你好 Elidio Moas,

感谢您的澄清和耐心。

现在、我们完全了解了使用案例和过时快照的问题。 您之前提出的解决方法可以解决此问题、而不会产生任何副作用。