我的 CAN 总线在 TM4C129XNCZAD (15个份额/位、TSeg1、TSeg2、SJW = 13、1、 1 (寄存器值+1))和一个单端(TXSPG、RXSPG)的 SN65HVD230DR 以及一个 LM3S2793 (10个份额/位、TSeg1、TSeg2、SJW = 8、1、 1 (寄存器值+1))和另一端(TXTCU、RXTCU)的 SN65HVD230DR。 我正在监控 RX 和 TX 引脚、因此我不加载总线。 这是一条长总线；我发现500ns 和600ns 总环路延迟(从 Tx 到 Rx)也存在同样的问题。
下面是显示错误的消息、然后在下一次尝试时成功传输：
这是第一个数据包末尾的缩放：
TXSPG 的 CRC 定界符的末尾非常接近屏幕中心。 就在屏幕中间、TXTCU 用一个 ACK 进行响应、该 ACK 在沿传输线路向下行驶后被 RXSPG 检测到、然后 TXSPG 在同一位时间内抛出活动错误。 为什么？
根据博世标准，我看到以下内容：
这是一个位时间太早、不能成为 Ack 错误(标志从下一位开始、而不是在 Ack 时隙期间)。
这两个位太早、不能成为 CRC 错误(标志从 Ack 分界符后面的位开始)
在仲裁和 Ack 期间、位错误有一个例外、因此它不是这样。
CRC 中的先前位为0b10110110 (0xd6)、因此它不是填充错误。
这只会导致格式错误(SOF、EOF、ACK 定界符和 CRC 定界符、符合 sloa101b.pdf)。 SOF 之前有很多位、ACK 和 EOF 仍在未来、因此时序使其看起来像是 CRC 形式错误、但我看不到它。
我缺少什么？
问得好。 数据表中有一些有趣的措辞：
' LEC 位域保存的代码表示 CAN 总线上最后一次发生的错误的类型。 这种情况
当一个消息被无错误地传输(接收或发送)时、此位域被清除。 。
CPU 可以写入未使用的错误代码0x7来手动将该域设置为无效错误
以便稍后可以检查它是否有更改。"
在上面的示例中、左侧数据包有错误、右侧数据包无错误地传输。 粗体语句是否意味着我必须在右边的数据包传输之前检查 LEC？ 这意味着我需要在 LEC 上设置一个中断来检查这一点。
使用"最后一个错误代码"的名称、似乎该错误将是静态的、直到它被0x7读取和覆盖。
作为示例、中的寄存器列表 
显示了 LEC 值0x5。 是在中断上捕获的吗？
似乎是时候拉出调试器了！
