工具/软件:
当我在此处测试 CAN 通信时、我很快发现向从动器件发送命令后、从动器件没有返回数据。 此时、我检查了 tcan4550 的中断 nINT 引脚、并发现它始终处于低电平。 芯片应该异常。

CAN 命令发送了 10 次。 从第 0 次到第 9 次、从器件可以回复数据。 在第 10 次之后、从器件不再回复 CAN 数据。


我非常焦虑。 请帮助我确定问题是什么以及如何解决
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
工具/软件:
当我在此处测试 CAN 通信时、我很快发现向从动器件发送命令后、从动器件没有返回数据。 此时、我检查了 tcan4550 的中断 nINT 引脚、并发现它始终处于低电平。 芯片应该异常。

CAN 命令发送了 10 次。 从第 0 次到第 9 次、从器件可以回复数据。 在第 10 次之后、从器件不再回复 CAN 数据。


我非常焦虑。 请帮助我确定问题是什么以及如何解决
尊敬的 Jimmy:
您似乎收到了一个未校正的 ECC 错误、该错误导致器件重新进入初始化模式(设置控制寄存器 0x1018[0]= 1 的 INIT 位)并停止 CAN 通信、从而导致 CAN 静音错误、进而导致设置 CAN 错误和全局错误位。

MRAM 单元在上电或复位后不会自动初始化为“0",“,但、但 ECC 计算假设所有未使用的位都具有值“0"。“。 如果在配置序列中未将缓冲单元初始化为零、则需要确保向 MRAM 元素(例如 TX 缓冲区)中的任何未使用字节写入零、以防止可能的 ECC 错误。
此致、
Jonathan
在阅读您的回复后、tcan4550 似乎没有重新进入初始化模式。 有以下两个原因:
初始化芯片时、整个 MRAM 有一个写入 0 操作、如下所示:
void m_can_init_ram(结构 m_can_classdev *cdev)
{
INT END、 I、 START;
/* 初始化 正在 使用的整个消息 RAM 以 避免 可能的情况
* 读取 未初始化 缓冲区时出现 ECC/奇偶校验和错误
*/
start = cdev->mcfg[MRAM_SIDF].off;
end = cdev->mcfg[MRAM_TXB].off +
cdev->mcfg[MRAM_TXB].num * TXB_Element_size;
对于 (I = START; I < END; I += 4)
m_can_fifo_write_no_off (cdev 、i、 0x0);
}
2..发生异常时、寄存器 0x1018 的值为 0、位 0 未设置为 1、如下所示:
第 1018 章:我的心
第 1019 章:我的心
101a: 00000000
101B: 00000000
101C: 00004409
e2e.ti.com/.../1464.regdump.txt
请检查一下。 以上是寄存器转储
e2e.ti.com/.../TCAN4550_2D00_SCH.pdf
另外、请检查此原理图是否正确。 如需进行任何修改、请详细说明
尊敬的 Jimmy:
好的。 我将查看您的寄存器日志和原理图、以了解 ECC 错误和 CAN 通信停止的可能原因。
您是否尝试过清除所有中断寄存器并查看它是否恢复 CAN 通信?
此错误是否可重复并且始终出现在第 10 帧上?
您是否有多个板或 TCAN4550 器件、如果有、您是否在多个器件上尝试了测试、以确定问题是否是器件特有的、这意味着它可能存在缺陷、或者您的所有器件上是否都出现这种情况、这意味着这可能是由寄存器配置问题引起的?
此致、
Jonathan
你好、Jimmy 和 Wang、
我不确定您使用的 TXB_Element_size 值是多少、但如果它不是 18、那么您可能无法根据我对初始化序列的理解、将分配的所有 MRAM 完全初始化为零。 TX 缓冲区元素有 2 个标头字(8 个字节)+从 TX 缓冲区数据字段大小寄存器(寄存器 0x10C8[2:0]中的 TBDS)分配的字节数。 目前、您有一个 64 字节的数据字段、即 16 个字。
如果您偶然为 TXB_Element_Size 使用 16 或 18、以验证是否可能未初始化所有 TX 缓冲器/FIFO 存储器。
从您的配置来看、您使用的 MRAM 大约为 97%、并且您只有 16 个未使用的 MRAM 字尚未初始化。 我建议初始化所有 MRAM (0x8000 至 0x87FF)、以确保不可能访问尚未初始化为零的存储器、并消除 ECC 错误的可能原因。
从您的数据日志中、我看到 MRAM 单元 0x87C0 至 0x87FF 是尚未初始化的随机值。 请尝试初始化这些字节、看看这样是否解决了您的 ECC 错误。

从原理图中可以看到、整体看起来正常。 我不知道晶体的负载电容要求是什么、但 OSC1 和 OSC2 的 22pF 电容器大约是 40MHz 晶体正常值的两倍。 由于 MCAN 控制器和数字内核直接使用晶体、因此该时钟的任何中断也会导致 SPI 和 CAN 通信错误。 通常、如果晶体电路未进行优化、当 OSC2 上的振荡电压降至 150mV 以下时、它可能会无法开始振荡、停止振荡、或者通过在单端时钟模式和晶体模式之间切换而发生中断。
另请查看 TCAN455x 时钟优化和设计指南应用报告 (链接)、了解更多信息。
此致、
Jonathan
MRAM 的整个 2K 空间已初始化为 0、但仍然会发生错误。 附件是寄存器转储、请帮助您重新查看。 谢谢!
MRAM 配置如下:
Bosch、MRAM-cfg =<0x0 0 0 22 0 5 5>;
将 MRAM 初始化为 0 的代码如下:
void m_can_init_ram(结构 m_can_classdev *cdev)
{
INT END、I、START;
/*初始化正在使用的整个消息 RAM 以避免可能的情况
*读取未初始化缓冲区时出现 ECC/奇偶校验和错误
*/
start = cdev->mcfg[MRAM_SIDF].off;
end = cdev->mcfg[MRAM_TXB].off +
cdev->mcfg[MRAM_TXB].num * TXB_Element_size;
START = 0;
END = 2048;
printk(“yjc %s MRAM clear start:0x%x、end:0x%x \n“、__func__、start、end);
对于 (I = START;I < END;I += 4)
m_can_fifo_write_no_off (cdev、i、0x0);
}
您好、王
日志文件未显示任何 ECC 错误。
错误计数器寄存器的 CEL 字段显示正在生成协议错误 (0x1040[23:16]= 24)。 REC 字段也>0 (0x1040[14:8]= 2)。
MCAN 中断寄存器 (0x1050) 设置了以下位:
[29] ARA — 这可能是由于您创建了错误日志,因为您不会限制读取正确的寄存器地址,并且对每个字节而不是每个字执行读取。 您还在从保留或不存在的寄存器地址读取数据。
[27] PEA — 在仲裁阶段检测到协议错误,这也是导致 CEL 计数器增加的原因。 我建议验证标称和数据位时序配置、以确保其与测试设置中的其他 CAN 节点的位时序配置完全匹配。 位时序配置中的任何差异都可能导致采样错误并导致此类错误。
[12] TEFN — 您有一条来自已成功发送消息的 TX 事件 FIFO 条目
[11] TFE - TX FIFO 为空且没有要传输的消息。
[0] RF0N - RX FIFO 0 有一条来自成功接收消息的新消息
中断寄存器 (0x0820) 仅指示 CAN 静音错误、这意味着在大约 1 秒的计时器内显性总线电平和隐性总线电平之间没有状态变化。
我实际上无法从该配置检测到任何配置问题。 器件正在发送和接收消息、尽管检测到一些协议错误、但不足以使器件进入总线关闭状态。 TX FIFO 中未加载消息、因此如果您希望器件发送消息、则可能需要确定 TX FIFO 为空的原因、这可能是应用固件错误导致的。
如果所有其他 CAN 总线节点的位时序配置设置相同、则可能需要评估晶体的时钟频率、以确保其在所需的容差范围内。 晶体的振荡频率随电容变化、因此如果电容太大、您的频率将减小、从而导致时间量子大于预期、这可能导致位时间比预期更长、这可能导致其他在更标称时钟频率下运行的器件出现采样误差。 我之前提到过,你的 22pF 电容看起来比我通常看到的大,所以你应该验证可以位具有预期的位周期与示波器,并且你可能需要尝试使用不同的电容值测试,如果你的电容太大.
此致、
Jonathan
1.我可以询问此错误发生了什么? 如何解决?
<4>[ 2.717032].(3)[1:swapper/0]yjc m_can_dev_setup m_can_version=32、is_peripheral=1
<4>[ 2.719212].(3)[1:swapper/0]tcan4x5x spi3.0(未命名的 net_device)(未初始化):无法初始化模块
<4>[ 2.720451].(3)[1:swapper/0]yjc tcan4x5x_init
源代码如下所示:
void m_can_config_endisable(结构 m_can_classdev *cdev、bool 启用)
{
u32 cccr = m_can_read (cdev、m_can_ccr);
U32 超时= 10;
U32 val = 0;
/*清除时钟停止请求(如果已设置)*/
if (cccr & CCCR.CSR)
cccr &=~CCCR.CSR;
if (enable){
/*启用 m_can 配置*/
M_can_write (cdev、M_can_ccr、cccr | CCCR.INIT);
udelay(5);
/*仅当 CCCR.INIT =“1"时“时、CCCR.CCE 才能设置/复位*/
M_CAN_WRITE (cdev、M_can_ccr、cccr | CCCR.INIT | CCCR.CCE);
}其他{
M_CAN_WRITE (cdev、M_can_ccr、cccr &~(CCCR.INIT | CCCR.CCE));
}
/*模块初始化有延迟*/
IF(启用)
VAL = CCCR.INIT | CCCR.CCE;
while ((m_can_read (cdev、m_can_ccr)&(CCCR.INIT | CCCR.CCE))!= val){
如果(超时== 0){
netdev_warn(cdev->net,“初始化模块失败\n“);
返回;
}
超时--;
udelay (1);
}
}
2、目前的问题非常紧迫,没有取得任何进展。 我能否询问是否可以将设备发送到您的现场进行分析?
e2e.ti.com/.../1_2800_4_2900_.txte2e.ti.com/.../0753.regdump.txte2e.ti.com/.../1_2800_7_2900_.txt
查看多个失败的寄存器转储的 e2e.ti.com/.../6076.1_2800_6_2900_.txt1.After(如附件中所示)0x1018 [0]始终为 0
0x0800 [7:6]的介绍无法在规格表中找到。 请提供。
3.我们能否从当前的现象和重新转储中确认是软件相关的问题还是硬件问题?
4.我们接下来应该如何分析?
e2e.ti.com/.../4370.1_2800_4_2900_.txte2e.ti.com/.../7103.regdump.txte2e.ti.com/.../6445.1_2800_7_2900_.txt
查看多个失败的寄存器转储的 e2e.ti.com/.../6076.1_2800_6_2900_.txt1.After(如附件中所示)0x1018 [0]始终为 0
0x0800 [7:6]的介绍无法在规格表中找到。 请提供。
3.我们能否从当前的现象和重新转储中确认是软件相关的问题还是硬件问题?
4.我们接下来应该如何分析?
5.需要什么信号波形来确认不存在硬件问题?
最新的regdump如附件、请帮忙看看。e2e.ti.com/.../1_2800_9_2900_.txt
尊敬的 Wang:
2.在规格表中找不到 0x0800 的介绍[7:6]。 请提供。
您可以在数据表中找到此信息。

3.我们能否从当前现象和 regdump 中确认这是软件相关问题还是硬件问题?
我在软件配置或器件中断中没有看到说明。 我可以看到 PEA 位被置位、指示消息在仲裁阶段出现协议错误、但错误计数器全部为零、协议状态寄存器不会指示器件处于警告或总线关闭状态。 因此、它可能不是器件停止通信的原因。
我所看到的是 TX FIFO 完全为空、并且没有加载要发送的消息。 如果原始投诉仍然是该器件在向其发送消息后没有响应、那么我预计会有消息加载到 TX FIFO 中、等待传输、或者该器件会由于过多错误而被禁用。
我目前不能说此器件或硬件的配置在功能上有任何问题、并且我当前对您提供的信息的解释表明将消息加载到 TX FIFO 以进行传输时出现了问题。
当发生 CAN 静音或无响应情况时、您是否可以验证 MCU 是否已将消息加载到 TX FIFO 中、并已写入 TX 缓冲区添加请求 (TXBAR) 寄存器 (0x10D8)、为用于消息的相应 TX FIFO 元素设置“1"?“?
TX FIFO 空闲级别设置为 5、这也等于 TX FIFO 大小、这意味着它完全为空。 TX 缓冲区请求挂起寄存器 (0x10CC) 也为 0x0、这意味着没有正在等待传输的 TX 消息。
我怀疑该错误可能与软件相关、并且 MCU 已停止将消息加载到 TX FIFO 中、从而导致您的 CAN 静音错误。
此致、
Jonathan
感谢您的答复!
第 158 次传输出现问题、应是由于 MCU 未成功发送、因此器件无响应。 但 MCU 会不断发送、表明传输成功、由于某种原因、未写入 TX FIFO。 此时、中断保持在低电平。
为什么 MCU 无法发送 TX FIFO?
DEV_sendCan 仍然正常、、但 未调用 DEV_receiveCan。
07-03 11:56:48.306087 3251 3325 D CanManager_307:可以发送数据:154、7df、0、0、8、 02、01、0d、55、55、 55、55、55、
07-03 11:56:48.307617 3251 3325 I fangkou-Zn193 CantestUtil: dev_sendCan, remaining data size: 16
07-03 11:56:48.313895 3251 3295 I 方口-Zn193 CantestUtil: dev_receiveCan, remaining data size: 37
07-03 11:56:48.314252 3251 3325 D CanManager_314:可以发送数据正常:16
07-03 11:56:48.316619 3251 3295 I fangkou-Zn193 CantestUtil: dev_receiveCan, remaining data size: 33
07-03 11:56:48.319502 3251 3295 I fangkou-Zn193 CantestUtil: dev_receiveCan, remaining data size: 57
07-03 11:56:48.325959 3251 3290 D CanParser_3026:cnvSpeedTypeJ1979 () 调用、速度:250
07-03 11:56:48.332885 3251 3290 D CanParser_3026:cnvSpeedTypeJ1979 () 调用、速度:250
07-03 11:56:48.400514 1275 1290 D LocationManager 服务:noteLocationAccess 失败、没有为软件包:com.duritech.tab.dtg 提供程序:gps 授予权限
07-03 11:56:48.400642 3251 3325 D CanManager_152:发送诊断数据
07-03 11:56:48.408341 3251 3325 D CanManager_307:可以发送数据:155、7df、0、0、8、 02、01、0c、55、55、 55、55、55、
07-03 11:56:48.410219 3251 3325 I fangkou-Zn193 CantestUtil: dev_sendCan, remaining data size: 16
07-03 11:56:48.415772 3251 3295 I 方口-Zn193 CantestUtil: dev_receiveCan, remaining data size: 45
07-03 11:56:48.415904 3251 3321 D DtgHelper_193:1秒数据:DtgSecData (infoDate=20250703115648、driveYMD=20250703、millis=1751543808935、speed=250.0、rpm=8674、 BRAKE =关闭、gpsX = 0.0、gpsY = 0.0、角度= 0、commState = 32、 ACC=1、距离=0.071)
07-03 11:56:48.416496 3251 3325 D CanManager_314:可以发送数据正常:16
07-03 11:56:48.418307 3251 3295 I fangkou-Zn193 CantestUtil: dev_receiveCan, remaining data size: 41
07-03 11:56:48.425804 3251 3290 D CanParser_3036:cnvRpmTypeJ1979 () 调用、RPM:8678
07-03 11:56:48.500675 3251 3325 D CanManager_152:发送诊断数据
07-03 11:56:48.506248 3251 3325 D CanManager_307:可以发送数据:156、7df、0、0、8、 02、01、0d、55、55、 55、55、55、
07-03 11:56:48.508211 3251 3325 I fangkou-Zn193 CantestUtil: dev_sendCan, remaining data size: 16
07-03 11:56:48.513987 3251 3325 D CanManager_314:可以发送数据正常:16
07-03 11:56:48.514546 3251 3295 I fangkou-Zn193 CantestUtil: dev_receiveCan, remained data size: 37
07-03 11:56:48.517158 3251 3295 I fangkou-Zn193 CantestUtil: dev_receiveCan, remaining data size: 33
07-03 11:56:48.519628 3251 3295 I fangkou-Zn193 CantestUtil: dev_receiveCan, remained data size: 57
07-03 11:56:48.526318 3251 3290 D CanParser_3026:cnvSpeedTypeJ1979 () 调用、速度:250
07-03 11:56:48.533225 3251 3290 D CanParser_3026:cnvSpeedTypeJ1979 () 调用、速度:250
07-03 11:56:48.601157 3251 3325 D CanManager_152:发送诊断数据
07-03 11:56:48.607225 3251 3325 D CanManager_307:可以发送数据:157、7df、0、0、8、 02、01、0c、55、55、 55、55、55、
07-03 11:56:48.608561 3251 3325 I fangkou-Zn193 CantestUtil: dev_sendCan, remaining data size: 16
07-03 11:56:48.615298 3251 3295 I fangkou-Zn193 CantestUtil: dev_receiveCan, remaining data size: 45
07-03 11:56:48.616117 3251 3325 D CanManager_314:可以发送数据正常:16
07-03 11:56:48.617329 3251 3295 I fangkou-Zn193 CantestUtil: dev_receiveCan, remaining data size: 41
07-03 11:56:48.624725 3251 3290 D CanParser_3036:cnvRpmTypeJ1979 () 调用、RPM:8678
07-03 11:56:48.700482 3251 3325 D CanManager_152:发送诊断数据
07-03 11:56:48.706331 3251 3325 D CanManager_307:可以发送数据:158、7df、0、0、8、 02、01、0d、55、55、 55、55、55、
07-03 11:56:48.707598 3251 3325 I fangkou-Zn193 CantestUtil: dev_sendCan, remaining data size: 16
07-03 11:56:48.714175 3251 3325 D CanManager_314:可以发送数据正常:16
07-03 11:56:48.800584 3251 3325 D CanManager_152:发送诊断数据
07-03 11:56:48.808291 3251 3325 D CanManager_307:可以发送数据:158、7df、0、0、8、 02、01、0c、55、55、 55、55、55、
07-03 11:56:48.809216 3251 3325 I fangkou-Zn193 CantestUtil: dev_sendCan, remaining data size: 16
07-03 11:56:48.812706 3251 3325 D CanManager_314:可以发送数据正常:16
07-03 11:56:48.900677 3251 3325 D CanManager_152:发送诊断数据
07-03 11:56:48.906386 3251 3325 D CanManager_307:可以发送数据:158、7df、0、0、8、 02、01、0d、55、55、 55、55、55、
07-03 11:56:48.907031 3251 3325 I fangkou-Zn193 CantestUtil: dev_sendCan, remaining data size: 16
07-03 11:56:48.912111 3251 3325 D CanManager_314:可以发送数据正常:16
07-03 11:56:49.000456 3251 3325 D CanManager_152:发送诊断数据
07-03 11:56:49.006431 3251 3325 D CanManager_307:可以发送数据:158、7df、0、0、8、 02、01、0c、55、55、 55、55、55、
07-03 11:56:49.007331 3251 3325 I fangkou-Zn193 CantestUtil: dev_sendCan, remaining data size: 16
07-03 11:56:49.012347 3251 3325 D CanManager_314:可以发送数据正常:16
07-03 11:56:49.100446 3251 3325 D CanManager_152:发送诊断数据
07-03 11:56:49.106518 3251 3325 D CanManager_307:可以发送数据:158、7df、0、0、8、 02、01、0d、55、55、 55、55、55、
07-03 11:56:49.107174 3251 3325 I fangkou-Zn193 CantestUtil: dev_sendCan, remaining data size: 16
07-03 11:56:49.111964 3251 3325 D CanManager_314:可以发送数据正常:16
尊敬的 Wang:
这很有趣。
您是否有可能在 SPI 总线上放置逻辑分析仪并将 MCU 和 TCAN4550 之间的 SPI 通信捕获到数据日志中?
如果 MCU 认为它正在发送消息、那么通常是 SPI 写入过程、此时消息数据将写入 TCAN4550。 不清楚 MCU 是否有一种机制来判断是否成功、而只是假定成功。 如果 SPI 总线出现问题、MCU 可能无法捕获到这个问题。
然而、当接收到消息时、会有更多的 SPI 读取、并且 MCU 可能更容易检测到某种 SPI 错误。
此外、对原始 SPI 读取/写入记录会导致并跟踪 CAN 静默错误、这有助于确定任何与器件相关的问题或需要调整的任何其他序列问题。
此致、
Jonathan
从日志中、第二次到最后一次通信出现异常。 MCU 成功发送 TX 数据后、它仅触发了一个中断、没有接收到从器件返回的任何数据。 没有与 m_can_ISR ir=0x1 相关的日志。
在最后一次通信之后、MCU 在不触发任何中断的情况下成功发送了 TX 数据、然后 MCU 停止发送。
整个通信过程的内核日志已上传、请帮助查看。
倒数第三次通讯:μ s
<4>[ 59.633474](5)[3369:RxComputationTh]yjc m_can_start_xmit start
<4>[ 59.633506](5)[3369:RxComputationTh]yjc m_can_start_xmit cdev->can.state=0、cdev->is_peripheral=1
<4>[ 59.633560](5)[3369:RxComputationTh]yjc m_can_start_xmit end
<4><[59.633626](5)[522:kworker/5:2]yjc m_can_tx_handler cdev->version=32、cf->can_id=0x7df
<4>[ 59.633649](5)[522:kworker/5:2]yjc tcan4x5x_read_reg reg=196
<4>[ 59.633925](5)[522:kworker/5:2]yjc tcan4x5x_read_reg reg=196
<4>[ 59.634174](5)[522:kworker/5:2]yjc tcan4x5x_write_fifo addr_offset=1768、val=528220160
<4>[59.634402](5)[522:kworker/5:2]yjc m_can_tx_handler putidx=4、id=0x1f7c0000、Cf->len=8
<4>[ 59.634428](5)[522:kworker/5:2]yjc tcan4x5x_write_fifo addr_offset=1772、val=76021760
<4>[ 59.634556](5)[522:kworker/5:2]yjc tcan4x5x_write_fifo addr_offset=1776、val=1426850050
<4>[ 59.634685](5)[522:kworker/5:2]yjc tcan4x5x_write_fifo addr_offset=1780、val=1431655765
<4>[ 59.634817](5)[522:kworker/5:2]yjc tcan4x5x_write_reg reg=208、val=16
<4>[ 59.634939](5)[522:kworker/5:2]yjc tcan4x5x_read_reg reg=196
<4>[ 59.635186](4)[3343:IRQ/123-CAN0]yjc m_can_ISR start444
<4>[ 59.635213](4)[3343:IRQ/123-CAN0]yjc tcan4x5x_READ_reg reg=80
<4>[ 59.635494](7)[3343:IRQ/123-CAN0]yjc m_can_ISR ir=0x1800
<4>[ 59.635522](7)[3343:IRQ/123-CAN0]yjc tcan4x5x_write_reg reg=80、val=6144
<4><[59.636269](7)[3343:IRQ/123-CAN0]yjc tcan4x5x_read_reg reg=244
<4>[ 59.636552](7)[3343:IRQ/123-CAN0]yjc m_can_echo_tx_event TXE_COUNT=1
<4>[ 59.636577](7)[3343:IRQ/123-CAN0]yjc tcan4x5x_READ_reg reg=244
<4>[ 59.636780](7)[3343:IRQ/123-CAN0]yjc tcan4x5x_READ_fifo addr_offset=1476
<4>[ 59.637023](7)[3343:IRQ/123-CAN0]yjc tcan4x5x_write_reg reg=248、val=4
<4>[ 59.637370](0)[3343:IRQ/123-CAN0]yjc tcan4x5x_read_reg reg=196
<4>[ 59.637609](7)[3343:IRQ/123-CAN0]yjc m_can_ISR start444
<4>[ 59.637636](7)[3343:IRQ/123-CAN0]yjc tcan4x5x_read_reg reg=80
<4>[ 59.637940](7)[3343:IRQ/123-CAN0]yjc m_can_isr ir=0x1
<4>[ 59.637965](7)[3343:IRQ/123-CAN0]yjc tcan4x5x_write_reg reg=80、val=1
<4>[ 59.638606](7)[3343:IRQ/123-CAN0]yjc tcan4x5x_write_reg reg=92、val=0
<4>[ 59.638985](7)[3343:IRQ/123-CAN0]yjc tcan4x5x_READ_reg reg=80
<4>[ 59.639208](7)[3343:IRQ/123-CAN0]yjc tcan4x5x_read_reg reg=68
<4>[ 59.639431](7)[3343:IRQ/123-CAN0]yjc tcan4x5x_READ_reg reg=164
<4>[ 59.639664](7)[3343:IRQ/123-CAN0]yjc tcan4x5x_read_fifo addr_offset=1300
<4>[ 59.639906](7)[3343:IRQ/123-CAN0]yjc tcan4x5x_READ_fifo addr_offset=1296
<4>[ 59.640198](7)[3343:IRQ/123-CAN0]yjc tcan4x5x_read_fifo addr_offset=1304
<4>[ 59.640431](7)[3343:IRQ/123-CAN0]yjc tcan4x5x_READ_fifo addr_offset=1308
<4>[ 59.640646](7)[3343:IRQ/123-CAN0]yjc tcan4x5x_write_reg reg=168、val=18
<4>[ 59.640936](7)[3343:IRQ/123-CAN0]yjc tcan4x5x_READ_reg reg=164
<4>[ 59.641160](4)[3343:IRQ/123-CAN0]yjc tcan4x5x_READ_fifo addr_offset=1372
<4>[ 59.641451](4)[3343:IRQ/123-CAN0]yjc tcan4x5x_READ_fifo addr_offset=1368
<4>[ 59.641687](4)[3343:IRQ/123-CAN0]yjc tcan4x5x_READ_fifo addr_offset=1376
<4>[ 59.641896](4)[3343:IRQ/123-CAN0]yjc tcan4x5x_READ_fifo addr_offset=1380
<4>[ 59.642153](4)[3343:IRQ/123-CAN0]yjc tcan4x5x_write_reg reg=168、val=19
<4>[ 59.642411](4)[3343:IRQ/123-CAN0]yjc tcan4x5x_READ_reg reg=164
<4>[ 59.642671](4)[3343:IRQ/123-CAN0]yjc tcan4x5x_write_reg reg=92、val=1
倒数第二次通讯:μ s
行 8074:<4>[ 59.734167](6)[3369:RxComputationTh]yjc m_can_start_xmit start
行 8075:<4>[ 59.734198](6)[3369:RxComputationTh]yjc m_can_start_xmit cdev->can.state=0、cdev->is_peripheral=1
行 8076:<4>[ 59.734261](6)[3369:RxComputationTh]yjc m_can_start_xmmit end
行 8077:<4>[ 59.734327](6)[43:kworker/6:0]yjc m_can_tx_handler cdev->version=32、cf->can_id=0x7df
行 8078:<4>[ 59.734350](6)[43:kworker/6:0]yjc tcan4x5x_read_reg reg=196
行 8079:<4>[ 59.734610](6)[43:kworker/6:0]yjc tcan4x5x_read_reg reg=196
行 8080:<4>[ 59.734939](6)[43:kworker/6:0]yjc tcan4x5x_write_fifo addr_offset=1480、val=528220160
行 8081:<4>[ 59.735068](6)[43:kworker/6:0]yjc m_can_tx_handler putidx=0、id=0x1f7c0000、cf->len = 8
行 8082:<4>[ 59.735094](6)[43:kworker/6:0]yjc tcan4x5x_write_fifo addr_offset = 1484、val = 8912896
行 8083:<4>[ 59.735270](6)[43:kworker/6:0]yjc tcan4x5x_write_fifo addr_offset=1488、val=1426915586
行 8084:<4>[ 59.735394](6)[43:kworker/6:0]yjc tcan4x5x_write_fifo addr_offset=1492、val=1431655765
行 8085:<4>[ 59.735524](6)[43:kworker/6:0]yjc tcan4x5x_write_reg reg=208、val=1
行 8086:<4>[ 59.735994](7)[3343:IRQ/123-CAN0]yjc m_can_ISR start444
行 8087:<4>[ 59.736022](7)[3343:IRQ/123-CAN0]yjc tcan4x5x_read_reg reg=80
行 8088:<4>[ 59.736497](6)[43:kworker/6:0]yjc tcan4x5x_read_reg reg=196
行 8089:<4>[ 59.737120](7)[3343:IRQ/123-CAN0]yjc m_can_ISR ir=0x1800
行 8090:<4>[ 59.737148](7)[3343:IRQ/123-CAN0]yjc tcan4x5x_write_reg reg=80、val=6144
行 8091:<4>[ 59.738076](5)[3343:IRQ/123-CAN0]yjc tcan4x5x_read_reg reg=244
行 8092:<4>[ 59.738269](5)[3343:IRQ/123-CAN0]yjc m_can_echo_tx_event TXE_COUNT=1
行 8093:<4>[ 59.738293](5)[3343:IRQ/123-CAN0]yjc tcan4x5x_read_reg reg=244
行 8094:<4>[ 59.738532](5)[3343:IRQ/123-CAN0]yjc tcan4x5x_READ_fifo addr_offset=1444
行 8095:<4>[ 59.738770](5)[3343:IRQ/123-CAN0]yjc tcan4x5x_write_reg reg=248、val=0
行 8096:<4>[ 59.739017](5)[3343:IRQ/123-CAN0]yjc tcan4x5x_read_reg reg=196
最后一次通讯:μ s
行 8105:<4>[ 59.833022](6)[3369:RxComputationTh]yjc m_can_start_xmit start
行 8106:<4>[ 59.833055](6)[3369:RxComputationTh]yjc m_can_start_xmit cdev->can.state=0、cdev->is_peripheral=1
行 8107:<4>[ 59.833128](6)[3369:RxComputationTh]yjc m_can_start_xmit end
行 8108:<4>[ 59.833196](6)[43:kworker/6:0]yjc m_can_tx_handler cdev->version=32、cf->can_id=0x7df
行 8109:<4>[ 59.833220](6)[43:kworker/6:0]yjc tcan4x5x_read_reg reg=196
行 8110:<4>[ 59.833528](6)[43:kworker/6:0]yjc tcan4x5x_read_reg reg=196
行 8111:<4>[ 59.834100](6)[43:kworker/6:0]yjc tcan4x5x_write_fifo addr_offset = 1552、val = 528220160
行 8112:<4>[ 59.834354](6)[43:kworker/6:0]yjc m_can_tx_handler putidx=1、id=0x1f7c0000、cf->len=8
行 8113:<4>[ 59.834381](6)[43:kworker/6:0]yjc tcan4x5x_write_fifo addr_offset=1556、val=25690112
行 8114:<4>[ 59.834568](6)[43:kworker/6:0]yjc tcan4x5x_write_fifo addr_offset=1560、val=1426850050
行 8115:<4>[ 59.834751](6)[43:kworker/6:0]yjc tcan4x5x_write_fifo addr_offset=1564、val=1431655765
行 8116:<4>[ 59.834985](6)[43:kworker/6:0]yjc tcan4x5x_write_reg reg=208、val=2
行 8117:<4>[ 59.835195](6)[43:kworker/6:0]yjc tcan4x5x_read_reg reg=196
从日志中、第二次到最后一次通信出现异常。 MCU 成功发送 TX 数据后、它仅触发了一个中断、没有接收到从器件返回的任何数据。 没有与 m_can_ISR ir=0x1 相关的日志。
尊敬的 Wang:
MCU 成功发送 TX 数据后、它仅触发了一个中断、没有接收到从器件返回的任何数据。 [/报价]我不确定这是否意味着器件返回的值为 0x0(因为这是正在读取的寄存器的值)、或者是否存在错误且返回的值为 0x0(因为器件未响应 SPI 读取)。
如果器件在 SPI 读取事务期间未能返回数据、则可能存在时钟问题。 数字内核和 MCAN 控制器直接由连接到 OSC1 和 OSC2 引脚的高速时钟(晶体)供电。 如果中断、数字内核将无法将寄存器数据加载到 SPI 接口 FIFO 中、MCU 将使用较慢的 SPI 时钟检索这些数据。 此外、MCAN 将无法发送或接收 CAN 消息。
在 SPI 写入事务期间、MCU 将使用 SPI 时钟将数据加载到 SPI 接口 FIFO 中、TCAN4550 数字内核将使用高速 OSC 时钟将该数据从 FIFO 中拉出。
同样、TCAN4550 数字内核将在 SPI 读取期间使用高速 OSC 时钟将数据加载到 SPI FIFO 中、MCU 将使用 SPI 时钟将该数据从 FIFO 中拉出。
如果 SPI 时钟或 OSC 时钟中断、SPI 通信将失败。 由于 SPI 通信由 MCU 控制、因此 TCAN4550 控制的唯一信号是 SDO (MISO) 信号。
在我之前的帖子中、我多次提出了时钟电路和晶体电容值。 我没有看到对这些注释的响应、但我需要您验证晶体电路是否正确优化并提供稳定的时钟。 此类与寄存器配置无关的大多数 SPI 和 CAN 错误通常是由时钟不稳定造成的。
在您的原理图中、我看到一个晶体器件型号为“7M1100002"和“和 22pF 电容器值。 搜索有关“7M1100002"的“的信息我只看到具有该器件型号且总负载电容为 12pF 的晶体的参考资料。
您能否验证特定晶体的总负载电容要求? 使用估算 3pF 的 PCB 电容和 22pF 负载电容器、我计算出您晶体上的近似总负载电容为 18.75pF。 如果负载电容器过大、则可能导致振荡停止或无法启动。 这些中断也可能是间歇性的、并会随其他条件(例如温度)而变化、进而导致寄生电容值发生变化。
请查看 TCAN455x 时钟优化和设计指南应用报告 (链接)。
如果您的晶体的时钟电容规格较低、您能否调整电路板上的电容值、看看是否因使故障频率增加或减少而使测试结果发生任何变化?
此致、
Jonathan