This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
您好!
我正在使用我们定制设计的应用硬件上安装的 F28M35H52C Concerto 器件。 这是一种新设计、我们在没有任何代码加载到器件的情况下执行了首次加电测试、因此 Concerto 器件处于其初始的现成状态。 在施加所有电源电压且没有过载迹象的情况下、我开始检查 XRS/ARS 复位引脚上的复位信号。 这些引脚按照器件文档的建议连接在一起。 我发现这些引脚上的意外脉冲仅在器件尝试引导至闪存时出现。 如果引导模式更改为串行接口、这些脉冲将消失并且 nXRS = 1、这是预期的。
我认为这些复位脉冲由其中一个看门狗计时器触发。 在检查 TRM 后、我发现 WDT1和 WDT0计时器默认处于禁用状态、因此我认为复位是由 NMI WDT 触发的。 但这里是我产生困惑的地方。
我们应用中的 X1时钟为20MHz、因此时钟周期为50ns。 根据上面提供的 nXRS 波形、复位脉冲周期为1.124ms。 但是、鉴于 NMI WDT 是16位计数器、我预计周期为50ns * 2^16 = 3.2768ms、这大约是观测周期的3倍。 我不确定是需要1个还是2个 NMI WDT 周期来触发系统复位、但观察到的周期只是单个周期的几分之一。
我的问题如下。
Q1:观察到的 nXRS 脉冲是否正确由 NMI WDT 计时器引起? 如果不是、可能的来源是什么?
Q2:如果这些脉冲确实是由 NMI 看门狗引起的、那么为什么预期周期值和观测周期值之间存在差异?
谢谢、
Michael
Michael、
我同意这似乎是 NMI WD 计时器、但正如您提到的、基于 X1上的20MHz 时钟、低脉冲之间的时间太短。
但是、NMI WD 在 XRSn 上的低电平有效时间为512 osc 时钟~ 26us、这似乎与示波器图一致。
我需要与一些同事联系、了解我们为什么是3倍的比率、并为您提供一个可靠的答案、尽管我们都相当肯定这是 WD 机制。
最棒的
Matthew
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
Michael、
是的、这也是我的结论。 请记住、由于 PLL 尚未启用、我们将以20MHz 时钟执行、这说明了更长的持续时间。
我将提出我之前的评论、XRSn 脉冲的保持低电平时间也对应于512个 OSC 时钟周期的 DS。 那么、这肯定是将复位置为有效的 WD。
最棒的
Matthew
谢谢 Matthew。
现在、让我们将其作为最终答案。