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/TM4C1294NCPDT:接收 CAN 数据时出错

Guru**** 2482105 points


请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/706472/ccs-tm4c1294ncpdt-error-in-receiving-can-data

器件型号:TM4C1294NCPDT

工具/软件:Code Composer Studio

您好!

我正在尝试在 TM4C1294XL 上使用 CAN 总线。 我从简单的 Rx 和 Tx 代码开始、并将其更改为使用 CAN1、以便可以使用 UART0监控数据。 我使用两个 MCP2551作为具有120欧姆端接电阻、RS 端子接地的收发器。 当我尝试传输时、我在两个控制器中都收到错误。 我随附 了发送和接收的寄存器说明。 仅当我连接 Tx m/C 时才会发生 Rx 中断 据我了解、Tx 和 Rx 错误计数器已填充、这会导致错误。 因此我尝试将传输速率降低到100Kbps、我还尝试了多个 Tx 和多个 Rx、结果是相同的。 请告诉我可能会出现什么问题。 随附这些文件以及 m/C 的寄存器说明供参考

e2e.ti.com/.../CAN-Tx_2C00_Rx.zip

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

    问题可能是您未正确设置系统时钟频率。 TX.c 的第268行缺少逗号(,)。 遗憾的是、这种忽略与该示例直接相关。 尝试添加逗号、重新编译和重新测试。 如果这不起作用、请尝试使用示波器查看 CAN 信号、以验证您是否以预期的波特率运行。



    看起来 Rx.c 文件与 TX.c 文件完全相同。 在创建.zip 时、这是一个问题吗? 接收例程中可能存在相同的问题。

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

    尊敬的 Bob:

    感谢您的回答。

    抱歉、我的末尾出现文件混频错误 附加实际的 Rx 文件。

    我已按照您的建议更新了代码、但仍会出现相同的错误。 我将使用示波器进行检查、并让您知道我的结果。

    谢谢你

    e2e.ti.com/.../0383.Rx.c

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

    [引用 user="Bob Crosby">不幸的是、该省略(缺少逗号)与示例直接相关。 [/报价]

    这是不好的-但不知怎么说、我的公司使用'simple_Rx.c & simple_Tx.c' (在(过去) StellarisWare 下)作为 CAN 应用的基础-已经解决了这个问题!   我们注意到、在该(过去)制度下、不存在这样的"TM4C129"(要求完全新/偏离系统频率命令)。   

    是否不清楚 是否需要"更好地提醒"此类(缺少逗号)-以保存用户-客户端-来自此"已知"缺陷?   

    这不是您的工作、但在如此高(未受保护)的"悬崖"上、将用户游行 证明"不是那么明智"。    这里没有人"期望供应商做到完美"。    然而,有些----有效纠正(或至少----(一些)警告)似乎远远优于... 避免!

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

    我尝试监控示波器上的数据。 我已将我的标识数据包更改为29 (0x1D)、将我的数据包更改为45 (2D)。

    如果我理解正确、时间份额(tq)= BRP / fsys = 63 / 16、000、000 = 3.9375uec。

    总位时间= [TSEG1 + TSEG2 + 3]×t q = 74.8 μ s。

    数据帧应为[SOF、11位标识符、........] =[0 00000011101 ......... ]。 因此、在 7 x 74.8 μ s = 523.6 μ s 后、总线应降至隐性状态。

    但是、从示波器观察到、显性状态持续2200 μ s、然后重新开始。  何时未收到确认? (我假设)。

    如果我错了、请纠正我的问题。

     我已经检查了寄存器值、它们看起来很好。  发送器设置是否有问题或我错过了什么。

    谢谢你

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

    [引用 user="Tarun Bajajaja"]我以简单的 Rx 和 Tx 代码开始... (随后)更改了它...[/引号]

    您的(过去)成功通过'simple_rx 和 simple_Tx'吗?不 保证您能重新访问  这些关键文件?    

    这样做-您可能会"比较和对比"个"已证明成功"的 CAN 实施方案-与 "您现在拥有的"方案相比 -失败了。   仔细检查各种"设置和配置-以及"simple_Rx/Tx"运算范围电容-极有可能提供"关键事实"-  可能"让您 前进"-迈向  CAN 成功...

    和往常一样,很多人会敦促你使用 “kiss” ——你似乎已经做了很多改变——因此,正确 的“故障识别” 是“ 困难得多”…… 和... “很耗时!”   不好!   

    相反、由于其严格控制的系统性质、"kiss"会指示 "一个简单的(一次可衡量的变化)始终经过测试和验证!"   然后、检测到故障(甚至是"轻度"偏差-更明显  (更快速、更容易) -这可以  实现"更快/更轻松"的修复!

    "亲吻"提供的卓越控制和洞察 (仅限)无疑会产生 "极其出色的方法"、不是吗?

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

    我发现了问题!

    它与我使用的是 GNU 编译器这一事实有关。 同一组代码适用于 TI 编译器。

    我必须使用 GNU 编译器、我有没有做任何事情来解决这个问题?

    谢谢你。

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

    我的朋友-你不会再次尝试 "不必要的困难/复杂"任务、 "太大的挑战?"

    您的'Adoption of 'kiss'-是否最好让您能够、'Test/Verify'(测试/验证)密钥(但大小受限)的 GNU 编译器段-以便您可以在 GNU & Vendor 编译器不同的时间/地点"准确识别"?   也请注意-即使  您的"一体式"方法"阻碍和阻碍了"、您也能够 (几乎)识别 "故障"的(可能的)区域。

    "kiss"指示您"激光聚焦"   当前故障区域(有限)和"工作与故障"编译器输出之间的"A-B -比较/对比"。   这种“亲吻方法”-证明 了您 (当然还有其他人)成功的“最快、最简单和最可能的路径”-这两个方法(现在)...  并为 您/他们的未来带来长远的发展!   

    另外请注意通过执行此类"详细检查"、您可能 会发现确切原因、掌握关键(新)知识 、 有效  地"防范"未来的任何情况、 "再次访问此问题和/或类似 问题!"    这是巨大 的- “亲吻”(真的/明显)值得 您采纳...

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

    感谢 CB1_MOBILE、

    这确实起了作用!

    从我的终点看,这是一个愚蠢的错误 对于 GCC 编译器、未应用#if 函数、因为它缺少所需的定义。 因此、寄存器配置不正确。

    这部分解决了问题。 能够传输数据、并且可以在我的示波器上监控数据。 但是、具有所有相同更改的接收器始终会给出 ID 和数据、对于要传输的任何值都为"0000s"。

    我看到其他人面临这一问题,但无法找到解决办法。 请告诉我如何继续。

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

    [引述 USER="Tarun Bajajaja)]我能够传输数据并可以在示波器上监控数据。 [/报价]

    您对传输数据的"监控"是否延伸到您能够"读取数据?   KISS -再次-通过建议您(购买)"独立" CAN 总线监视器来帮助您。   (这甚至可作为带有 CAN 到 PC 信号接口的"PC"程序使用。)

    您的问题可能是由您的"报告数据" (不是最新数据)引起的-因此、"诊断眼的第二组"可以(最好)确认这一点。

    同样、当所有其他故障发生时、您可以恢复到 simple_ca_RX/TX -并仔细注意-接收到的正确数据是什么-以及"何时、何地和如何"。

    一 个(更多)提示-您可以通过使用(或) 0x55或0xAA 来"最好地识别"传输的数据(在 CAN 总线上")、因为这两个方法都会产生"交替位模式"-极大地简化/帮助视觉识别。    (即使在-尤其是在-正确的诊断设备-被证明不可用时...)