B1MC0 uds协议

[wenqiang]

27服务报文02 27 01能正常进入处理，但是02 27 01 00 00 00 00 00 不能，应该修改哪里能不受报文长度限制，通过发送数据的长度02获取27 01？

[wenqiang]

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

[jiankang_wang]

如果不开padding的话，02 27 01 00 00 00 00 00 消息本身就不是一帧合法的 TP 报文：

如果要能识别该消息，需要打开对应端的Padding选项

[wenqiang]

[wenqiang]

改了这里padding设置后，有没有可能填不填充都能接收到的更改点呢

[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