B1MC0 uds协议
-
编号错乱是因为 0x36 的 0x9C 编号的报文出错了。返回负相应 0x72，所以继续传 0x9D 就是序号错了。
这是哪一个系列的芯片？还有一个帖子也是类似的问题，我排查一下。 -
好的，是直接使用的Demo下载吗？编译器是什么？对应的优化选项是什么
-
下载的起始地址是多少？36服务会调用flash driver 写操作，这个操作需要地址8字节对齐。所以可以看看负相应的时候地址是多少。
-
参考这个帖子，应该是上位机CRC算错了：https://forum.ytmicro.com/topic/936/uds_pc_tool使用问题/16?_=1754039742150
-
wenqiang 在 B1MC0 uds协议 中说：
其实地址0x8200,长度0x8430，hexview和CANoe boot上位机计算CRC32都是0xF2896B9A，麻烦帮忙看一下程序是不是哪里设置有问题，计算出来CRC32不对。
这里提到的长度正确吗？CRC计算的时候是会默认填充0xFF对齐的。不仅仅只是文件大小哈
-
对比一下字节序是不是正确的。最后把芯片flash上的部分数据是多少拉出来对比一下。
-
可以调试的话，建议四个字节四个字节对比着算。用你提到的工具先算四个字节的数据，与芯片实际写入到crc寄存器的一个word的结果做比较。如果第一个word计算结果是ok的，说明还是末尾处理的有问题，如果第一个word就算错了，那就是你crc设置的问题，可能原因有这些：
- crc多项式不匹配
- crc配置不一样
- 数据不一样
-
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 增加消息传输中止导致的数据缺失问题。
为什么刷新过程中，编号会错乱
APPflash长度在0x7D98时一切正常，新增部分APP代码编译bin文件长度变长时，就会有上一问题。裁剪到0x7D98也能正常刷。
CRC设置
快速上手云途开发生态
发帖前请查看
帮助改进和优化YT CONFIG TOOL，有机会抽取YTM32B1ME0 EVB哦...