esp-bist-skill

Copy the samples/standalone application as your starting point, add a mandatory bist.conf file, and follow the canonical pattern: run post-boot tests once, initialize the stack sentinel, configure the windowed watchdog, then run CPU/CSR/stack/PC tests every main-loop iteration with failures routed to fail_safe_exit().

Post-boot tests run once at startup and cover expensive or destructive checks like RAM March A/X, Flash CRC, and watchdog reset. Runtime tests are cheap and idempotent, such as CPU registers, CSR, PC, and stack-overflow check, and execute every main-loop iteration.

ESP-BIST targets RISC-V SoCs: ESP32-C3, C5, C6, and H2 have guaranteed build support, with C61, H4, and P4 documented upstream. Xtensa-based chips like ESP32, S2, and S3 are not supported because the tests rely on RISC-V CSR, PMP, and PMA registers.

The Flash CRC test compares runtime CRC32 values against reference values injected post-build by scripts/calculate_crc32.py into the .crc_section_text and .crc_section_data linker sections. If your build bypasses cmake/project.cmake's post-build hook, the stored CRCs stay zero and the test fails.

The windowed WDT detects feeds that arrive before the underflow window set by wdt_init_windowed() elapses. If your loop is faster than CONFIG_ESP_BIST_WDT_WINDOWED_UNDERFLOW_TIMEOUT_US, either raise the underflow value or add a delay before calling wdt_feed().

No. ESP32-C6 and H2 lack SOC_XT_WDT_SUPPORTED, so bist_ext_crystal_fail_test() is skipped and returns BIST_ESP_OK. Use bist_main_crystal_test() to validate the 40 MHz main crystal on those chips instead.