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 收发器是 TCAN1145。 最近、汽车的两个售后零部件不能被唤醒;
唤醒解决方案是通过特定消息进行唤醒、并通过 INH 引脚唤醒 MCU;
1.在基准测试中发现 CANH 和 CANL 持续短路人为导致 BUSOFF、偶尔会导致 CAN 收发器在睡眠后无法唤醒;
2.此时、INH 引脚始终为低电平、发送唤醒消息无法唤醒、并且 INH 引脚没有任何操作;
3.将 INH 引脚短接至电源并人为触发唤醒引脚。 MCU 可以正常唤醒、证明 MCU 唤醒逻辑正常;
4.强制唤醒后、INH 引脚仍然保持低电平、但是此时 CAN 通信可以正常;
5、电源必须关闭才能恢复;
请帮助分析在哪些情况下会导致 INH 引脚为低电平而无法唤醒;
Alan:
在测试中、您是否用两个有问题的器件将 INH 短接至电源? 如果器件能够通信但 INH 仍不为高电平、这可能会导致引脚损坏。 当控制器进入总线关闭状态时、CAN 收发器与其强制 INH 为高电平、还可能由于其自身的错误计数器而进入故障状态。 发生此情况后检查 ERR_CNTx 位和所有中断寄存器、清除中断、然后重试以唤醒器件。
此致、
Eric Hackett
您好、Eric、ö m
根据您的分析、该现象是否为失效防护模式?
但是、客户检查了代码、发现我们之前的初始化配置关闭了"故障保护模式";
还有哪些其他原因会导致 INH 保持低电平而无法唤醒?
您好、Eric、ö m
客户端转储的寄存器:
e2e.ti.com/.../TACN1145_5F00_Abnormal_5F00_dump2e2e.ti.com/.../TCAN1145_5F00_Normal_5F00_dump
您好、Eric、ö m
客户对此问题有另一个问题。 请帮助确认:
1.查看前面的代码可以看到已关闭"FSM 模式"和"SWE 计数"。 为什么"收发器无法唤醒、INH 始终为低电平"的问题仍然会出现?
2.这个问题的根本原因还不清楚。 发生问题时收发器处于什么状态?
3.比较测试发现,它是在清除中断后复位(51h,52h,53h)。 为什么错误的中断导致收发器异常? 哪些特定中断会导致此类异常?
Alan:
它们是使用选择性唤醒(WUF)还是 WUP?
我无法打开您包含的文件、这些文件的格式是什么? 如果未清除这些中断、则可能无法启用选择性唤醒。
您说即使通信正常、INH 始终较低、现在收发器是否处于正常模式? 您可以读取 MODE_SEL 位吗? 正如 Eric 所说、如果在正常模式下、INH 仍然输出低电平、这意味着该引脚可能由于对电源短路而损坏。 你用 INH 短接到电源或者所有其他装置的异常芯片上、是会发生这种情况吗?
此致、
Sean
你好、Sean、ć
客户使用特定消息唤醒、该消息应为 WUF
转储文件为 txt 格式、可使用 Notepad 或 Notepad++打开;
3. 比较测试发现、它在清除中断(51h、52h、53h)后复位。 为什么错误的中断导致收发器异常? 哪些特定中断会导致此类异常?[/QUOT]客户使用此处的复位操作后、恢复正常、所以我认为芯片没有损坏。 可能是客户对功能的理解不够好。 因此、我需要你们的帮助来找出导致这种情况的原因。
Alan:
"异常"器件设置了以下中断:
设置这些中断时、无法启用选择性唤醒、这就是它们 在睡眠后无法唤醒的原因。
但是、我不清楚为什么 INH 在正常通信期间仍然为低电平、因此它们使用 WAKE 引脚进行本地唤醒、并且在转换到正常模式后、INH 仍为低电平?
它们能否共享 CAN 总线和 INH 波形?
此致、
Sean
你好、Sean、
客户目前正在考虑如何从根本上解决此问题、仍有几个问题需要确认:
1.哪些特定中断会导致"无法启用选择性唤醒"?
2.当 CAN 收发器处于睡眠模式时、会出现总线错误。 这些中断会被触发吗?
3.如果我们禁用这些中断,它是否不会影响选择性唤醒?
4.如果这些中断被阻止、是否会有其他影响?
客户目前正在考虑两种解决方案:
解决方案1:在触发 CAN 收发器进入睡眠状态之前、清除所有中断、然后 MCU 进入睡眠状态;
但该解决方案的前提是 CAN 收发器在处于睡眠模式时不能进入错误中断。 如果 CAN 收发器在睡眠模式下也进入异常中断、则 MCU 已处于睡眠状态、并且 CAN 收发器无法唤醒、则无法恢复;
解决方案2:关闭所有可能导致 WUF 无法唤醒的中断、但这种解决方案是否可行、需要阻止哪些中断、以及阻止中断是否有其他影响、我需要您的专业建议。
您好、Alan:
也许我不应该说"unable to wakeup"、我的意思是、如果这些中断被设置、你就不能启用选择性唤醒。 实际上不会有任何中断阻止收发器在睡眠模式下唤醒。
查看"异常"器件的寄存器映射、MODE_SEL 显示收发器处于正常模式、这意味着收发器实际上已唤醒。 INH 在正常模式下应该为高电平、但是我不能解释为什么在正常模式下它仍然为低电平、但 CAN 通信正在进行。 这就是为什么我要让您分享这些波形、以了解当 INH 输出为低电平时 CAN 总线的行为。
1.见数据表10.4.5.1
2.帧错误计数器将递增,一旦达到阈值,帧溢出中断将被设置,收发器将被唤醒。 见10.4.5.7
3.它将禁用这些中断只能影响反映这些中断的 nINT 引脚输出。
4、"封锁"是什么意思? 已禁用? 它将只影响 nINT 输出、如3所述
首选解决方案1、我们建议清除所有中断、将选择性唤醒设置为待机模式、然后进入睡眠模式。 中断不会阻止收发器唤醒。
此致、
Sean
你好,Alan Xia,你解决了你的问题吗? 我有一个类似的问题,这是非常相似的。 也异常 睡眠和无法唤醒。 我也没有解决它。 在我去睡觉之前,我总是清除 INT。 下面是指向我的问题的链接:
如果你已经解决了它,请告诉我,谢谢。