SysCtlResetCauseGet 返回1。 我需要找到导致此复位的原因。
探测硬件看门狗 GPIO 和 MCU 复位引脚不会在示波器上生成触发信号
电压。 我将再次重新运行此程序以进行确认。
我在 NVIC_APINT 寄存器中设置了一个硬件观察点。 执行也没有在这里停止
这是我第一次运行它。 不确定要执行其他什么操作来跟踪此复位的原因? 什么工具
我要使用什么?
谢谢、
Priya
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.
SysCtlResetCauseGet 返回1。 我需要找到导致此复位的原因。
探测硬件看门狗 GPIO 和 MCU 复位引脚不会在示波器上生成触发信号
电压。 我将再次重新运行此程序以进行确认。
我在 NVIC_APINT 寄存器中设置了一个硬件观察点。 执行也没有在这里停止
这是我第一次运行它。 不确定要执行其他什么操作来跟踪此复位的原因? 什么工具
我要使用什么?
谢谢、
Priya
您好!
如果您读取1、则为外部复位。 请参阅下面的内容。 您希望使用示波器来捕获 nRST 输入。
如果您有意外的外部复位、请查看您的电路板是否遵循以下建议。 示例 如果 nRST 引脚上有合适的上拉电阻器、 同时检查 VDD 上是否有稳定的电源。 如果 VDD 超出范围、则稳压器可能会跳闸。 有关详细信息、您还可以参阅 TM4C129系统设计指南应用手册。 http://www.ti.com/lit/an/spma056/spma056.pdf
感谢您提供数据表中的信息。
但是、driverlib API 显示如下:
26.2.2.47 SysCtlResetCauseGet
获取重置的原因。 原型:uint32_t SysCtlResetCauseGet (void)
说明:此函数返回复位的原因。 由于复位原因在软件清零或上电复位前是粘着的、因此如果发生了多次复位、可能会返回多个复位原因。 复位原因是 SYSCTL_CAUSE_HSRVREQ、SYSCTL_CAUSE_HIB、SYSCTL_CAUSE_WDOG1、SYSCTL_CAUSE_SW、SYSCTL_CAUSE_WDOG0的逻辑 OR、 SYSCTL_CAUSE_BOR、SYSCTL_CAUSE_POR 和/或 SYSCTL_CAUSE_EXT。
返回:返回重置的原因。
这似乎表明复位可能有多种原因。 这是真的吗?
您好、Charles、
我的团队发现您的初始回答非常完美。 (EXT 生成了复位。)
海报的问题可能围绕着(严格)对语言的解释:"可以同时设置多个标志?" 我所在集团的信念是:"读取 RESC 寄存器时、可能会出现多个标志"。" 这并不意味着,“所有这种旗帜都是同时“设置”的! 相反-它们很可能是单独/按顺序设置的。
请注意、这些标志被描述为"粘着"(即、在被清除前将一直保持。) 一旦记录到寄存器位、通过定期的 RESC 测试-和清除-可消除(肯定会减少)与"哪个标志导致复位"相关的混淆。 (该"测试"可以在每次 MCU 复位后自动执行、从而简化过程。 它(仅在允许累积"多个复位"时)(在 RESC 中)-可能会引起对"上次复位源"的混淆...)
[引用用户="Charles Tsaaaa">但是、在我使用的另一个 MCU 器件中、确实可以在同一周期中设置多个复位标志。 [/报价]
实际上、Charles -由于我的小型技术公司(主要是)雇用(现在)五家供应商的 ARM Cortex MCU -我们也是"防范"可疑行为"、这迫使我们"高度关注和准备"。
作为一般性陈述和/或观察-我们不会发现"太频繁"-同时发生(近)多种复位原因。 (除非发生了具有重大意义的事件-然后需要充分注意...)