[参考译文] TMS570LS10106：器件勘误问题：DCAN 22

您好 Amanda、

我们从未在干净启动时看到过这种行为。 您提到的序列是 boot -> CAN_init 调用。 我们已经看到客户将切换 INIT 位以尝试从总线关闭状态释放的情况、这会导致问题。 我们需要确认、即使在热复位条件下、如果没有解决办法、初始化位也不会在代码中的任何位置设置。

通常、这需要一些条件断点的创造性用途来指示何时写入/触摸 INIT 位。  

Amanda、

另一个需要检查的问题是启动序列。 如果他们以某种方式初始化、则可以很早地执行 LBIST 功能、则会有一个 CPU 复位、这会导致代码重新执行、进而导致 按照通报中的描述、在没有外设复位的情况下对 INIT 位执行另一次写操作、并持续进行 CAN 通信。

你好、Chuck

我是有此问题的客户。 遗憾的是、我们无法在工作台上或以轻松附加调试设置的方式对其进行调试、从而打破这个问题

我们只有在整个系统中安装时才看到这一点、这种情况很少发生。 直到最近、这可能是1000次的一对一事件、但我们现在发现一辆车在20次尝试中表现出了这一问题、每100次尝试中就会出现1次。

如果您使用 LBIST 函数进行推理、则我们不使用自检控制器、除非它与标准 Halcogen 输出一同提供？

除了提供的 halcogen CAN_init()函数之外，还有一个其他位置可以处理 init 位。 我们在实践中发现、如果发生导致控制器进入错误模式的事件、控制器将保持关闭状态。 我们不能允许这种情况发生、因此我们会定期检查节点是否处于初始化模式、如果要将其恢复到"正常"模式、则将其清除。 此函数仅清除 INIT 位、不对其进行置位。 此外、该函数不执行其他操作。 也许这是我们的问题的一部分？ 如果我们进入错误状态并尝试使其恢复正常模式、我们还需要做什么？

您好、Nick、

这是我在其他几个客户中看到的一个非常类似的问题。 本质上、它们会清除 INIT 位、并需要特别小心以确保 CAN 通信的持续运行。 问题是、导致错误行为的原因是将 INIT 位清零。 我强烈建议您在清除 init 位时执行通报中建议的变通办法。 在过去、将此步骤添加到清除 init 位的任何代码中、也修复了出现的问题。

你好、Chuck

感谢您的回答、这是否意味着勘误表适用于您是设置还是清除该位？ 我们清除该位的问题是否与勘误表不同？

此外、我们怀疑清除 INIT 位可能是个问题、因此我们添加了一个 CAN 帧、每当此函数清除 INIT 位时、该帧就会发出。 我们得到了该问题的另一个再现、CAN 帧未发出。 我不确定这意味着什么、因为有两种可能：我们的问题不是由初始位的清除引起的、或者您无法传输 CAN 帧、除非您在清除初始位后等待一定数量的周期。 由于我们试图在清零该位后进行传输、那么外设可能会忽略该请求吗？

你好、Chuck

我们进一步改进了诊断、认为当代码检测到模块处于错误状态时清除 INIT 位是问题的原因。 我们用于执行此"从 eror 状态返回"的函数从 main while 循环调用、代码如下所示

if (hal_chassis _CAN_reinit()) CAN_init_counter++；

这是函数主体

bool TMS570_CAN_RESTE_IF_IN_INIT_MODE (canBASE-t*节点)
｛
  IF (节点->CTL & CAN_CTL_init)
  ｛
    NODE->CTL &=~CAN_CTL_INIT；
    返回 true；
  ｝
  否则返回 false；
｝

CAN_INIT_COUNTER 定期通过 CAN 发送；在事件重现之前和之后、计数器都保持为0。 我们还将电力线限定在微控制器中、它没有下降或欠压。 这导致我认为代码或控制器中存在问题、导致部分复位、然后双次调用 halcogen CAN_init 函数？ 奇怪的是、我们在启动该控制器时发出 CAN 帧、因此如果前面的理论为真、这意味着控制器正在重置、但仅以部分方式进行重置、因为它不会再次触发 CAN 帧？ CAN_init 的双次调用是否仍然与此处的问题类似？

我担心这一问题、因为问题很难重现、所以我想在应用修复之前确定问题。 因此、如果我们应用此"修复"而不识别问题、我们将无法判断问题是否已解决或只是更难重现

您好、Nick、

我理解驱动问题根本原因的愿望、因为修复程序可能掩盖另一个具有更大影响的意外行为、例如掉电条件。 当然、微控制器中有用于某种级别欠压保护的机制。 具体而言、如果电压下降到足以触发器件、VMON 将对器件发出复位命令。 问题是 VMON 是一种非常严重的保护机制、不能单独依赖。 您是否使用任何其他类型的外部电压监控器或电压监控器？ 即使如此、由于器件的数字特性、我也不认为电压骤降可能导致此类问题。 但是、这可能会导致 CAN 总线出现问题、从而导致您看到的 CAN 错误。

CAN 总线通常是一条5V 总线、该总线馈入收发器、然后作为3V 信号输出到网络中的 CAN 模块。 您是否知道设备看到哪些类型的错误导致设备停止传输？ 通常情况下、如果错误累积、CAN 总线将转换为总线关闭状态、此时将由硬件在恢复过程中设置 INIT 位。

当然、如果器件确实进行了任何类型的复位、它将再次执行初始化代码、除非您有一些保护措施来防止它。 您还可以通过检查代码中的 SYSESR 寄存器来查看这一点。 在某些情况下、如果不处理错误、则可能触发软复位、这也应加以考虑。 请查看 TRM 以了解包括异常处理在内的复位源、但如果发生这种情况、您会在执行引导代码时看到正在传输启动/引导消息。 此外、如果触发了复位、CAN 模块将像 SWR 一样进行复位、以解决 DCAN 22问题。

当您看到 CAN 模块停止通信时、是否仍有从 CAN 模块捕获错误数据？ 也就是说、我知道您说过您无法通过调试器查看它、但您能否通过 SCI 或 SPI 等其他串行线路访问它？ 如果没有其他内容、您可以将数据存储在闪存仿真 EEPROM (FEE)区域中吗？ 最终目标是了解 CAN 模块发生了什么情况、导致需要向 INIT 位写入数据才能使其再次运行。

你好、Chuck、

我曾尝试在控制器中对该问题进行某种一致的复制。 我已经尝试了各种技术来实现这一目标、包括设置 INIT 位和延迟模块配置、或者多次调用较大的 INIT 函数、而不是运气好使其更具重现性。 我想现在我们将尝试修复、然后通过其他方法增加周期尝试、以查看此更改是否对该问题有可衡量的影响。 我有另一个问题。 为什么这不能通过 Halcogen 代码中包含的 DCAN #22解决？ 这是我在勘误表中的第一个建议中的示例代码

静态空_TMS570_CAN_RESET (canbase_t*节点)
｛
NODE->CTL &=~(CAN_CTL_IE1 | CAN_CTL_IE0)；//禁用中断
node->CTL |= CAN_CTL_init；//将模块置于初始化模式
//等待6 + 1个 CAN 时钟周期以避免幻象中断、CAN 时钟=系统时钟
asm (" nop")；asm (" nop")；asm (" nop")；asm (" nop")；asm (" nop")； asm (" nop")；asm (" nop")；
NODe->CTL |= CAN_CTL_SWR；//重置模块
while (node->CTL & CAN_CTL_SWR)；//等待模块脱离复位状态
｝

您好、Nick、

赞赏 相关工作的实施。 我认为你应该看到问题消失了、但鉴于正常情况下的发生率很低、这肯定很难测量。

关于 HalCoGen 代码中未包含解决方法的原因、我并不完全确定。 鉴于需要基于 INIT 位的设置、软件团队可能根本没有预见到 INIT 函数可能被调用时会出现的错误情况。 最后、这是一个看起来未涵盖的临界情况。  

当然、在这一点上、鉴于器件的 NRND 状态以及可用于此类性质更新的有限软件资源、我不确定是否会发生任何变化。 在我们的较新器件上、如果不是 NRND、则 DCAN 22问题已修复、不再是问题。

你好、Chuck、

非常感谢您迄今提供的所有帮助！ Nick 最近介绍了实施 DCAN #22修复的方法、他们很确定它解决了接收函数在启动期间的内存损坏问题。 请参阅下面的修复...

但是、它们最近收到一个在接收到过多 CAN 总线错误后处于错误模式的单元。 Nick 认为这会强制 TMS570 CAN 驱动程序返回初始化模式、因为它没有特殊的错误模式。

Nick 说，他们现在已经用当前的错误检测和复位机制运行了一段时间，它用来清除 node->CTL 寄存器中的 INIT 位(这以前是正常的)。  然而、在他们执行 DCAN #22修复后、他们现在调用初始化函数、该函数会重新初始化驱动程序。 问题是、当驾驶员尝试此操作时、总线仍有流量、驾驶员挂起且从不会出现。

客户也提供了日志(e2e.ti.com/.../7484.test_5F00_out.txt)。 在此期间、他们的系统正在侦听三个 ID (0x180、0x186和0x500)、同时还使用0x691从这些 ID 中继信息。 每当它尝试从错误中重新初始化驱动程序时、它将在标记0xAB 时发送0x692。 如果您看一下日志的末尾、它似乎会重新初始化驱动程序、但仅返回传输函数。

请查看他们正在使用的函数、以尝试使 CAN 驱动程序恢复到运行模式...

此外，当它调用 hal_chassis _CAN_reinit()时，它将映射到下面的此函数...

客户根据所有这些问题有以下问题：

"一. 当总线包含来自其它模块的通信时、命令这个复位和初始化机制是否有问题？

2.引导后、建议采用什么方法使驱动程序脱离错误(init)并恢复运行 CAN 总线上的流量？ 这与引导期间的初始化方法是否不同？

3.有没有关于使用流量初始化 CAN 驱动程序的内容会导致它在进入"运行"之前等待总线上的"安静"窗口？ 如果是这样、我们可以做什么来使模块从错误模式返回到在总线包含 CAN 流量时运行"

感谢您提供任何意见。 感谢您花时间与我们一起了解这一点。

此致、

-Amanda

您好、Amanda、

一位同事和我查看了您发布的详细说明和代码、我们看不到有关 DCAN 22工作实施方式的任何具体问题。 当然、在 CAN 初始化期间、CAN 总线上可能会有流量。 这是正常情况、不应阻止初始化例程完成。

此外、您能否澄清这两项陈述的含义？

[引用用户="Amanda Ross95"]问题是，当驾驶员尝试此操作时，总线仍有流量，驾驶员挂起而不会出现。

和  

[引用 user="Amanda Ross95">每当尝试从错误中重新初始化驱动程序时，它都会在标记0xAB 时发送0x692。 查看日志的末尾、似乎是重新初始化驱动程序、但仅返回传输函数。

这些说法似乎是矛盾的。 也就是说、它从未完成 CAN_Init、但它会恢复发送功能？ 通常、如果没有接收到任何内容、他们能否检查总线上是否有数据包被忽略/不接收？  需要接收的 CAN 报文的发送器是否有可能已经脱离总线？ 如果没有、并且总线上有一条消息根本没有被接收、那么是否正确设置了 Rx 掩码？ 如果它在驱动程序中挂起，它在哪里挂起？

你好、Chuck、

很抱歉出现冲突的陈述。 下面我要说的是：CAN 初始化似乎没有挂起、它确实完成了；然而、完成后、只有 CAN 传输才起作用。 接收功能不再工作。

奇怪的是、这完全相同的函数在引导时调用、并且每当主代码循环检测到模块处于初始化模式(我们将其解释为进入错误模式的 CAN 驱动程序)。 也许处理 CAN 消息接收的邮箱也需要一个额外的步骤或过程来重置它们？ 这似乎是我们最后遇到的问题、除了接收邮箱在启动时有坏数据之外、如果您尝试在启动后重置 CAN 驱动程序、它们没有数据

Rx 掩码和滤波器设置与我们在引导时调用此函数时完全相同、因此我认为问题不存在、除非在总线上存在流量或邮箱存储器已包含某些流量时设置邮箱有什么不同 消息？

CAN 报文的发送器没有关闭总线。 您可以在日志中看到它仍在发送消息。 在这种情况下、有两个不同的节点：一个发送0x500消息、另一个发送0x180和0x186。 日志显示、在逆变器使用 INIT 函数将 CAN 驱动器从 INIT 中拉出后、它不再中继这些消息、因为它不接收任何消息

您好、Nick、

第一，在巴士上的交通问题上，这与问题无关，因为我们预计巴士在初始启动时也可能会有交通的情况，所以我认为这不会对现时的问题有任何影响。 据称、会发生某种灾难性错误事件、导致系统脱机或启动其错误处理逻辑、包括 DCAN 22工作原理。

您是否能够捕获演示事件的任何日志文件？ 即导致 CAN 驱动器最终死亡的一系列错误？ 当错误恢复发生时、您是否已确认 ID 屏蔽设置、以确保收到的消息不会由于配置的掩码更改而被关闭？

您好、Nick、

很高兴听到问题得到解决。 像往常一样、让我知道是否出现任何其他问题、以及我是否可以提供任何帮助。