B1MC0 uds协议

[wenqiang]

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

[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字节对齐。所以可以看看负相应的时候地址是多少。