[参考译文] TM4C1237H6PM：电源欠压事件时的锁定

感谢您的回答。  我们尝试按照您发送的应用程序中的说明解锁器件。  我们使用的是 djgtag.exe 工具。  我们没有成功解锁微控制器。  有什么想法或其他事情我们可以尝试解锁 MC 吗？

软件团队正在努力确定软件版本中出现此问题的差异。

我有一个问题、我如何判断器件是否确实损坏、但实际上是处于深度睡眠模式还是其他锁定模式？

您好 Steven、

 dbgjtag.exe 的结果是什么？ 是否 说在屏幕上解锁成功、或者解锁有问题？ dbgjtag.exe 和 LM 闪存编程器是解锁器件的唯一工具。 如果他们无法解锁、我怀疑器件是坏的、甚至可能损坏。 您可以执行 JTAG 扫描测试吗？ 它显示了什么？ 请参阅以下使用 XDS200调试探针的示例。 它将具有与 XDS110或 XDS100相同的测试连接功能。  

另外、请在非易失性寄存器提交期间检查电源是否中断。 请参见下面的。  

还请检查您的固件的更新版本是否具有 EEPROM 操作？ EEPROM 有多个勘误表、如果中间断电、可能会导致器件无法正常工作。  

您好、Charles、

dbgjtag.exe 的浏览过程与应用程序中描述的完全相同。  没有显示成功或错误的消息。  为了进行确认、我们在相同设置下以良好的板运行了 dbgjtag.exe。  成功了。 我们知道 dbgjtag.exe、我们的设置工作正常。  我们在这里没有尝试 LM 闪存编程器的设置。

我们无法执行 JTAG 扫描测试。 我收到错误消息“Error connecting to the target：(error -1170 @ 0x0) Unable to access the DAP”(连接到目标时出错：(错误-1170 0x0)无法访问 DAP)。  

固件确实可以访问 EEPROM。  当 EEPROM 访问过程中断电导致 MC 无法正常工作时、这是否意味着与我们的情况一样、它将无法恢复–锁定或欺骗？

另一个线索。  多年来，我们一直在测试此设计，并且始终在 MC 处于各种运行模式时关闭中间的电源。  直到最近使用有源 USB 集线器时，我们才遇到同样的问题。  将集线器插入集线器时、集线器有时会循环通电和断电几次。  断电时间大约为500ms、然后打开大约为800ms。  现在，在这种锁定模式下，我们有5个以上的单元。  之前我们认为死锁与特定的 s/w 修订相关。  今天我们发现这不是真的。  我们尝试使用该软件版本(相同的 h/w)重现故障模式。  我们无法重现故障。  现在我们感到困惑。

此致、

Steven

我在这里有点困惑。 您在这里说过"具有该软件版本(相同的 h/w)"。 什么是"那个"版本？ 这是过去使用过的旧版本吗？ 我提出的原因是、您以后无法重现故障。 我认为这是对之前版本的软件的预期 如果理解不正确、请澄清。  

是的、当 EEPROM 操作由于断电而在中间中断时、器件可能无法恢复。  

也许在您的旧设置中、在 MCU 运行模式中、断电在 EEPROM 运行过程中从未发生。 使用带电 USB 集线器的新设置可能比旧设置更随机地关闭电源。  

在这里，“那个版本”，我指的是新的软件版本--导致多个 h/w 被锁定的版本。  现在、对于新的软件版本以及旧的软件版本、我们无法重现故障。  简而言之、我们无法重现故障模式。

现在、我们正在进行新的测试设置、以便重现故障模式。  我们的次要优先事项是确定真正的根本原因。  另一个优先事项是解锁 MC，因为我们没有太多的测试样本。  我们无法购买此微控制器。 该部件到处都缺货。

谢谢、

Steven

您好 Steven、

 我想您无法在运行新软件版本的不同芯片/主板上重现故障、对吧？ 但是、失败的那个仍然无法覆盖、对吧？ 我不太确定这个故障芯片发生了什么情况？ 是因为可能的故障模式(例如 EEPROM 或非易失性寄存器编程因电源中断或复位中断)或其他未知的故障模式而使其产生错误。 您能进行电流测试吗？ 如果故障芯片测量高电流、则可能存在一些短路。 您还可以对每个引脚进行电阻测试。  

没错。  我们无法在具有相同新软件版本的不同电路板上重现故障。  我们无法解锁失败的文件。  所有发生故障的电路板中的电流消耗仍处于正常范围内。 电源电压均正常。  引脚25&56上的 VDDC 正常(1.2V)。  我们可以在 PC3 (引脚49)上看到来自 MC 的大约13Hz (ICDI_TDO)的时钟信号。  我们在 OSC1/OSC0上有一个外部晶体电路、我们在该电路中测量了无时钟信号。  所有 GPIO 引脚都没有正常功能。  在 USB 集线器电源欠压测试期间、我们监控了电源电压和复位信号、但未捕获任何过压事件。

您好 Steven、

我希望我知道根本原因，但我现在不知道。 我认为您可能有两种不同的电路板设计。 一个电路板设计运行相同的软件不会失败、但另一个电路板设计将锁定。 这两种设计之间的区别是什么、尽管我很难将锁定与电路板相关。  

如果没有 OSC0/OSC1、则没有源时钟、除非您的代码正在从内部 PIOSC 运行。 或者您的代码已将器件置于某种类型的休眠模式或深度睡眠模式、在该模式下振荡器将关闭。 如果是这种情况、您的应用必须有一个唤醒机制。 如果没有时钟、则处理器调试逻辑不能与 JTAG 时钟同步。  

你好、切里斯、

感谢您的回答。  请更新、我们也使用旧版本的软件复制了失败。  现在、我们尝试在其他设计板上重现故障。  我们有几个使用相同 MC 的电路板。  我已将您的评论转发给我们的软件团队、希望他们有资源来处理此问题。 它在我们一侧具有更高的优先级。

BTW、听起来像是最新的器件版本-修订版7 -可能没有这种故障模式。  如果确实如此、我们确实需要使用修订版7部件并进行测试以证明这一点。  一旦证明，至少我们有一个解决方案--将我们的设计改为修订版7部件。  目前、我们无法在任何地方购买器件。    我们是否有可能从 TI 获得多个样片？  我认为修订版7器件 P/N 是  TM4C1237H6PMI7。

谢谢、

Steven

您好、Charles、

你 是对的。  测试条件是打开/关闭电源。  两个电路板之间存在电路差异。  我们将 开始找出   假期休息后电路差异是否是原因。

快乐的假期！

Steven

您好、Charles、

现在、我们确定它与软件相关。  我们的软件团队正在制定解决方案。  我仍在努力解决如何解锁微控制器。  我在搜索 TI 网站时发现了这一点：

该错误可能是由于子内核上的无效代码导致其自身持续复位造成的。

如果该错误源自软件、则可以通过直接访问 DAP 并尝试通过 GEL 脚本复位有问题的内核、将其锁定或擦除其闪存来恢复该错误(某些微控制器具有预加载的例程以允许这样做)。

如果 我们可以尝试上面提到 的--直接通过 GEL 脚本访问 DAP，还有什么进一步的说明？  或者我们可以尝试的任何其他方法、请提供建议。

谢谢！

Steven

您好、Steve、

 如果您有一个非常短的周期性复位事件、则调试器可能无法与目标连接。 例如、在器件从 t1的复位中释放出来并且在 t2上发生另一个复位事件后、调试器必须能够在 t2发生前连接到目标。 调试器需要一些时间来连接、如果  需要花费更长的时间来连接到 T2以外的目标、则已经发生了 T2。 这可能成为一种恶性循环。  

 您有什么调试探针？ 我知道一些性能更高的调试探针可能需要更快的连接速度。 如果您具有 J-Link 等更高性能的探针、则可以尝试重复连接到目标。 也许、多次尝试后有机会进行连接。 您还可以尝试使用现有的调试探针。 我还建议您将 nRST 引脚保持在低电平、并在尝试将调试器连接到目标的同时将其释放。 换言之、您希望在 T1之后立即开始连接。 但是、如果 T1和 T2之间的持续时间如此短、则可能不起作用、因为总连接时间可能会超过该时间。  

 至于使用 GEL 访问 DAP、我没有任何经验。 请为此打开一个新主题、以便我可以将新帖子移至我们的 CCS 专家。 我不想在同一主题中杂乱地讨论不同的主题。 谢谢  

我们尝试了很多次、并将根据您的建议尝试更多。  我们使用 XDS200探针。

我们发现，从锁定的 MC 中，ICDI_TDO 端口(引脚49)上的信号在大约77ms 内变为低电平，然后在接下来的77ms 内变为高电平--就像13Hz 时钟信号一样。  而通过良好的 MC、该信号会保持高电平。  这是什么意思？  这是否意味着在内部 MC 保持复位77ms、然后释放复位77ms？  如果是、不确定这77ms 是否太短、以至于 XDS200探针无法执行任何操作。

谢谢！

您好 Steven、

 由于这些故障器件中已经有代码、您是否有任何功能引脚也可以指示频率为77ms 的复位模式？

好主意！  我检查了多个信号引脚、但并非所有引脚。  我将在下周做第一件事。  谢谢！

第 5.2.2.1节 TM4C1237H6PM 数据表的复位源包含：

来自 TM4C1231H6PZ：tm4e1231h6zrb 不起作用状态、如果您使用的是修订版6器件、请认为这意味着由于勘误 表 MEM#04、器件变为无法正常工作：

这很有帮助。  谢谢！

我们不希望在下电上电时无法恢复此类 EEPROM 写入相关故障。  我将与我们的软件团队一起检查的另一件事是了解他们在早期代码中所做的不同之处。  使用早期代码时、故障不可重现。

BTW 对于我前面的问题，在如上所述的“设备未能通过初始化阶段”模式下，我们可以通过任何方式让设备退出此类故障模式并恢复正常使用状态？ 我们的持续项目的可用单元即将用完、这是非常紧迫的计划。

谢谢！

您好 Steven、

 感谢 Chester 挖掘相关帖子和勘误表4。 如前所述、如果 EEPROM 操作在中间因功率损耗或任何类型的复位事件而中断、即使在由于错误而复位后器件也可能无法恢复。 设备解锁是唯一一种我认为恢复的机会可能很小的方法、但您已经尝试过但未成功。  

在早期开发阶段，我们在遇到故障模式时研究了勘误表 MEM#04 --如上所述，“复位不会恢复器件”。  但当我们重新打开电源时、器件是可恢复的。 此类故障模式已被接受。  但是现在故障模式是不同的--复位和循环电源都不能恢复器件。  这意味着它是我们器件的永久损失--与 h/w 一样，无法丢失所有器件功能。  这在我们的应用中是不可接受的。  我认为勘误表应该向用户明确说明这一点。

我将与我们的软件团队就该故障模式进行交流。  我们可能必须进一步证明这是真正的故障模式。  一旦证明 、考虑到硬件更改不是我们的选择、我们似乎只有两种选择：

1 -将我们的软件更改为不写入 EEPROM。

2 -将我们的设计更改为硅7器件、并证明故障模式不可重现。

请告知是否有其他选项。  

为了验证器件版本7、我们需要 TI 的支持。  如果您有 TI 相关团队或人员的联系信息、请告知您。

谢谢！

您好 Steven、

 有关修订版7样片或与购买相关的问题、 请联系当地的 TI 销售办事处。 抱歉、我们只处理有关 e2e 的技术讨论。