[参考译文] TMS570LC4357：启用交叉触发器接口的代码、导致数据中止异常

您好、Marcio、

我正在咨询我们的一些专家、稍后将与您联系。

谢谢 Chuck。

只需添加一些更多信息。 今天、我再次遇到这个问题、并设法获得更多数据。

因此、当发生数据中止异常时、我尝试了按钮"系统复位开关"(Hercules Dev 中的 S3)。 套件板)、但它无法解决问题。 TMS570LC 仍然获得数据中止异常。

因此、我需要使用 PORRST (套件中的上电复位、S4按钮)来停止数据异常。 这一点很有意义、因为断开电源也可以解决问题。
并解释了我无法通过调试器复位解决此问题的原因。

这意味着需要进行 POR 复位、以使 TMS570LC 从导致数据中止异常的状态中删除。 对我来说仍然是神秘的、但希望此信息能为您和您的团队提供更多帮助。

只需快速复制并粘贴 Hercules Dev 即可。 与可用的2个复位相关的套件指南：

===================================================================================================
2.6 S4、上电复位开关
TMS570LC43 MCU 有两个复位：热复位(nRST)和上电复位(nPORRST)。 开关 S4是 A
将 TMS570LC4357器件的上电复位置为有效的瞬时开关。 nPORRST 条件为
用于复位器件上的所有逻辑、包括测试和仿真电路。

2.7 S3，系统复位开关
开关 S3用于将 TMS570LC4357器件的热复位置为有效。 热复位不会复位任何测试
或仿真逻辑。 来自窗口看门狗的复位信号也将向 MCU 发出热复位。 。
热复位可通过按下 nRST 按钮、或者通过来自 XDS100 CPLD、ARM 的复位信号来调用
JTAG SREST。
===================================================================================================

此致、
Marcio

您好、Marcio、

我很抱歉、由于我对您正在使用的 ECT IP 做了一些研究、因此迟迟未能与您联系。 请注意、ARM 网站(ARM 信息中心)上的 CoreSight 组件 TRM 中有更多有关此 IP 的信息。

对于我的一般信息、您能否提供指向您的代码来源的帖子的链接、以便我更深入地了解它？ 根据初始外观、对寄存器的带密钥写入的使用似乎与 CoreSight 组件 TRM 不一致。

你好、Chuck、  

上周我还在、这就是为什么我花了一段时间来回答问题的原因。

下面是我之前提到的脚本的帖子链接：

https://e2e.ti.com/support/microcontrollers/hercules/f/312/p/517887/1882641#1882641

它是一个.gel 脚本。 由于我不使用 Code Composer Studio (CCS)、所以我只使用代码在 TMS 初始化期间启用了 CTI。

此致、

Marcio

您好、Marcio、

我就这一问题与我们的 R5专家进行了交谈(很抱歉他因为一段时间不在办公室而延误了)。 他提到、您需要在 Halcogen 中将 CTI 帧添加到 MPU 配置中(需要新的块定义)、以确保不会因非法访问而触发中止。

Marcio、

MPU 配置由软件完成。 我的理解是、MPU 默认在 Halcogen 内配置、而 init 作为启动代码的一部分被调用。 CTI 的地址范围不一定包含在该默认配置中、需要添加。

你好、Chuck、

是的、MPU 由软件配置、但复位时、通常所有内部模块都设置回其复位条件(即确定性状态)。 因此、即使在执行任何指令之前、根据我的理解、所有模块都应采用已知的书面配置。


在 TI 论坛上进行快速研究、我发现、例如 Jean-Marc 的这篇文章：
e2e.ti.com/.../304680

摘录：
"对这些位的任何写操作都将导致软件复位。
CPU 将跳回到复位矢量、并且所有内部模块将返回到它们的复位条件。"

另外一篇由蔡国斌所作的文章：
e2e.ti.com/.../1974415

摘录：
"系统复位是一种热复位、几乎可以重置除少数模拟组件之外的整个器件。"


那么、我的问题是：MPU 模块的复位状态是什么？
为什么在热复位之后、MPU 有时会导致异常、而在热复位之后、当 CPU 访问同一地址时、MPU 不会导致异常。

此致、
Marcio

您好、Marcio、

抱歉、我对您的问题感到困惑。 为了确保 MPU 被 nRST/WARM 复位来复位至其缺省状态。 默认情况下、应在任何代码配置和启用前禁用它。

如果您接收到此数据访问的间歇中止、我目前没有很好的解释。 您能否提供有关发生中止的重置的调试连接状态的更多详细信息？

我的理论与器件中的调试信号传播以及执行热复位时有关、 调试连接不会丢失/复位、但当您执行硬复位(POR)时、这意味着在不存在调试信号的情况下启用 CTI、而不是在出现调试信号的情况下启用 CTI。

你好、Chuck、

调试通过 JTAG 连接完成。 调试连接永远不会丢失。 在调试器中、我在执行热复位或 POR 时看不到任何差异。

但是、问题似乎与 CTI 本身的激活无关。 它似乎与对地址 0xaa07fb0的写入相关、 因为此时发生异常。 (即在执行任何命令以实际启用 CTI 之前)

我甚至不能确定这个问题是由 MPU 引起的、因为我有 一个同步外部中止、MPU 只能生成3种类型的故障：后台、权限和对齐。

因此、即使启用了 MPU、如果地址0xaa07fb0的存储器区域未映射到 MPU 区域、我也会遇到后台故障。 情况并非如此。

在写入存储器地址时、会导致同步外部中止的原因是什么？ 不会通过热复位清除的东西。 但会通过 POR 清除。

谢谢、

Marcio

您好、Marcio、

一般来说、同步中止不会在热复位时清除、以便在出现瞬态错误时在新的复位后进行处理。 要清除该中断、您需要通过读取 FSR 并通过读取同步中止标志和捕获的错误地址来处理同步中止。

读取捕获到的错误地址后、您可以更深入地了解发生错误的原因。 即未实现的内存、不可纠正的错误/总线错误等 如果捕获的错误地址与0xaa07fb0的对应、则它位于 CTI1帧中。 我没有在 ARM 文档中查看 CTI 寄存器定义、但这可能是一个未实现的地址位置、因此、访问时会导致中止。

总之、您看到的与正在清除的中止相关的热复位与 POR 复位行为是预期的。 有一点令人困惑的是、为什么由于对同一寄存器地址的访问、在 POR 之后不会获得任何新的中止。 我在上一篇文章中的理论可能会解释这一点、即当您执行 POR 时、器件将与调试器断开连接、而当发生热复位时、您不会这样做。 测试这种情况的一种方法是执行 POR、连接到器件(或通过在调试器中执行暂停等操作来重新建立连接)、重新连接后、执行另一个软/热复位、并查看中止现在是否显示在连接的调试器上。

请注意、即使调试器物理连接到电路板、POR 也会在上电复位期间与仿真器短暂断开。 在 CCS 中(我知道您不使用该工具)、器件已完成复位的消息会注意到这一点。

你好、Chuck、

同步中止在热复位时不被清除是很有意义的。

上次遇到此问题时、我查看了错误地址、它对应于对确切地址0xa07fb0 (CTI 1)的写入。 它可能看起来是一个未实现的地址。 但是、在 POR 之后、写入该地址有效(即不生成中止)、我看到启用 CTI 的效果(即、RTI 计数器在 CPU 暂停时冻结。 为了确保我禁用了 CTI、计数器不会冻结。 所以我是积极的 CTI、确实起作用)。

因此、根据您的理论、实际清除并正确启用 CTI (以防发生中止异常)的唯一方法是从调试器上断开器件。 这无法通过物理断开调试器或 POR 来实现(也只能通过物理按下 DEV 上的 POR 按钮来实现。 电路板)。

OBS：只是为了突出一点。 对地址0xaa07fb0的写入访问并不是为了实际启用 CTI。 它只是为了解锁对 CTI 的写入(因此可以通过写入其他地址来启用它)。 因此、CTI 可能与此问题无关。
我相信、如果 TMS570在解锁对 CTI 地址的写入时遇到问题、它不会提供与该地址中的写入相关的数据中止异常。 实际上、如果 TMS570在解锁对 CTI 的写入时遇到问题、则意味着写入地址0xaa07fb0确实成功。

无论如何、这一点都是相关的、因为如果我们运行一批测试、最终可能会出现一个无法通过软件清除的异常、因此需要有人手动复位器件。
我从未见过这样的情况、特别是考虑到我们在开发的这个阶段没有运行任何超复杂的东西。

有关如何避免必须亲自前往开发的任何权变措施。 并按下 POR 按钮？

谢谢、
此致、
Marcio

很抱歉、只是为了澄清我最后一条消息中的一点。 我们确实可以通过软件重置此数据中止异常。

正如您提到的、我可以创建一个代码来清除此错误标志并再次复位 CPU。

但是、即使我通过软件清除此数据中止异常标志并执行热复位、数据中止异常也可能会再次发生、没错。 因为清除该标志实际上并不能解决中止的根本原因。 显然、"解决"中止的根本原因的唯一方法是实际进入电路板。

您好、Marcio、

正确的做法是、SW 可以通过清除标志并读取 FSR 数据来禁用中止。 我认为第二部分也需要从导致中止的 FSR 中读取地址。

至於再次出现的问题，我不能肯定是否真的是这样。 可能值得与 ARM 直接讨论、因为正是他们的 IP 导致了此问题。 另一种可能是写入写入使能寄存器后需要延时？ 也许这就是为什么您看到的问题存在一些不稳定性？ 最后一个位有点远、因此它可能不会产生任何影响、只是建议在写入 CTI 寄存器后放置一些 NOP、还请检查您进行此写入时处于哪种模式。 即监控器模式、特权模式、用户模式等、以确保您处于该寄存器的正确访问模式。

Marcio、

我100%同意、将我们发现的问题/难题保留在论坛中是非常重要的。 它为遇到相同问题的任何人提供了方便的参考、也为我们提供了数据存储库、可用于在性能、执行或简单文档方面进行改进。 它确实有益于 TI 和我们的客户。 感谢您在此讨论您的问题。

你好、Chuck、

请注意、调试器复位不能清除 CTI 错误的事实是、在 TI TMS570LC HDK 上、SRST JTAG 信号路由到 TMS570LC4357的 nRST (热复位)引脚。 CPU 的冷复位引脚(POR_RESET)仅在实际断电或 POR_RESET 按钮激活时激活。 为什么 HDK 将 JTAG SRST 连接到热复位功能、而不是冷复位功能？ 我的效果是无法远程执行冷复位：我们需要通过物理方式连接到电路板才能执行冷复位。

谢谢。

有什么答案？

您好、Etienne、

[引述 USER="ETIENE ALEFINS"]为什么 HDK 会将 JTAG SRST 连接到热复位功能、而不是冷复位功能？ 我的效果是无法远程执行冷复位：我们需要通过物理方式连接到电路板才能执行冷复位。
 [/报价]

是建议和预期的连接。 通常情况下、EVM 放在您旁边的工作台上、而不是放在远程位置。 当然、如果您希望每次在调试器中选择系统复位时都进行上电复位、则可以对电路板进行小幅修改以启用此配置。

您好！

谢谢。 您还建议在我们的最终产品中将 JTAG 复位连接到 CPU 的冷复位吗？ 热复位特性将不会被连接。

您好、Etienne、

我不能提出这样的建议。 您需要确定应用的具体需求。 通常、JTAG 在应用运行期间应受到保护、并且在安全手册中有描述如何执行此操作的安全机制。

热复位是我们安全实施中的一项关键功能。 它允许重新启动应用程序、而不会丢失有关错误条件导致复位的原因的历史参考。 因此、在重新启动/热复位时、您将检查 ESR 以确定复位源、然后在复位为热复位时检查是否存在捕获的错误条件。 在我们连接到 TPS65381 PMIC 的一些示例应用中、nRST 连接到 TPS 的复位、在该复位中、TPS 可以在超过 nERROR 计数或看门狗故障时将复位置为有效。 nRST 也是一个双向引脚、外部器件可在该引脚上检查器件的状态、以查看它是通过复位还是保持在复位状态。 简而言之、nRST 引脚/热复位特性的许多用途都应根据您的系统需求加以考虑。