[参考译文] TMS570LC4357：nERROR 引脚复位行为

您好、Gael、

很抱歉、这一个问题出现了裂缝。 我们将需要在此帖子下继续讨论、因为我无法解锁其他线程、因为它们被系统锁定。

为了便于访问和访问上下文、我将在此处复制原始帖子内容：

"您好、

我们观察到 ESM nERROR 引脚在热复位时的未检测行为。

附加的图上显示了初始条件。

在目标上执行的代码会生成一个 NMPU - DMA 端口 A MPU 错误 EMS1.69、具体方法是生成一个不正确的 DMA 请求。 ESM1.69按预期触发、 nERROR 引脚和低级中断处理程序根据 ESMIEPCR7和 ESMILSR7寄存器配置相应地被激活。 我们会给处理程序留出一些时间来记录一些工程数据并清除 ESMSR7寄存器。

从该状态开始、如所附图所述：  

e2e.ti.com/.../5141.nERROR.pdf

(a)一旦 RTCR 达到零、请求 nERROR 引脚复位的操作将立即成功。

但在热复位之后(b)

(C)请求 nERROR 引脚复位无效

(D)成功强制 nERROR (虽然我们预计会拒绝请求、因为 nERROR 引脚已处于活动状态、如 TRM§16.2.3-1所述'如果在功能模式中已经检测到故障、则 ESM 模块无法切换到错误强制模式。 切换到错误强制模式的应用程序命令将被忽略'

(e)从这种接受的强制模式中、请求切换回正常模式实际上会清除 nERROR 引脚、尽管没有发送实际复位请求；因此原始错误上下文会丢失。

(f)从接受的强制模式中、请求 nERROR 引脚复位被接受、但在 ESMEKR 中状态保持在复位请求模式、而根据 TRM§16.2 "(一旦 ERROR 引脚输出低电平、 需要一个上电复位或者向 ESMEKR 写入0x5来将 ESM ERROR 引脚释放回正常状态)"、并且只有当 CPU 通过在 ESMEKR 中写入0x0来实际请求时、才会进入正常模式。

您能不能帮助理解为什么(c)不足以在热复位后复位 nERROR 引脚？

请您澄清一下过渡时期(d)、(e)和(f) TRM 中的差异与我们的理解。

问题是完全确定的。"

为了更深入地探讨这一点、我需要在工作台上的测试案例中重新创建场景。 如果您已经有了一个简单的项目来演示您可以提供的上述行为、它可以帮助您更快地获得解释。

你好、Chuck、

谢谢你。 遗憾的是、我无法为您提供示例项目、因为我的实验仅通过调试器(WinIdea)直接修改寄存器来执行。 我注意到弗朗克·瓦特尔在其最初的文章中所记录的行为完全相同。

我跳过你可以给它带来光！

此致、

盖尔

你好、Chuck、
有关此主题的任何新闻？
谢谢、
盖尔

你好，盖尔
这是一个旧的帖子-我看到我们无法就此提供进一步的指导。 此问题是否仍然存在？
此致
Mukul

您好！

是的、这是一篇老文章、是的、这对我来说仍然是一个问题。 我需要您确认问题并在下一版 TRM 中更新文档。

谢谢你

盖尔

您好、Gael、

当 nERROR 发生时、器件在 nERROR 被清除前被系统复位、复位后向 ESMEKR 写入0x5将不能清除 nERROR。

如果发生系统复位、ESM 状态机也会复位。 它失去了刚才发生错误事件的事实。 因此、如果您现在尝试通过写入0x5来重置 nERROR 引脚、它将不起作用。 清除 nERROR 引脚的方法是通过上电复位或通过将0xA 写入 ESMEKR 寄存器、后跟任何非0xA 值来复位 nERROR 引脚、从而将 nERROR 引脚置于诊断模式。

我们已将其添加到最新的勘误表中。

您好 QJ、

感谢您提供信息。 我认为此勘误表可以解释原始帖子中标识为"c"的问题。
您是否调查过原始帖子中描述的其他问题？
谢谢
盖尔