B1MC0 uds协议

[wenqiang]

不是DEMO，之前DEMO没问题，用自己的APP也没问题，昨天APP新增了功能hex长度变长到0x7F70发现的问题，分块大小是0xD0。把hex内容裁剪到上一次编译的长度7D98恢复正常，看起来就是超过36 9B就会异常。编译器是VScode,优化等级默认的

[jiankang_wang]

下载的起始地址是多少？36服务会调用flash driver 写操作，这个操作需要地址8字节对齐。所以可以看看负相应的时候地址是多少。

[jiankang_wang]

参考这个帖子对比一下勒：https://forum.ytmicro.com/topic/1224/使用云途uds_pc_tool对单片机进行升级-在downloadfile最后一包数据时报错

[wenqiang]

非常感谢，修改擦除size后解决问题

[wenqiang]

其实地址0x8200,长度0x8430，hexview和CANoe boot上位机计算CRC32都是0xF2896B9A，麻烦帮忙看一下程序是不是哪里设置有问题，计算出来CRC32不对。

[wenqiang]

CRC设置

[jiankang_wang]

参考这个帖子，应该是上位机CRC算错了：https://forum.ytmicro.com/topic/936/uds_pc_tool使用问题/16?_=1754039742150

[wenqiang]

脚本计算没问题的，我用别的工具和客户的上位机程序都是一致的，就是程序里面debug算出来不对。

[jiankang_wang]

wenqiang 在 B1MC0 uds协议 中说：

其实地址0x8200,长度0x8430，hexview和CANoe boot上位机计算CRC32都是0xF2896B9A，麻烦帮忙看一下程序是不是哪里设置有问题，计算出来CRC32不对。

这里提到的长度正确吗？CRC计算的时候是会默认填充0xFF对齐的。不仅仅只是文件大小哈

[wenqiang]

长度0x8430是编译生成bin文件的长度，函数内填写的是0x8430 / 4 = 0x210C

[jiankang_wang]

对比一下字节序是不是正确的。最后把芯片flash上的部分数据是多少拉出来对比一下。

[wenqiang]

我读取了第一个数据，但是我CANoe脚本是通过单个字节查表方式计算的。

[jiankang_wang]

可以调试的话，建议四个字节四个字节对比着算。用你提到的工具先算四个字节的数据，与芯片实际写入到crc寄存器的一个word的结果做比较。如果第一个word计算结果是ok的，说明还是末尾处理的有问题，如果第一个word就算错了，那就是你crc设置的问题，可能原因有这些：

• crc多项式不匹配
• crc配置不一样
• 数据不一样

[wenqiang]

这些配置在哪里设置呢？另外还有个问题需要请教，由于boot demo只有物理寻址没有功能寻址，我新增了功能寻址直接link到一起，但是这样有个问题在刷写过程中36服务发送后等待回复30的时候一帧3E服务会打断本该回复的30，请问这种情况该如何解决。

[jiankang_wang]

CRC 对应的寄存器地址如下：

uds_can 写入CRC集成器代码的位置在 platform/drivers/src/crc/crc_driver.c 的 CRC_DRV_WriteData32 函数。

此外。后面提到的问题是否是CRC计算不对问题的一部分？如果后面有消息被中止了，没有做什么处理，CRC就应该是计算出错的。

---

在发送完首帧后，紧接着发送一个相同地址的单帧，会被认为是非法的：

从而导致首帧的传输被中止。

可以通过以下几种方式规避：

• 更改两帧消息的地址为不同的地址
• 上位机处理。加个状态机检测当前是否有长消息在发送过程中，如果有长消息就先不发送单帧。
• 下位机监听Tp层的错误，在Tp层的消息被中断时会通过 callback 报告：CANTP_CORE_N_UNEXP_PDU, 用户通过该 callback 增加消息传输中止导致的数据缺失问题。

[wenqiang]

与CRC问题无关。有更详细的解决方法吗，1、有没有在只有物理寻址的code上面新增功能寻址的demo可以参考。2、车端没法推动。3、没懂怎么改。

[jiankang_wang]

新增一个物理地址应该是最简单的解决方式。可以参考 can_stack 的 demo，里面有配置不同通道和地址的设置。

[wenqiang]

新增后，响应服务的接口还是跟物理寻址一样吗

[wenqiang]

找到了需要在uds_stack新增，非常感谢