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.

[参考译文] TCAN1145-Q1:在非 nm 帧后无法从睡眠状态唤醒

Guru**** 2465700 points


请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1477164/tcan1145-q1-wake-from-sleep-not-possible-after-non-nm-frames

器件型号:TCAN1145-Q1

工具与软件:

您好!

我们使用的是"选择性唤醒"功能、我们观察到一种我们无法解决并需要支持的特定行为。

在 Tresos 配置中、唤醒帧(WUF)的 CAN ID 设置为0x500、该帧用作 NM 消息。

 

  1. ECU 进入睡眠状态。
  2. 发送一条 NM 消息、然后 ECU 唤醒。 -预期行为
  3. NM 消息是停止发送的、然后 ECU 返回到睡眠状态。
  4. 发出非 NM 消息(任何应用程序 Rx 消息)然后 ECU 保持睡眠状态、没有唤醒。-预期行为
  5. 一条 NM 消息被发送到 ECU。 ECU 仍处于睡眠状态、不会唤醒、这是意外行为。

 

总之、进入睡眠模式后、我们会发送 nm 消息、并且仪表组会唤醒。 但是、如果它发送了另一条消息(与 NM 不同)、则集群不会唤醒、并且会卡在即使 NM 也无法唤醒集群的某种状态下。

 

我们发现、在步骤5之后、当在总线上发送 NM 消息时、CAN 收发器硬件寄存器不包含有效的检测数据、并且 CAN 收发器会保持睡眠模式。

 

当 NM 消息发送到 ECU 时、INT1_1寄存器(51h)的值应为0x40、但该值保持在0x00、CAN 收发器保持在睡眠模式

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Iulian:

    您是否会尝试在首次唤醒后清除 CANINT 中断? 建议在返回睡眠模式之前每次清除该中断。

    如果可行、请告诉我

    此致、

    Sean

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    你好、Sean、

    在当前软件中、是的、我们在首次唤醒和每次唤醒后都清除了 CANINT 中断、并且我们在每次返回睡眠模式之前都清除了此中断。

    仅在使用时出现当前问题 唤醒帧(WUF)集群不会唤醒并卡在某种状态、即使唤醒帧(WUF)也无法唤醒集群。

    当唤醒帧(WUF)消息发送到 ECU 时、NT1_1寄存器(51h)的值应为0x40、但该值保持在0x00、CAN 收发器保持在上述睡眠模式 AG 点5。

    我们需要详细了解导致收发器芯片无法检测到 唤醒帧(WUF)的原因  在 总线上发送唤醒帧(WUF]之前发送唤醒帧(WUF)。

    BR、
    Shrinidhi

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Shrinidhi:

    是、INT_1保持0x00、因为它未成功唤醒、因此未设置 CANINT 标志。

    我是否可以知道、在步骤4和5中、发送的 WUF 是否紧跟在 WUF 之后? 或者发送的两个帧之间有一个时间段?

    此外、您能否确认第5步中的 WUF 以配置的数据速率 SW_CONFIG_1发送?

    此致、

    Sean

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    你好、Sean、

    在步骤4和5中有延迟。 唤醒帧(WUF)会在非唤醒帧(非 WUF)之后大约2秒发送、而不是立即发送。

    步骤5中的 WUF 以配置的500kbps 数据速率发送、这与 CAN 收发器(cantrcv)驱动器配置中配置的数据速率相同。

    如前所述、仅当在 WUF 之前发送非 WUF 时、才会发生该问题。 否则、如果我们在每次睡眠后没有发送非 WUF、CAN 收发器都会在睡眠后检测到 WUF。

    BR、

    Shrinidhi

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Shrinidhi:

    2秒的时间周期过长、因此低功耗接收器 停用。 请注意、 需要有效的 WUP (可以是任何 CAN 帧)才能触发监控 WUF 的接收器。 如果在 tSLIENCE 计时器到期之前未检测到 WUF、WUF 接收器将处于非活动状态、您需要再次发送 WUP、然后发送匹配的 WUF。

    此致、

    Sean

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    你好、Sean、

    • 即使我们再次发送一个 WUP 后跟一个匹配的 WUF、也不会唤醒。 上述 TT 说明中的步骤4至步骤5后、Cantrcv 卡在某种状态。
    • 无论时序如何、如果我们没有先发送非 WUF、然后再发送 WUF、则不会观察到问题、并且每次我们唤醒时都是如此。
    • 为什么仅当先发送非 WUF、然后发送 WUF 时才会发生问题? 是什么导致 Cantrcv 卡住、即使使用有效的 WUP 和 WUF 也无法唤醒?
      您可以找到跟踪屏幕截图0x555h WUP 和 WUF (0x500h)

    BR、

    Shrinidhi

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Shrinidhi:

    您是否在非 WUF 之后"立即"发送了 WUF? 还是仍具有该2秒的延迟?

    需要 WUP (或任何总线活动)才能在睡眠模式下启用选择性接收器。 这是因为选择性唤醒接收器比低功耗接收器消耗更多的功率、因此选择性唤醒接收器将保持关闭状态、直到检测到总线活动。  

    在该测试期间是否可以捕获 CANH 和 CANL 信号的波形? 我们来考虑两种不同的情况:

    第2步:仅发送一个 WUF 并成功唤醒。

    发送 WUF 之前是否有任何总线活动? 我猜测控制器实际上不仅可以发送一个帧、如果未收到 ACK 位、则控制器可能会再次发送 WUF、因此您能否捕获 CAN 总线波形以及 INH 输出?

    步骤4和5:WUF 在非 WUF 之后发送、但没有唤醒。

    同样、请捕获上面提到的波形、可能控制器实际上没有发送 WUF、由于未接收到 ACK 位、它会持续发送非 WUF、然后从未检测到 WUF。

    此致、

    Sean

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    问题已经解决、谢谢。