请教 CAN扩展帧中的仲裁段的SRR位
本帖最后由 Semiconductor 于 2018-10-25 17:04 编辑先说故事：
最近在调试CAN通讯程序，使用NXP（原Freescale ）的S32K144单片机，与整车控制器在标定CAN上交互通讯。
先调试一款整车控制器A，调试过程顺利。
再调试另一款整车控制器B时（通信协议不一样），问题来了，我发出的请求命令帧，整车控制器B不响应，而且用CAN卡抓包时也没有发现命令数据哪里不对。
调试时CAN总线上就挂载了3个节点：我，整车控制器B，CAN卡（监控抓包用），终端电阻两个120Ω的。我不发起请求命令的话，CAN总线上就不会有数据活动。我发出数据时，CAN卡上也没检测到总线错误。
问题出在哪？虽说工作中接触CAN总线的时间不到两年，但这种时候通过CAN卡抓包，我也能确保发出CAN帧的ID和数据内容是完全正确的。
之后，更加摸不着头脑的事情是：使用CAN卡发送相同的请求命令帧，整车控制器B有响应；CAN总线上只挂载我和整车控制器B两个节点时，我发出的请求命令帧，帧结构上的ACK应答位，能被整车控制器应答，但就是不给响应。
问题出在哪？整车控制器明显是正确接收到了我发出的命令帧，就是不给响应。
难道是和我使用的S32K144单片机是工程样片有关？但网络上也没搜索到相关问题的反馈讨论啊——至少是中文描述我没找到，而且这单片机目前也已经量产了。
……
没有头绪的时候，往往会疑神疑鬼，想到什么可能性，都要去试一下，拿出我约十年前在淘宝上一百来块钱买的逻辑分析仪，看看S32K144单片机和CAN卡发出的同样一帧，到底有什么不同吧。
在逻辑分析仪上初一看，没发现什么不对，命令CAN帧的ID和数据内容无误，ACK应答位有效。
黔驴技穷，想必这种感觉，做研发的人应该都有感受过吧。
都不知道下一步该怎么进行了。逐个比较一下逻辑分析仪上单片机和CAN卡发出的相同CAN帧的bit？看一下位宽？
CAN扩展帧总共有100多bit，如果让单片机和CAN卡同时发送数据，用逻辑分析仪的两个通道采集，在逻辑分析仪软件界面上，上下对齐逐位对比，应该也不难。
问题是我没想到办法，让单片机和CAN卡同时发送数据给逻辑分析仪采集。不过偷懒的办法还是有的——只发CAN帧的ID，DLC=0，也就是不发数据内容，这样一帧的bit位就少很多了。也就不费劲去对齐比较了。
妈蛋，只发CAN帧ID，CAN帧的长度少得太多了，一眼就发现了CAN帧结构中的CRC校验值不同。多次重复测试时，CRC值是同样的，也就是说不CRC值不相同，不说偶然。
事情进展到这一时刻，自然是欣喜的——应该这CRC校验值的不同，就是问题的所在了吧。
问题是为什么同样的CAN帧数据，CRC值会不同呢？难道真和工程样片有关？亦或是和这S32K144支持CANFD有关？但也没听说过哪家的CAN控制器的CRC校验值可以修改CRC多项式或是初始化种子啊。
……
逐bit对比后发现，CAN扩展帧中的仲裁段的SRR位不一样：CAN卡发出的SRR位是1，S32K144发出的SRR位是0。这就导致了CRC值不一样。
S32K144的CAN驱动程序，使用的是官方的库。将程序中的SRR值置1，问题解决了。
那么问题有来了，SRR到底应该是置1还是置0？
SRR位是“代用远程请求位”。CAN帧结构中它参与仲裁，它的下一位“IDE”表示标准帧还是扩展帧。我的理解是SRR应该置1，才不影响仲裁。
和我当年遇到的情况一样，我当时是用示波器抓它和canoe发的数据有什么不同，最后好像也是这里 你正常通讯时数据包SRR的位置如果为1的话，就是隐性。
此位隐性可能表示该帧为扩展帧（IDE为1），或者是标准帧的远程帧（IDE为0），
你发的数据此位为0显性，表示你发送的是标准帧的数据帧。帧类型都不一样啊。
说了那么多，理解你的问题很麻烦，标准帧 扩展帧，用can看更直观，不必纠结位了，不容易看 lingdianhao 发表于 2018-10-25 23:27
你正常通讯时数据包SRR的位置如果为1的话，就是隐性。
此位隐性可能表示该帧为扩展帧（IDE为1），或者是标 ...
先说优先级：标准帧高于扩展帧；数据帧高于远程帧。
再说标识位：RTR为0是数据帧，RTR为1是远程帧；IDE为0是标准帧，IDE为1是扩展帧。
然后说SRR“代用远程请求位”：
1、发扩展数据帧的时候，假如SRR置0（SRR和RTR位相同——RTR此时为0）。它在和标准数据帧仲裁的时候，（假设前11bit的ID相同）在标准帧的RTR位（数据帧的RTR位此时为0），还不能仲裁出结果，但在接下来的IDE位仲裁失利。没毛病。
2、发扩展数据帧的时候，假如SRR置1（SRR不和RTR位相同——RTR此时为0）。它在和标准数据帧仲裁的时候，（假设前11bit的ID相同）在标准帧的RTR位（数据帧的RTR位此时为0），仲裁失利。没毛病。
3、发扩展数据帧的时候，假如SRR置0（SRR和RTR位相同——RTR此时为0）。它在和标准远程帧仲裁的时候，（假设前11bit的ID相同）在标准帧的RTR位（远程的RTR位此时为1），仲裁获利。有毛病吗？——【扩展数据帧的优先级高于标准远程帧】。
4、发扩展数据帧的时候，假如SRR置1（SRR不和RTR位相同——RTR此时为0）。它在和标准远程帧仲裁的时候，（假设前11bit的ID相同）在标准帧的RTR位（远程的RTR位此时为1），还不能仲裁出结果，但在接下来的IDE位仲裁失利。没毛病。
5、发扩展数据帧的时候，假如SRR置0（SRR和RTR位相同——RTR此时为0）。它在和扩展数据帧仲裁的时候，（假设前11bit的ID相同）如果竞争对手的SRR位为0，正常仲裁；如果竞争对手的SRR位为1，仲裁获利。有毛病吗？——【后18bit的ID不能参与仲裁了】
6、发扩展数据帧的时候，假如SRR置1（SRR不和RTR位相同——RTR此时为0）。它在和扩展数据帧仲裁的时候，（假设前11bit的ID相同）如果竞争对手的SRR位为1，正常仲裁；如果竞争对手的SRR位为0，仲裁失利。有毛病吗？——【后18bit的ID不能参与仲裁了】
综上，如果我的理解没有问题，那么，我认为SRR位应该始终置1，才不影响仲裁优先级。
我没有找到关于SRR位到底该如何设置的【标准文档】。如果谁知道，麻烦上传一下。
网上较多描述是SRR位应该和RTR位相同，实际中遇到的是SRR位置1（就扩展数据帧而言）。
这次S32K144的驱动程序的SRR位和RTR位相同，让我找得好苦。话说回来，我觉得调试中的整车控制器也有点奇葩，你接收到一帧报文后，取出帧ID和数据内容，该干嘛干嘛，非得和SRR位过不去。 nibia 发表于 2018-10-26 08:12
说了那么多，理解你的问题很麻烦，标准帧 扩展帧，用can看更直观，不必纠结位了，不容易看 ...
说这么多都是为了讲故事。
我一般调试中都会挂一个CAN卡到总线上，使用周立功的CANPro上位机查看。 本帖最后由 lvfv 于 2018-10-26 19:31 编辑
楼主，SRR名字就是代用远程请求，是必须为1的。
Substitute remote request (SRR) 1 Must be recessive (1)
参考资料：https://en.wikipedia.org/wiki/CAN_bus
我的主页有篇简单翻译。 本帖最后由 Semiconductor 于 2018-10-27 09:16 编辑
lvfv 发表于 2018-10-26 19:02
楼主，SRR名字就是代用远程请求，是必须为1的。
Substitute remote request (SRR) 1 Must be recessive (1 ...
感谢，有了出处。
页:
[1]