[参考译文] F28M35H52C：F28M35x 首次上电- XRS/ARS 引脚上出现意外脉冲

谢谢 Matthew。

请在您有更多信息后通知我。

此致、Michael

您好、Matthew、

您是否有机会与同事核实上述时间差异？ 请告诉我调查结果。 我们仍然没有明确的答案、这会影响我们的项目流程。 非常感谢您对这一问题的关注。

此致、Michael

Michael、

我目前的想法是、擦除的闪存在作为闪存引导的一部分执行时、将导致总线故障异常、因为这是无效指令、并且 ECC 未被编程。

是否可以放置一些小代码、甚至像我们的支持包中的一个示例一样、看看这是否会消失？  即使是故意不禁用主 WDS 的代码(我们的所有示例都将禁用/服务 WD)、以便我们可以看到以预期频率输出的代码。

只需对原始语句进行一些澄清、主 WDS 就会针对外设引导模式禁用、因为会根据实现情况出现一些不同的延迟。  但是、由于代码执行应该是已知的、这些被启用用于闪存引导模式。

最棒的

Matthew

Matthew、

感谢您的回答。 不可以、出于多种原因、目前无法将任何代码加载到电路板中。 如果配置了引导至串行接口、问题消失、因此您对启用引导至闪存的看门狗的想法可能会间接得到确认。 但是、我在 TRM 中找不到有关该行为的确认信息。 请您向我指出该文档中的相关说明吗？

令人困惑的是、WDT0和 WDT1是32位计时器、在复位后、它们被配置为在启用时运行整个长度周期、这远长于我们在上面的波形上观察到的1.124ms。 因此、要获得1.124ms 的周期、必须适当地重新配置任何 WDT。 这将需要为 WDT0或 WDT1或 MMIWDPRD 设置适当的 WDTLOAD 值以实现 NMI WDT。 现在的问题是、这种重新配置是否真正作为引导至闪存过程的一部分发生。 这是真的发生了什么？ 这也将回答我最初的第2季度问题。

请提供建议。

此致、
Michael

Michael、

我相信我在这里找到了原因。  从 F28M35 TRM：

因此、当我们跳转到已擦除的闪存时、我们会触发总线故障异常、按照上述规则、这将触发硬故障异常。

我查看了该 ISR、它设置为在调用它后经过256个周期的极短延迟后触发 WD 复位。  这将解释您在引导至已擦除闪存时看到的复位脉冲之间的非典型持续时间、因为它不是基于32位超时。

根据代码片段、我关于启用 WD 的说法不正确。  我不认为在任何引导模式下、包括闪存在内、WD 都是由引导 ROM 启用的。

void mbrom_hard_fault_isr_handler()
{
	mbrom_boot_status_to_app |= M_BOOTROM_STATUS_TO_APP_HARD_FAULT_EXCEPTION;

	/*in certain cases RAM might not be accessible, so don't use function calls
	 * instead write to peripheral directly
	 */
	EALLOW;
	HWREG(SYSCTL_RCGC0) |= SYSCTL_RCGC0_WDT0;	//enable clock to WatchDOG
	//enable watchdog
	HWREG(WATCHDOG0_BASE + WDT_O_CTL) |= WDT_CTL_INTEN;
	//load watchdog with a small value for immediate reset
	HWREG(WATCHDOG0_BASE + WDT_O_LOAD) = 0x100;
	// Enable the watchdog reset.
	HWREG(WATCHDOG0_BASE + WDT_O_CTL) |= WDT_CTL_RESEN;
	EDIS;
	while(1);
}

最棒的
Matthew

您好、Matthew、

感谢您的回答。 因此、根据 WDT0在第二次超时时时产生复位的事实、并且给定脉宽本身的512个时钟周期、我们现在的时间间隔为1024 =(2x256 + 512)个时钟周期、或者对于20MHz X1时钟、时间间隔为51.2us。 由于复位脉冲周期约为1.124ms、因此我们仍然无法使用1.0728ms 的时间间隔。

Q3：可以安全地假设剩余的1.0728ms 时间间隔表示从复位脉冲开始到硬故障 ISR 处理程序启动为止的 M-Boot 执行时间吗？

此致、
Michael

谢谢 Matthew。
现在、让我们将其作为最终答案。