[参考译文] TMS320F28067：CAN Tx 随机停止工作

您似乎遇到了 SPRZ432N 第22页中描述的"意外停止传输操作"。 在这种情况下、您能否检查模块是否继续正常接收？

您好、Haresh、

您能否发布指向该文档的链接？ 谷歌找不到它;-)

嗯、我只能代表我的同事发言、并要求他核实我的下一个发言。

"通常、我们在 CAN 控制器收到任何消息时立即收到中断、但显然我们不再收到任何中断。"

但是、我们当然可以在某些后台任务中手动读取 Rx 邮箱、因此清除 Rx 邮箱、然后检查新消息是否到达(无论是否触发 IRQ)。 因此、我们可以检查接收方向。

请注意、由于问题发生在我同事的办公室(我们访问测试站的权限有限)、我只需通过桌面共享向我的同事调试问题、我需要大约1周的时间才能获得更多信息。

Andreas

您好、Haresh、

好的、我已经知道、在我们的错误条件下、通常在收到消息时调用的 IRQ 函数不再被调用。 这意味着我必须编写一个函数、该函数读取后台任务中的 Rx 邮箱并递增自己的 Rx 读取计数器、因为某些内容不能用于 IRQ 生成。

‘，如果我们确实面临着“意外停止传输操作”问题，那么我希望出现以下情况：

1) 1)我们重现错误情况。

2) 2)我确保以下函数被调用一次：

3) 3)我检查以下各项：

  a)我在 CAN 总线上看到邮箱0内挂起的消息正被直接传输。

  b)或者、在我的上述函数中通过 EINT 重新启用 IRQ 之前、我将在邮箱0中插入一条自己的测试消息并设置 CANTRS 的位0。

您能‘一下我在上面写的名为“LeaveUnexpectedCessationOfCanTransmit”的函数是否包含了从勘误表中描述的情况中摆脱所需的所有内容？

您能否告知我们在调用函数时是否期望邮箱0内的消息被发送、或者是否需要再次设置发送请求位(第3a 点与第3b 点)？

如果我们在 CAN 总线上看不到任何内容，那么我们很可能会面临一个不同的问题，无论 Rx 是否继续工作(因为勘误表指出，使用上述函数，我们就可以摆脱这种错误状况)。 你同意吗？

Andreas

[引用]好的、我已经知道、在我们的错误条件下、通常在收到消息时调用的 IRQ 函数不再被调用。 [/报价]

这意味着接收也已停止。 这与当时的勘误表问题不一样。 您是否检查了是否确实在总线上传输了消息？ 如果您使用的是 CAN 总线分析仪、您是否在这种情况之前在总线上看到了任何错误帧？ 节点是否处于脱离总线状态？ 如果是这样、您应该会看到 CCR 位被置位。 你是吗？  

[引用]这意味着我必须编写一个函数、该函数读取后台任务中的 Rx 邮箱并递增自己的 Rx 读取计数器、因为某些内容不能用于 IRQ 生成。 [/报价]

我不赞同。 如果未生成接收中断、您需要了解原因。  

[引述]无论如何，如果我们确实面临‘意外停止传输操作’的问题，那么我希望：  

1) 1)我们重现错误情况。 [/报价]

根据我们过去的经验、我们未能在实验室中"按意愿"重现此错误条件。  

[引用]2)我确保调用以下函数一次：[/引用]

如果这确实是勘误问题、这将处理这种情况。 目前，我们不确定是否确实如此。 另请注意、您的函数也可用于清除总线关闭条件。 此外、什么会导致您的代码执行该函数？ 您的应用应该感应某种超时条件才能调用此条件、对吧？  

[引用]a)我在 CAN 总线上看到邮箱0内挂起的消息正被直接传输。  

b)或者、在我的上述函数中通过 EINT 重新启用 IRQ 之前、我将在邮箱0中插入一条自己的测试消息并设置 CANTRS 的位0。 [/报价]

为什么不利用 eCAN 的邮箱超时功能？ H/W 将自动为您处理这一问题、而不是代码。  

[‘]您能否验证我编写的名为“LeaveUnexpectedCessationOfCanTransmit”的上述函数是否包含从勘误表中描述的情况中摆脱所需的所有内容？ [/报价]

如前所述、确定您看到的确实是勘误问题非常重要。 考虑到接收也已停止、我想知道节点是否真正处于 BO 状态。 另一个注意事项是、在检查 CCE 位时、您没有使用32位 R/W。 您应该执行如下操作：

操作
｛
ECanaShady.canes.all = ECanaRegs.canes.all；
｝ while (ECanaShading.canes.bit.CCE！= 1)；//等待 CCE 位被置位

[报价]您能否告知我们在调用函数时是否期望邮箱0内的消息被发送、或者是否需要再次设置发送请求位(第3a 点与第3b 点)？ [/报价]

我想这就是你要问的：让我们假设模块处于错误状态。 代码调用 LeaveUnexpectedCessationOfCanTransmit()函数。 MBX0中的消息会在该消息之后自动发送、或者代码应再次设置 TRS。 假设这是您的问题、答案如下：我希望数据输出、而不必再次设置 TRS。 但是、我尚未在器件中验证这一点。 如前所述、我在实验室中未能成功重现此情况。  

[引述]如果我们在 CAN 总线上看不到任何内容，那么我们很可能会面临一个不同的问题，无论 Rx 是否继续工作(因为勘误表指出，使用上述函数，我们就可以摆脱这种错误状况)。 你同意吗？ [/报价]

我不清楚你在这里要问什么。

您好、Haresh、

首先、请回答您的问题并发表意见：

1) 1)我同意、我们需要确定当总线上有电报时、CAN IRQ 为何不再被调用(因此、为什么由于接收到的消息而没有 IRQ)。 我也同意、我们还不能说我们面临的情况与勘误表中描述的情况相同。

2) 2)我的同事检查了器件中的错误历史记录、我们之前确实遇到了总线关闭情况。 我的同事通过我们正在使用的 CAN 堆栈供应商(公司端口)的函数清除了总线关闭条件、因此应该清除总线关闭条件。 如果需要、我可以为您提供该函数的源代码。

3) 3)我还有一个测试站、遗憾的是、它很少显示问题。  我还无法连接到测试站中的调试器、但我启用了自动总线打开(ABO)位、因此我也停止了调用清除总线关闭的软件函数。 即使在 ABO 设置为 true 的情况下、我仍然能够重新创建该情况。 但坦率地说，我不能说我同事的试验站的情况和我的问题是一样的，我需要做更多的试验。

4) 4)我们只在出现错误情况时测量总线流量、所以我不能说之前是否有错误帧。 但是、之前的脱离总线条件仅在出现错误帧时出现、对吧？

5) 5)我知道我同事的测试站、在之前就存在了公共汽车关闭状态、但后来又被清除了。 当错误发生时、CCR 位肯定为0、这是我们检查的第一件事。 也许清除总线关闭的源代码有一个错误的时序或者不等待 CCR 位被置位/清零作为对 CCE 设置的确认、我需要检查这个情况。

6)是的、我的代码必须感应 Tx 的某些超时、然后调用我的函数'LeaveUnexpectedCessationOfCanTransmit'。 但是、这是我们在设法在 CAN 总线上再次获取消息后实施的操作。

感谢您提示我应该使用'ECanaShady.canes.all'应用32位读取指令。 我将更新我的代码。

7)关于我的陈述：

"如果我们在 CAN 总线上看不到任何东西、那么我们很可能会面临一个不同的问题、无论 Rx 是否继续工作(因为勘误表指出、借助上述功能、我们可以摆脱这种错误情况)。 您同意吗？"

如果我们面临我所描述的错误情况、并且如果我们没有从 Tx 方向的错误情况中退出(这意味着、如果我们看不到器件发送的任何消息)、那么我们会由于以下事实而面临另一个问题： 我编写的函数肯定会确保一个放置在我们邮箱内的 Tx 消息在 CAN 总线上传输。

8) 8)关于硬件超时功能、我只需要阅读它。 我尚未完全了解功能、但我们肯定会将其视为一个选项。

我建议我首先关注我的同事 很容易重现的问题：

1)我更新了我的函数、以确保通过32位指令读取 CANES 寄存器(该值加载到影子寄存器中)。

2) 2)我让我的同事重现问题。

3) 3)我让我的同事运行我在更新函数后编写的函数。

4) 4)调用我的函数后、我们希望 CAN 控制器在总线上再次传输消息、因为我们在 CAN 控制器寄存器中看不到任何错误值。 你同意吗？

5) 5)我们还尝试调查 Rx 是否正常工作(为什么在接收消息时不再调用 CAN IRQ)。

PS：我们的测试站位于以色列、下周人们将庆祝 Pessach 假期、因此我不确定是否可以在4月30日之前为您提供更多更新。

PPS：我们还可以在 WebEx 会话中向您显示问题、对您是否合适(以防我们的想法用完)。

感谢您迄今的支持、我将随时向您提供最新信息