-
1. 基于 MD14 开发板对问题进行复现
1.1 问题背景
- 软件：MCAL2.3.0 Flstst Demo + LIN
- 硬件：MD14
- 问题描述：
- Flstst 后台测试，GPT 10ms 中断回调函数中调用 FlsTst_MainFunction
- MD14 LIN 采用从机模式
- 使用 TSMaster 循环发送 0x3C（经典校验） 主机写 和 0x0D（增强校验） 主机读报文
- 上位机发送 0x0D 主机读报文，MCU 在正常情况下回复：0xFF 0x7F 0x00 0x00 0xE0 0xFF 0xFF 0xFF，当出现 checksum 后，MCU 会回复：0xFF 0xFF 0x00 0x00 0xE0 0xFF 0xFF 0xFF
- 由于 FlsTst_MainFunction 中会调用 SchM_Enter_FlsTst_FLSTST_EXCLUSIVE_AREA_02 和 SchM_Exit_FlsTst_FLSTST_EXCLUSIVE_AREA_02 函数开关全局中断，会导致 LIN 功能开启后，即便尚未填入接收所需的数据，只要收到报头，硬件就会自动接收数据并将其写入寄存器。此时若已收到报头，但后续被其他中断或线程打断，导致接收配置尚未完全填入寄存器，就会触发 CheckSum 错误。
1.2 问题复现
1.2.1 时间测试
- 验证 GPT 10ms 定时是否准确，使用逻辑分析仪抓取 IO 反转波形，是 10ms
- 计算 FlsTst_MainFunction 中 SchM_Enter_FlsTst_FLSTST_EXCLUSIVE_AREA_02 和 SchM_Exit_FlsTst_FLSTST_EXCLUSIVE_AREA_02 函数的时间是 57.75us
- 一次 FlsTst_MainFunction 计算 64Byte 大小的数据， 每次 SchM 保护阶段计算 8Byte 数据
1.2.2 测试方式 1
- TSMaster 发送 0x3C（经典校验，主机响应） 和 0x0D（增强校验，从机响应） 两种报文，周期都为 20ms
- TSMaster 发送一段时间后会触发 LIN Checksum Error，asd_test 是出现 Checksum Error 时 LINCFR 寄存器的值，此时是 0x57。TSMaster 0x3C 报文的校验和就是 0x57
- 下图为逻辑分析仪抓取出现 LIN Checksum Error 时的波形图，多次测试发现只有在 LIN 总线（Channel 2）数据段第一个 Byte 的起始位和停止之间触发 LIN 中断并执行 Lin_Lld_HandleHeaderRecInt （Channel 1），且此时还处于 FlsTst_MainFunction（Channel 0）函数执行期间，就会触发 LIN Checksum Error
- Channel 0：高电平持续时间为 FlsTst_MainFunction SchM 保护的时间
- Channel 1：高电平持续时间为 Lin_Lld_HandleHeaderRecInt 函数的执行时间
- Channel 2：LIN 总线波形
1.2.3 测试方式 2
- TSMaster 发送 0x3C（经典校验，主机响应） 和 0x0A（增强校验，主机响应） 两种报文，周期都为 20ms
- TSMaster 发送一段时间后会触发 LIN Checksum Error，asd_test 是出现 Checksum Error 时 LINCFR 寄存器的值。
- 此时是 0x57。TSMaster 0x3C（经典校验） 报文的校验和就是 0x57
- 此时是 0x67。TSMaster 0x0A （增强校验）报文的校验和就是 0x67
- 下图为逻辑分析仪抓取出现 LIN Checksum Error 时的波形图，多次测试发现只有在 LIN 总线（Channel 2）数据段第一个 Byte 的起始位和停止之间触发 LIN 中断并执行 Lin_Lld_HandleHeaderRecInt （Channel 1），且此时还处于 FlsTst_MainFunction（Channel 0）函数执行期间，就会触发 LIN Checksum Error
- Channel 0：高电平持续时间为 FlsTst_MainFunction SchM 保护的时间
- Channel 1：高电平持续时间为 Lin_Lld_HandleHeaderRecInt 函数的执行时间
- Channel 2：LIN 总线波形
1.2.4 测试方案 3
- TSMaster 发送 0x3C（经典校验，主机响应） 和 0x3D（经典校验，主机响应） 两种报文，周期都为 20ms，压测 12 小时左右，未出现 Checksum 错误
1.2.5 测试方案 4
- TSMaster 发送 0x3D 或 0x3C（经典校验，主机响应）和 0x0D（经典校验，从机响应）两种报文，周期都为 20ms，若上位机发送为 ID 为 0x3D，代码里需要修改 0x3D 的 dir 为 PDU_RX
- 发送 0x3D（经典校验，主机响应）和 0x0D（经典校验，从机响应）
- 发送 0x3C（经典校验，主机响应）和 0x0D（经典校验，从机响应）
- TSMaster 发送一段时间后会触发 LIN Checksum Error，asd_test 是出现 Checksum Error 时 LINCFR 寄存器的值。
- 此时是 0xC7。TSMaster 0x3D（经典校验）报文的校验和就是 0xC7
- 此时是 0x57。TSMaster 0x3C（经典校验） 报文的校验和就是 0x57
- 下图为逻辑分析仪抓取出现 LIN Checksum Error 时的波形图，多次测试发现只有在 LIN 总线（Channel 2）数据段第一个 Byte 的起始位和停止之间触发 LIN 中断并执行 Lin_Lld_HandleHeaderRecInt （Channel 1），且此时还处于 FlsTst_MainFunction（Channel 0）函数执行期间，就会触发 LIN Checksum Error
- Channel 0：高电平持续时间为 FlsTst_MainFunction SchM 保护的时间
- Channel 1：高电平持续时间为 Lin_Lld_HandleHeaderRecInt 函数的执行时间
- Channel 2：LIN 总线波形
1.2.6 测试方案 5
- TSMaster 发送 0x3D 和 0x3C（经典校验，主机响应）两种报文，单帧发送，但是接收到 0x3C 报文时，会启动定时器，在 LIN 中断里做一个延时，让中断执行时间拉长到数据段第一个 Byte 的起始位中间再结束，此时 0x3C 报文必触发 Checksum Error
- 下图为逻辑分析仪抓取出现 LIN Checksum Error 时 0x3C 报文的波形图，当 LIN 中断处理时间超过数据段第一个 Byte 的起始位到达的中间时，就会触发 Checksum Error
1.2.7 测试总结
1.3 根因分析
1.3.1 全局中断开关导致 LIN 配置延迟（核心诱因）
- FlsTst_MainFunction 函数会调用 SchM_Enter_FlsTst_FLSTST_EXCLUSIVE_AREA_02 与 SchM_Exit 函数，该过程会开关全局中断（耗时 57.75us），且函数单次处理 64Byte 数据（SchM 保护阶段每次处理 8Byte）。当 LIN 硬件收到报头后，会自动开始接收数据并写入寄存器，但此时若被 SchM 的全局中断保护打断，LIN 接收配置（如 BIDR 寄存器参数）无法及时、完整填入寄存器，导致后续数据接收的校验逻辑异常。
1.3.2 BIDR 寄存器写入时机限制（硬件约束）
- 根据 BIDR 寄存器（LINFlexD 模块关键配置寄存器）的功能特性及测试验证：
- 寄存器需在LIN 收到报头后、数据段第一个 Byte 起始位前完成写入，否则硬件判定为 “数据接收阶段已启动”，拒绝后续配置写入（如 DIR 字段 “方向控制” 在接收开始后无法修改）；
- 若延迟至数据段第一个 Byte 起始位后再写入 BIDR（如测试中通过软件延时模拟），配置无效且必触发 Checksum 错误，印证了 “配置时机窗口过短” 的硬件约束。
1.3.3 Checksum 错误判定逻辑的实际映射
- 从硬件逻辑代码可知，Checksum 错误的理论判定条件是 “在数据 Byte 的 STOP 位，满足stop_sample_data_pulse=1、ccd=0、chsu_r≠0”，即仅在 STOP 位校验。但实际测试中 “起始位后报错” 的现象，本质是配置延迟导致硬件在 STOP 位校验时，使用了不完整的配置参数计算校验和，最终表现为 “起始位后错误触发”，并非判定逻辑异常。
1.4 解决方案
- 采用软件 Checksum 校验替代硬件校验，可直接避免因硬件配置延迟导致的校验错误，且已通过测试验证有效性。
- 将 Lin_Lld.c 文件直接替换即可，注意当前软件方案只是 LIN 做从机的时候用软件 Checksum。
Lin_Lld.zip
-
Y yt0069 从 MCAL BUGS 移动了该主题
快速上手云途开发生态
发帖前请查看
帮助改进和优化YT CONFIG TOOL，有机会抽取YTM32B1ME0 EVB哦...