• 状态 Resolved
  • 已锁定 已锁定
  • 回复 5 回复
  • 订户 0 订户
  • 视图 298 视图
  • 用户 0 会员在此处
选项
选项
相关

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] CCS/HALCOGEN：在 RM46x HDK 中、CAN1的第一个接收到帧上始终不准确的 DLC 和响应的整体延迟。

admin
Guru**** 2350610 points
Other Parts Discussed in Thread: HALCOGEN
请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/612257/ccs-halcogen-consistently-inaccurate-dlc-on-first-received-frame-of-can1-in-rm46x-hdk-and-overall-delay-in-response

器件型号：HALCOGEN

工具/软件：Code Composer Studio

我遇到这一问题的程度实际上是值得欢迎的进展，这要归功于我迄今所得到的宝贵答复。

我正在使用 HalCoGen 4.6.1为 RM46 HDK 创建构建。  我有一个 USB CAN 器件来发送准备好的 CAN 帧。  准备好的消息可以具有不同的长度(DLC)。  在评估响应时间时、我将读取 DLC 值并发送一条包含 DLC 值的 CAN 消息。

可靠地、第一个 DLC 值是错误的、如 IF2MCTL 中所示。  它应该是6或8、但它是7。  我的布线应该是8、但应该是7；而布线应该是6、但应该是7。  IF2MCTL 中的 DLC 在第一个帧后变得准确。

此外、器件发送帧以及返回帧指示消息长度时会有400ms 的延迟。

;$FileVersion=1.1
;$STARTTIME=42937.5972109375
；
；  H：\IoT\TI\20170721_CANLogs\WhyS230.TRC
；
；  开始时间：2017年7月21日14：19：59.025.0
;  由 PCAN-View v4.1.1.463生成
；
;  消息号
;|          时间偏移(ms)
;||                 类型
;||ID                        (十六进制)
；  |               ||       |数据    长度
；  |               |       ||    |  数据字节(十六进制)...
;||||||                               |
;--+------+-----+-+-+      ---- ----
    1)     5060.6 Tx    0CEF900A 8 06 07 00 00 00 00 FF
    2)     5062.0 Rx    00000002 1 07
    3)     5560.6 Tx    0CEF900A 8 06 07 00 00 00 00 FF
    4)     5562.0 Rx    00000002 1 08
    5)     6060.6 Tx    0CEF900A 8 06 07 00 00 00 00 FF
    6)     6060.6 Tx    00000001 6 00 74 2D 91 CA F2
    7)     6062.0 Rx    00000002 1 08
    8)     6062.8 Rx    00000002 1 08
    9)     6440.7 Tx    00000001 6 00 74 2D 91 CA F2
   10)     6441.9 Rx    00000002 1 06
   11)     6560.7 Tx    0CEF900A 8 06 07 00 00 00 00 FF
   12)     6562.0 Rx    00000002 1 06
   13)     6940.7 Tx    00000001 6 00 74 2D 91 CA F2
   14)     6942.0 Rx    00000002 1 08
   15)     7060.7 Tx    0CEF900A 8 06 07 00 00 00 00 FF
   16)     7062.0 Rx    00000002 1 06
   17)     7440.7 Tx    00000001 6 00 74 2D 91 CA F2
   18)     7442.0 Rx    00000002 1 08

 

;$FileVersion=1.1
;$STARTTIME=42937.5921254167
；
；  H：\IoT\TI\20170721_CANLogs\WhySeven．TRC
；
；  开始时间：2017年7月21日14：12：39.636.0
;  由 PCAN-View v4.1.1.463生成
；
;  消息号
;|          时间偏移(ms)
;||                 类型
;||ID                        (十六进制)
；  |               ||       |数据    长度
；  |               |       ||    |  数据字节(十六进制)...
;||||||                               |
;--+------+-----+-+-+      ---- ----
    1)     2748.3 Tx    00000001 6 00 74 2D 91 CA F2
    2)     2749.5 Rx    00000002 1 07
    3)     3248.3 Tx    00000001 6 00 74 2D 91 CA F2
    4)     3249.6 Rx    00000002 1 06
    5)     3748.3 Tx    00000001 6 00 74 2D 91 CA F2
    6)     3748.3 Tx    0CEF900A 8 06 07 00 00 00 00 FF
    7)     3749.6 Rx    00000002 1 06
    8)     3750.5 Rx    00000002 1 06
    9)     4112.3 Tx    0CEF900A 8 06 07 00 00 00 00 FF
   10)     4113.7 Rx    00000002 1 08
   11)     4248.3 Tx    00000001 6 00 74 2D 91 CA F2
   12)     4249.6 Rx    00000002 1 08
   13)     4612.4 Tx    0CEF900A 8 06 07 00 00 00 00 FF
   14)     4613.8 Rx    00000002 1 06
   15)     4748.4 Tx    00000001 6 00 74 2D 91 CA F2
   16)     4749.6 Rx    00000002 1 08
   17)     5112.4 Tx    0CEF900A 8 06 07 00 00 00 00 FF
   18)     5113.8 Rx    00000002 1 06
   19)     5612.4 Tx    0CEF900A 8 06 07 00 00 00 00 FF
   20)     5613.8 Rx    00000002 1 08

  • 0
    TI__Guru**** 2350610 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    在最近的重新测试中、400ms 延迟似乎是在等待 canIsRxMessageArrived 返回 true/READY。
  • 0
    TI__Guru**** 2350610 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好 Neil、

    如果您在从工具到器件的传输中放置一个示波器、您能否查看传入消息是否延迟或它是否与器件上的接收功能相关？ 当然、在 CAN 的大多数用例中、400ms 的延迟是不可接受的。 您使用的波特率是多少？

    关于 DLC 不准确、您是否收到了传输的所有数据？ 是否存在任何 CAN 错误条件、例如 CRC 错误、组帧错误或此类错误？
  • 0
    TI__Guru**** 2350610 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    延迟似乎发生在 while 循环内(我正在使用的代码在 example_canIntCommunication 中有一些)

         while (！canIsRxMessageArrived (canREG1、canMESSAGE_BOX1))；
         canGetData (canREG1、canMESSAGE_BOX1、Rx_PTR)；//复制到 RAM *    

    当我在 while 循环之前读取 canMessageNotification 中的 DLC 时、就会发生不准确的 DLC。  当我在 while 环路之后开始读取 DLC 时、DLC 是准确的。  在 canMessageNotification 中、准确的值没有准备就绪、这一点不足为奇。

    USB CAN 工具不报告任何问题、但如果问题的根源、它可能不会报告问题。  范围似乎没有突出任何缺陷，显示了帧的定期触发。  USB CAN 工具可能是一些阻碍因素。

    我将看到我可以通过示波器确定的内容。

  • 0
    TI__Guru**** 2350610 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好、Neil、

    函数 canISRxMessageArrived()正在读取并返回 CAN 消息中 NEWDat 位的状态。 当报文对象更新了新数据时、该位将置位。 很有意思的一点是、您可以在与 CAN 消息从传输开始到完成的时序相关的范围内看到什么、因为 MsgBox 不会指示它已经更新、直到完全接收到消息。
  • 0
    TI__Guru**** 2350610 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    在本帖子的开头、我添加了 CAN 帧跟踪、这些跟踪似乎表示 canMessageNotification 中存在400ms 延迟(或您在调用该延迟之前建议的400ms 延迟)。

    作为快速测试、我创建了一个计数器来查看 canIsRxMessageArrived 函数的调用频率。  在今天上午的测试中、收到的每帧只调用一次、没有延迟。  发送帧记录时间约为1ms。

    我要将其标记为已解决。  我不确定这是诊断错误还是某个地方的代码更改幸运。

    当前问题：我在当前代码中没有获得准确的消息标识符、因此我很感谢 您提供有关如何/在何处获得该值的建议。  接收消息框的掩码为0x0、因此需要以某种方式收集消息标识 符、就像我必须收集 DLC 一样。