Sam Price commented: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1555#note_161772 For reviewers, here is where the same sequence appears elsewhere. Links are pinned to the current upstream commits. **ESP32-C3 Technical Reference Manual v1.4** ([PDF](https://documentation.espressif.com/esp32-c3_technical_reference_manual_en.pdf)), Chapter 12, Watchdog Timers: - §12.1, p. 305: RWDT and timer group 0's MWDT are enabled automatically during flash boot. - §12.2.2.3, Write Protection, pp. 308–309: each watchdog has its own key field (`TIMG_WDT_WKEY`, `RTC_CNTL_WDT_WKEY`). Writes are ignored until 0x50D83AA1 is written there, and the procedure ends by writing any other value to lock it again. - §12.2.2.4, Flash Boot Protection, p. 309: "After booting, TIMG_WDT_FLASHBOOT_MOD_EN and RTC_CNTL_WDT_FLASHBOOT_MOD_EN should be cleared to stop the flash boot protection procedure." - §12.3, Super Watchdog, pp. 309–310: the 0x8F1D312A key and `RTC_CNTL_SWD_AUTO_FEED_EN`. - Register 11.10, `TIMG_WDTCONFIG0_REG`, p. 298: `TIMG_WDT_CONF_UPDATE_EN`, "Updates the WDT configuration registers." **ESP-IDF**, what its second-stage bootloader does before an application runs. This is why ESP-IDF applications never hit the bug and a direct-boot image like this BSP does: - [`bootloader_config_wdt()`](https://github.com/espressif/esp-idf/blob/0e6b480f858c69862ffb6001d96e9eef74599a6e/components/bootloader_support/src/bootloader_init.c#L76-L112): unlock, clear flash-boot mode, lock, for the RWDT and then MWDT0. - [`bootloader_super_wdt_auto_feed()`](https://github.com/espressif/esp-idf/blob/0e6b480f858c69862ffb6001d96e9eef74599a6e/components/bootloader_support/src/esp32c3/bootloader_esp32c3.c#L74-L79): unlock, set auto-feed, lock. Both functions are called from the [C3 hardware init](https://github.com/espressif/esp-idf/blob/0e6b480f858c69862ffb6001d96e9eef74599a6e/components/bootloader_support/src/esp32c3/bootloader_esp32c3.c#L130) and [later in the same file](https://github.com/espressif/esp-idf/blob/0e6b480f858c69862ffb6001d96e9eef74599a6e/components/bootloader_support/src/esp32c3/bootloader_esp32c3.c#L186). - [`mwdt_ll_set_flashboot_en()`](https://github.com/espressif/esp-idf/blob/0e6b480f858c69862ffb6001d96e9eef74599a6e/components/esp_hal_wdt/esp32c3/include/hal/mwdt_ll.h#L183-L195): clears `wdt_flashboot_mod_en` and then sets `wdt_conf_update_en`, because "Config registers are updated asynchronously". **NuttX**, [`esp_start.c`](https://github.com/apache/nuttx/blob/5eca74f254c8d32847179f6ebbd5a6e4b588bec0/arch/risc-v/src/common/espressif/esp_start.c): in simple-boot mode (no second-stage bootloader, as here) it [calls ESP-IDF's `bootloader_init()`](https://github.com/apache/nuttx/blob/5eca74f254c8d32847179f6ebbd5a6e4b588bec0/arch/risc-v/src/common/espressif/esp_start.c#L517-L523), which runs the functions above. Before `nx_start()` it also [clears the RWDT's flash-boot mode and disables it, under the key](https://github.com/apache/nuttx/blob/5eca74f254c8d32847179f6ebbd5a6e4b588bec0/arch/risc-v/src/common/espressif/esp_start.c#L666-L676). **Zephyr**, [`soc/espressif/esp32c3/hw_init.c`](https://github.com/zephyrproject-rtos/zephyr/blob/d1b8eec76bfd14058854245d09aa1e413e355c4a/soc/espressif/esp32c3/hw_init.c): its no-bootloader path calls [`super_wdt_auto_feed()`](https://github.com/zephyrproject-rtos/zephyr/blob/d1b8eec76bfd14058854245d09aa1e413e355c4a/soc/espressif/esp32c3/hw_init.c#L36) and [`config_wdt()`](https://github.com/zephyrproject-rtos/zephyr/blob/d1b8eec76bfd14058854245d09aa1e413e355c4a/soc/espressif/esp32c3/hw_init.c#L91). The implementations live in Espressif's HAL module for Zephyr. The second commit, ffb50e00c9, brings this MR in line with those implementations. It locks each watchdog again after changing it, and it sets `TIMG_WDT_CONF_UPDATE_EN` after writing `TIMG_WDTCONFIG0`. It builds with no warnings but hasn't been run on hardware yet; I'll report back when it has. The first commit is the one that was tested on hardware. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1555#note_161772 You're receiving this email because of your account on gitlab.rtems.org. Unsubscribe from this thread: https://gitlab.rtems.org/-/namespace/49/sent_notifications/6-dfms6yjqcpvecsdsu7e2tuazn-1d/unsubscribe | Manage all notifications: https://gitlab.rtems.org/-/profile/notifications | Help: https://gitlab.rtems.org/help
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
