我有一个GPIO0
通过开关接地的 ESP32 板。这个想法是,如果我按下按钮并发出一个ESP.restart()
板将进入闪光模式。相反,ESP.restart()
只是重新启动应用程序,忽略GPIO0
状态。
是否可以强制整个引导过程,也许直接 JMP 到硬件复位向量?
我有一个GPIO0
通过开关接地的 ESP32 板。这个想法是,如果我按下按钮并发出一个ESP.restart()
板将进入闪光模式。相反,ESP.restart()
只是重新启动应用程序,忽略GPIO0
状态。
是否可以强制整个引导过程,也许直接 JMP 到硬件复位向量?
在 ESP32 上,有 3 个复位原因导致捆绑 GPIO 被采样:上电、RTC WDT 复位、掉电复位。
因此,就代码而言,请参见下文。如果引脚被捆绑,它将永远不会退出将等待串行同步的引导加载程序。
#include "soc/rtc_wdt.h"
void hardReset() {
rtc_wdt_protect_off(); //Disable RTC WDT write protection
//Set stage 0 to trigger a system reset after 1000ms
rtc_wdt_set_length_of_reset_signal(RTC_WDT_SYS_RESET_SIG, RTC_WDT_LENGTH_3_2us);
rtc_wdt_set_stage(RTC_WDT_STAGE0, RTC_WDT_STAGE_ACTION_RESET_SYSTEM);
rtc_wdt_set_time(RTC_WDT_STAGE0, 10000);
rtc_wdt_enable(); //Start the RTC WDT timer
rtc_wdt_protect_on(); //Enable RTC WDT write protection
}
更好的解决方案是不使用固件更新模式进行编程软件更新,仅将其用于引导加载程序更新。将您的代码分成两部分引导加载程序和逻辑程序部分。
要更新您的逻辑程序部分,您的引导加载程序应该处理除引导加载程序之外的剩余地址的刻录。(您的引导加载程序代码可以烧录微控制器上的任何地址,文件系统库会这样做)所以不要尝试切换到可用于整个固件更新的固件更新模式。更高级的解决方案是尽可能使用 OTA 更新功能。
通过这种方式,您可以保证您始终在现场拥有可启动设备,该设备已准备好更新任何损坏的逻辑部分。在现场刻录引导加载程序期间的任何错误都可能导致您的设备运输成本下降。