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 增加消息传输中止导致的数据缺失问题。
-
新增一个物理地址应该是最简单的解决方式。可以参考 can_stack 的 demo,里面有配置不同通道和地址的设置。
快速上手云途开发生态
发帖前请查看
帮助改进和优化YT CONFIG TOOL,有机会抽取YTM32B1ME0 EVB哦...