B1MC0 uds协议

[jiankang_wang]

不行，这个是写死的。填充了就一定得手动固定长度的消息。不填充就不能手动过长的消息

[wenqiang]

为什么刷新过程中，编号会错乱

[wenqiang]

APPflash长度在0x7D98时一切正常，新增部分APP代码编译bin文件长度变长时，就会有上一问题。裁剪到0x7D98也能正常刷。

[jiankang_wang]

编号错乱是因为 0x36 的 0x9C 编号的报文出错了。返回负相应 0x72，所以继续传 0x9D 就是序号错了。
这是哪一个系列的芯片？还有一个帖子也是类似的问题，我排查一下。

[wenqiang]

用的芯片是B1MC0

[jiankang_wang]

好的，是直接使用的Demo下载吗？编译器是什么？对应的优化选项是什么

[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，请问这种情况该如何解决。