"help":"Adds --warn-undefined-variables to MAKEFLAGS. This causes make to\nprint a warning any time an undefined variable is referenced.\n\nThis option helps find places where a variable reference is misspelled\nor otherwise missing, but it can be unwanted if you have Makefiles which\ndepend on undefined variables expanding to an empty string.\n\n(Note: this option is used with the legacy GNU Make build system only.)",
"help":"Enable this option in case you have a custom toolchain which supports time_t wide 64-bits.\nThis option checks time_t is 64-bits and disables ROM time functions\nto use the time functions from the toolchain instead.\nThis option allows resolving the Y2K38 problem.\nSee \"Setup Linux Toolchain from Scratch\" to build\na custom toolchain which supports 64-bits time_t.\n\nNote: ESP-IDF does not currently come with any pre-compiled toolchain\nthat supports 64-bit wide time_t.\nThis will change in a future major release,\nbut currently 64-bit time_t requires a custom built toolchain.",
"help":"Select the way the application is built.\n\nBy default, the application is built as a binary file in a format compatible with\nthe ESP32 bootloader. In addition to this application, 2nd stage bootloader is\nalso built. Application and bootloader binaries can be written into flash and\nloaded/executed from there.\n\nAnother option, useful for only very small and limited applications, is to only link\nthe .elf file of the application, such that it can be loaded directly into RAM over\nJTAG. Note that since IRAM and DRAM sizes are very limited, it is not possible to\nbuild any complex application this way. However for kinds of testing and debugging,\nthis option may provide faster iterations, since the application does not need to be\nwritten into flash.\nNote that at the moment, ESP-IDF does not contain all the startup code required to\ninitialize the CPUs and ROM memory (data/bss). Therefore it is necessary to execute\na bit of ROM code prior to executing the application. A gdbinit file may look as follows:\n\n # Connect to a running instance of OpenOCD\n target remote :3333\n # Reset and halt the target\n mon reset halt\n # Run to a specific point in ROM code,\n # where most of initialization is complete.\n thb *0x40007901\n c\n # Load the application into RAM\n load\n # Run till app_main\n tb app_main\n c\n\nExecute this gdbinit file as follows:\n\n xtensa-esp32-elf-gdb build/app-name.elf -x gdbinit\n\nRecommended sdkconfig.defaults for building loadable ELF files is as follows.\nCONFIG_APP_BUILD_TYPE_ELF_RAM is required, other options help reduce application\nmemory footprint.\n\n CONFIG_APP_BUILD_TYPE_ELF_RAM=y\n CONFIG_VFS_SUPPORT_TERMIOS=\n CONFIG_NEWLIB_NANO_FORMAT=y\n CONFIG_ESP_SYSTEM_PANIC_PRINT_HALT=y\n CONFIG_ESP32_DEBUG_STUBS_ENABLE=\n CONFIG_ESP_ERR_TO_NAME_LOOKUP=",
"help":"This option sets compiler optimization level (gcc -O argument)\nfor the bootloader.\n\n- The default \"Size\" setting will add the -0s flag to CFLAGS.\n- The \"Debug\" setting will add the -Og flag to CFLAGS.\n- The \"Performance\" setting will add the -O2 flag to CFLAGS.\n- The \"None\" setting will add the -O0 flag to CFLAGS.\n\nNote that custom optimization levels may be unsupported.",
"help":"This value is ignored unless flash mode is set to QIO or QOUT *and* the SPI flash pins have been\noverriden by setting the eFuses SPI_PAD_CONFIG_xxx.\n\nWhen this is the case, the eFuse config only defines 3 of the 4 Quad I/O data pins. The WP pin (aka ESP32\npin \"SD_DATA_3\" or SPI flash pin \"IO2\") is not specified in eFuse. That pin number is compiled into the\nbootloader instead.\n\nThe default value (GPIO 7) is correct for WP pin on ESP32-D2WD integrated flash.",
"id":"BOOTLOADER_SPI_WP_PIN",
"name":"BOOTLOADER_SPI_WP_PIN",
"range":null,
"title":"SPI Flash WP Pin when customising pins via eFuse (read help)",
"help":"If this option is enabled, and VDDSDIO LDO is set to 1.8V (using eFuse\nor MTDI bootstrapping pin), bootloader will change LDO settings to\noutput 1.9V instead. This helps prevent flash chip from browning out\nduring flash programming operations.\n\nThis option has no effect if VDDSDIO is set to 3.3V, or if the internal\nVDDSDIO regulator is disabled via eFuse.",
"help":"The selected GPIO will be configured as an input with internal pull-up enabled.\nTo trigger a factory reset, this GPIO must be pulled low on reset.\nNote that GPIO34-39 do not have an internal pullup and an external one must be provided.",
"id":"BOOTLOADER_NUM_PIN_FACTORY_RESET",
"name":"BOOTLOADER_NUM_PIN_FACTORY_RESET",
"range":null,
"title":"Number of the GPIO input for factory reset",
"help":"The device will boot from \"factory\" partition (or OTA slot 0 if no factory partition is present) after a\nfactory reset.",
"id":"BOOTLOADER_OTA_DATA_ERASE",
"name":"BOOTLOADER_OTA_DATA_ERASE",
"range":null,
"title":"Clear OTA data on factory reset (select factory partition)",
"type":"bool"
},
{
"children":[],
"depends_on":"BOOTLOADER_FACTORY_RESET",
"help":"Allows customers to select which data partitions will be erased while factory reset.\n\nSpecify the names of partitions as a comma-delimited with optional spaces for readability. (Like this:\n\"nvs, phy_init, ...\")\nMake sure that the name specified in the partition table and here are the same.\nPartitions of type \"app\" cannot be specified here.",
"id":"BOOTLOADER_DATA_FACTORY_RESET",
"name":"BOOTLOADER_DATA_FACTORY_RESET",
"range":null,
"title":"Comma-separated names of partitions to clear on factory reset",
"help":"Allows to reset the device to factory settings:\n- clear one or more data partitions;\n- boot from \"factory\" partition.\nThe factory reset will occur if there is a GPIO input pulled low while device starts up.\nSee settings below.",
"help":"The selected GPIO will be configured as an input with internal pull-up enabled.\nTo trigger a test app, this GPIO must be pulled low on reset.\nAfter the GPIO input is deactivated and the device reboots, the old application will boot.\n(factory or OTA[x]).\nNote that GPIO34-39 do not have an internal pullup and an external one must be provided.",
"id":"BOOTLOADER_NUM_PIN_APP_TEST",
"name":"BOOTLOADER_NUM_PIN_APP_TEST",
"range":null,
"title":"Number of the GPIO input to boot TEST partition",
"help":"Allows to run the test app from \"TEST\" partition.\nA boot from \"test\" partition will occur if there is a GPIO input pulled low while device starts up.\nSee settings below.",
"id":"BOOTLOADER_APP_TEST",
"name":"BOOTLOADER_APP_TEST",
"range":null,
"title":"GPIO triggers boot from test app partition",
"help":"The GPIO must be held low continuously for this period of time after reset\nbefore a factory reset or test partition boot (as applicable) is performed.",
"id":"BOOTLOADER_HOLD_TIME_GPIO",
"name":"BOOTLOADER_HOLD_TIME_GPIO",
"range":null,
"title":"Hold time of GPIO for reset/test mode (seconds)",
"help":"If it is set, the client must itself reset or disable rtc_wdt in their code (app_main()).\nOtherwise rtc_wdt will be disabled before calling app_main function.\nUse function rtc_wdt_feed() for resetting counter of rtc_wdt.\nUse function rtc_wdt_disable() for disabling rtc_wdt.",
"id":"BOOTLOADER_WDT_DISABLE_IN_USER_CODE",
"name":"BOOTLOADER_WDT_DISABLE_IN_USER_CODE",
"range":null,
"title":"Allows RTC watchdog disable in user code",
"type":"bool"
},
{
"children":[],
"depends_on":"BOOTLOADER_WDT_ENABLE",
"help":"Verify that this parameter is correct and more then the execution time.\nPay attention to options such as reset to factory, trigger test partition and encryption on boot\n- these options can increase the execution time.\nNote: RTC_WDT will reset while encryption operations will be performed.",
"help":"Tracks the execution time of startup code.\nIf the execution time is exceeded, the RTC_WDT will restart system.\nIt is also useful to prevent a lock up in start code caused by an unstable power source.\nNOTE: Tracks the execution time starts from the bootloader code - re-set timeout, while selecting the\nsource for slow_clk - and ends calling app_main.\nRe-set timeout is needed due to WDT uses a SLOW_CLK clock source. After changing a frequency slow_clk a\ntime of WDT needs to re-set for new frequency.\nslow_clk depends on ESP32_RTC_CLK_SRC (INTERNAL_RC or EXTERNAL_CRYSTAL).",
"help":"The secure version is the sequence number stored in the header of each firmware.\nThe security version is set in the bootloader, version is recorded in the eFuse field\nas the number of set ones. The allocated number of bits in the efuse field\nfor storing the security version is limited (see BOOTLOADER_APP_SEC_VER_SIZE_EFUSE_FIELD option).\n\nBootloader: When bootloader selects an app to boot, an app is selected that has\na security version greater or equal that recorded in eFuse field.\nThe app is booted with a higher (or equal) secure version.\n\nThe security version is worth increasing if in previous versions there is\na significant vulnerability and their use is not acceptable.\n\nYour partition table should has a scheme with ota_0 + ota_1 (without factory).",
"help":"The size of the efuse secure version field.\nIts length is limited to 32 bits for ESP32 and 16 bits for ESP32-S2.\nThis determines how many times the security version can be increased.",
"help":"This option allow emulate read/write operations with efuse secure version.\nIt allow to test anti-rollback implemention without permanent write eFuse bits.\nIn partition table should be exist this partition `emul_efuse, data, 5, , 0x2000`.",
"id":"BOOTLOADER_EFUSE_SECURE_VERSION_EMULATE",
"name":"BOOTLOADER_EFUSE_SECURE_VERSION_EMULATE",
"range":null,
"title":"Emulate operations with efuse secure version(only test)",
"help":"After updating the app, the bootloader runs a new app with the \"ESP_OTA_IMG_PENDING_VERIFY\" state set.\nThis state prevents the re-run of this app. After the first boot of the new app in the user code, the\nfunction should be called to confirm the operability of the app or vice versa about its non-operability.\nIf the app is working, then it is marked as valid. Otherwise, it is marked as not valid and rolls back to\nthe previous working app. A reboot is performed, and the app is booted before the software update.\nNote: If during the first boot a new app the power goes out or the WDT works, then roll back will happen.\nRollback is possible only between the apps with the same security versions.",
"help":"This option disables the normal validation of an image coming out of\ndeep sleep (checksums, SHA256, and signature). This is a trade-off\nbetween wakeup performance from deep sleep, and image integrity checks.\n\nOnly enable this if you know what you are doing. It should not be used\nin conjunction with using deep_sleep() entry and changing the active OTA\npartition as this would skip the validation upon first load of the new\nOTA partition.",
"id":"BOOTLOADER_SKIP_VALIDATE_IN_DEEP_SLEEP",
"name":"BOOTLOADER_SKIP_VALIDATE_IN_DEEP_SLEEP",
"range":null,
"title":"Skip image validation when exiting deep sleep",
"help":"Reserve RTC FAST memory for Skip image validation. This option in bytes.\nThis option reserves an area in the RTC FAST memory (access only PRO_CPU).\nUsed to save the addresses of the selected application.\nWhen a wakeup occurs (from Deep sleep), the bootloader retrieves it and\nloads the application without validation.",
"help":"This option reserves in RTC FAST memory the area for custom purposes.\nIf you want to create your own bootloader and save more information\nin this area of memory, you can increase it. It must be a multiple of 4 bytes.\nThis area (rtc_retain_mem_t) is reserved and has access from the bootloader and an application.",
"help":"This option allows the customer to place data in the RTC FAST memory,\nthis area remains valid when rebooted, except for power loss.\nThis memory is located at a fixed address and is available\nfor both the bootloader and the application.\n(The application and bootoloader must be compiled with the same option).\nThe RTC FAST memory has access only through PRO_CPU.",
"id":"BOOTLOADER_CUSTOM_RESERVE_RTC",
"name":"BOOTLOADER_CUSTOM_RESERVE_RTC",
"range":null,
"title":"Reserve RTC FAST memory for custom purposes",
"help":"Require apps to be signed to verify their integrity.\n\nThis option uses the same app signature scheme as hardware secure boot, but unlike hardware secure boot it\ndoes not prevent the bootloader from being physically updated. This means that the device can be secured\nagainst remote network access, but not physical access. Compared to using hardware Secure Boot this option\nis much simpler to implement.",
"help":"Select the Secure App signing scheme. Depends on the Chip Revision.\nThere are two options:\n1. ECDSA based secure boot scheme. (Only choice for Secure Boot V1)\nSupported in ESP32 and ESP32-ECO3.\n2. The RSA based secure boot scheme. (Only choice for Secure Boot V2)\nSupported in ESP32-ECO3. (ESP32 Chip Revision 3 onwards)",
"id":"security-features-app-signing-scheme",
"name":"SECURE_SIGNED_APPS_SCHEME",
"title":"App Signing Scheme",
"type":"choice"
},
{
"children":[],
"depends_on":"SECURE_SIGNED_APPS_NO_SECURE_BOOT",
"help":"If this option is set, the bootloader will be compiled with code to verify that an app is signed before\nbooting it.\n\nIf hardware secure boot is enabled, this option is always enabled and cannot be disabled.\nIf hardware secure boot is not enabled, this option doesn't add significant security by itself so most\nusers will want to leave it disabled.",
"id":"SECURE_SIGNED_ON_BOOT_NO_SECURE_BOOT",
"name":"SECURE_SIGNED_ON_BOOT_NO_SECURE_BOOT",
"range":null,
"title":"Bootloader verifies app signatures",
"type":"bool"
},
{
"children":[],
"depends_on":"SECURE_SIGNED_APPS_NO_SECURE_BOOT",
"help":"If this option is set, any OTA updated apps will have the signature verified before being considered valid.\n\nWhen enabled, the signature is automatically checked whenever the esp_ota_ops.h APIs are used for OTA\nupdates, or esp_image_format.h APIs are used to verify apps.\n\nIf hardware secure boot is enabled, this option is always enabled and cannot be disabled.\nIf hardware secure boot is not enabled, this option still adds significant security against network-based\nattackers by preventing spoofing of OTA updates.",
"help":"Build a bootloader which enables secure boot version 1 on first boot.\nRefer to the Secure Boot section of the ESP-IDF Programmer's Guide for this version before enabling.",
"help":"Build a bootloader which enables Secure Boot version 2 on first boot.\nRefer to Secure Boot V2 section of the ESP-IDF Programmer's Guide for this version before enabling.",
"help":"Select the Secure Boot Version. Depends on the Chip Revision.\nSecure Boot V2 is the new RSA based secure boot scheme.\nSupported in ESP32-ECO3. (ESP32 Chip Revision 3 onwards)\nSecure Boot V1 is the AES based secure boot scheme.\nSupported in ESP32 and ESP32-ECO3.",
"help":"Build a bootloader which enables Secure Boot on first boot.\n\nOnce enabled, Secure Boot will not boot a modified bootloader. The bootloader will only load a partition\ntable or boot an app if the data has a verified digital signature. There are implications for reflashing\nupdated apps once secure boot is enabled.\n\nWhen enabling secure boot, JTAG and ROM BASIC Interpreter are permanently disabled by default.",
"id":"SECURE_BOOT",
"name":"SECURE_BOOT",
"range":null,
"title":"Enable hardware Secure Boot in bootloader (READ DOCS FIRST)",
"help":"On first boot, the bootloader will generate a key which is not readable externally or by software. A\ndigest is generated from the bootloader image itself. This digest will be verified on each subsequent\nboot.\n\nEnabling this option means that the bootloader cannot be changed after the first time it is booted.",
"id":"SECURE_BOOTLOADER_ONE_TIME_FLASH",
"name":"SECURE_BOOTLOADER_ONE_TIME_FLASH",
"range":null,
"title":"One-time flash",
"type":"bool"
},
{
"children":[],
"depends_on":"<choice SECURE_BOOTLOADER_MODE>",
"help":"Generate a reusable secure bootloader key, derived (via SHA-256) from the secure boot signing key.\n\nThis allows the secure bootloader to be re-flashed by anyone with access to the secure boot signing\nkey.\n\nThis option is less secure than one-time flash, because a leak of the digest key from one device\nallows reflashing of any device that uses it.",
"id":"SECURE_BOOTLOADER_REFLASHABLE",
"name":"SECURE_BOOTLOADER_REFLASHABLE",
"range":null,
"title":"Reflashable",
"type":"bool"
}
],
"depends_on":"SECURE_BOOT_V1_ENABLED",
"help":null,
"id":"security-features-secure-bootloader-mode",
"name":"SECURE_BOOTLOADER_MODE",
"title":"Secure bootloader mode",
"type":"choice"
},
{
"children":[
{
"children":[],
"depends_on":"SECURE_BOOT_BUILD_SIGNED_BINARIES",
"help":"Path to the key file used to sign app images.\n\nKey file is an ECDSA private key (NIST256p curve) in PEM format for Secure Boot V1.\nKey file is an RSA private key in PEM format for Secure Boot V2.\n\nPath is evaluated relative to the project directory.\n\nYou can generate a new signing key by running the following command:\nespsecure.py generate_signing_key secure_boot_signing_key.pem\n\nSee the Secure Boot section of the ESP-IDF Programmer's Guide for this version for details.",
"help":"Once secure boot or signed app requirement is enabled, app images are required to be signed.\n\nIf enabled (default), these binary files are signed as part of the build process. The file named in\n\"Secure boot private signing key\" will be used to sign the image.\n\nIf disabled, unsigned app/partition data will be built. They must be signed manually using espsecure.py.\nVersion 1 to enable ECDSA Based Secure Boot and Version 2 to enable RSA based Secure Boot.\n(for example, on a remote signing server.)",
"help":"Path to a public key file used to verify signed images.\nSecure Boot V1: This ECDSA public key is compiled into the bootloader and/or\napp, to verify app images.\nSecure Boot V2: This RSA public key is compiled into the signature block at\nthe end of the bootloader/app.\n\nKey file is in raw binary format, and can be extracted from a\nPEM formatted private key using the espsecure.py\nextract_public_key command.\n\nRefer to the Secure Boot section of the ESP-IDF Programmer's Guide for this version before enabling.",
"id":"SECURE_BOOT_VERIFICATION_KEY",
"name":"SECURE_BOOT_VERIFICATION_KEY",
"range":null,
"title":"Secure boot public signature verification key",
"help":"In reflashable secure bootloader mode, a hardware key is derived from the signing key (with SHA-256) and\ncan be written to eFuse with espefuse.py.\n\nNormally this is a 256-bit key, but if 3/4 Coding Scheme is used on the device then the eFuse key is\ntruncated to 192 bits.\n\nThis configuration item doesn't change any firmware code, it only changes the size of key binary which is\ngenerated at build time.",
"help":"You can disable some of the default protections offered by secure boot, in order to enable testing or a\ncustom combination of security features.\n\nOnly enable these options if you are very sure.\n\nRefer to the Secure Boot section of the ESP-IDF Programmer's Guide for this version before enabling.",
"help":"Size of generated AES-XTS key.\n\nAES-128 uses a 256-bit key (32 bytes) which occupies one Efuse key block.\nAES-256 uses a 512-bit key (64 bytes) which occupies two Efuse key blocks.\n\nThis setting is ignored if either type of key is already burned to Efuse before the first boot.\nIn this case, the pre-burned key is used and no new key is generated.",
"help":"By default Development mode is enabled which allows UART bootloader to perform flash encryption operations\n\nSelect Release mode only for production or manufacturing. Once enabled you can not reflash using UART\nbootloader\n\nRefer to the Secure Boot section of the ESP-IDF Programmer's Guide for this version and\nhttps://docs.espressif.com/projects/esp-idf/en/latest/security/flash-encryption.html for details.",
"help":"If this option is set, flash contents will be encrypted by the bootloader on first boot.\n\nNote: After first boot, the system will be permanently encrypted. Re-flashing an encrypted\nsystem is complicated and not always possible.\n\nRead https://docs.espressif.com/projects/esp-idf/en/latest/security/flash-encryption.html\nbefore enabling.",
"id":"SECURE_FLASH_ENC_ENABLED",
"name":"SECURE_FLASH_ENC_ENABLED",
"range":null,
"title":"Enable flash encryption on boot (READ DOCS FIRST)",
"help":"By default, the BASIC ROM Console starts on reset if no valid bootloader is\nread from the flash.\n\nWhen either flash encryption or secure boot are enabled, the default is to\ndisable this BASIC fallback mode permanently via eFuse.\n\nIf this option is set, this eFuse is not burned and the BASIC ROM Console may\nremain accessible. Only set this option in testing environments.",
"id":"SECURE_BOOT_ALLOW_ROM_BASIC",
"name":"SECURE_BOOT_ALLOW_ROM_BASIC",
"range":null,
"title":"Leave ROM BASIC Interpreter available on reset",
"help":"If not set (default), the bootloader will permanently disable JTAG (across entire chip) on first boot\nwhen either secure boot or flash encryption is enabled.\n\nSetting this option leaves JTAG on for debugging, which negates all protections of flash encryption\nand some of the protections of secure boot.\n\nOnly set this option in testing environments.",
"id":"SECURE_BOOT_ALLOW_JTAG",
"name":"SECURE_BOOT_ALLOW_JTAG",
"range":null,
"title":"Allow JTAG Debugging",
"type":"bool"
},
{
"children":[],
"depends_on":"SECURE_BOOT_INSECURE",
"help":"If not set (default), app partition size must be a multiple of 64KB. App images are padded to 64KB\nlength, and the bootloader checks any trailing bytes after the signature (before the next 64KB\nboundary) have not been written. This is because flash cache maps entire 64KB pages into the address\nspace. This prevents an attacker from appending unverified data after the app image in the flash,\ncausing it to be mapped into the address space.\n\nSetting this option allows the app partition length to be unaligned, and disables padding of the app\nimage to this length. It is generally not recommended to set this option, unless you have a legacy\npartitioning scheme which doesn't support 64KB aligned partition lengths.",
"id":"SECURE_BOOT_ALLOW_SHORT_APP_PARTITION",
"name":"SECURE_BOOT_ALLOW_SHORT_APP_PARTITION",
"range":null,
"title":"Allow app partition length not 64KB aligned",
"help":"If not set (default), the bootloader will permanently disable UART bootloader encryption access on\nfirst boot. If set, the UART bootloader will still be able to access hardware encryption.\n\nIt is recommended to only set this option in testing environments.",
"help":"If not set (default), the bootloader will permanently disable UART bootloader decryption access on\nfirst boot. If set, the UART bootloader will still be able to access hardware decryption.\n\nOnly set this option in testing environments. Setting this option allows complete bypass of flash\nencryption.",
"help":"If not set (default), the bootloader will permanently disable UART bootloader flash cache access on\nfirst boot. If set, the UART bootloader will still be able to access the flash cache.\n\nOnly set this option in testing environments.",
"help":"If not set (default), and flash encryption is not yet enabled in eFuses, the 2nd stage bootloader\nwill enable flash encryption: generate the flash encryption key and program eFuses.\nIf this option is set, and flash encryption is not yet enabled, the bootloader will error out and\nreboot.\nIf flash encryption is enabled in eFuses, this option does not change the bootloader behavior.\n\nOnly use this option in testing environments, to avoid accidentally enabling flash encryption on\nthe wrong device. The device needs to have flash encryption already enabled using espefuse.py.",
"id":"SECURE_FLASH_REQUIRE_ALREADY_ENABLED",
"name":"SECURE_FLASH_REQUIRE_ALREADY_ENABLED",
"range":null,
"title":"Require flash encryption to be already enabled",
"help":"The serial port that's connected to the ESP chip. This can be overridden by setting the ESPPORT\nenvironment variable.\n\nThis value is ignored when using the CMake-based build system or idf.py.",
"help":"Default baud rate to use while communicating with the ESP chip. Can be overridden by\nsetting the ESPBAUD variable.\n\nThis value is ignored when using the CMake-based build system or idf.py.",
"help":"The flasher tool can send data compressed using zlib, letting the ROM on the ESP chip\ndecompress it on the fly before flashing it. For most payloads, this should result in a\nspeed increase.",
"help":"If this option is set, flashing the project will automatically detect\nthe flash size of the target chip and update the bootloader image\nbefore it is flashed.",
"id":"ESPTOOLPY_FLASHSIZE_DETECT",
"name":"ESPTOOLPY_FLASHSIZE_DETECT",
"range":null,
"title":"Detect flash size when flashing bootloader",
"help":"Configure whether esptool.py should reset the ESP32 before flashing.\n\nAutomatic resetting depends on the RTS & DTR signals being\nwired from the serial port to the ESP32. Most USB development\nboards do this internally.",
"help":"Configure whether esptool.py should reset the ESP32 after flashing.\n\nAutomatic resetting depends on the RTS & DTR signals being\nwired from the serial port to the ESP32. Most USB development\nboards do this internally.",
"help":"Baud rate to use when running 'idf.py monitor' or 'make monitor'\nto view serial output from a running chip.\n\nCan override by setting the MONITORBAUD environment variable.",
"help":"The partition table to flash to the ESP32. The partition table\ndetermines where apps, data and other resources are expected to\nbe found.\n\nThe predefined partition table CSV descriptions can be found\nin the components/partition_table directory. Otherwise it's\npossible to create a new custom partition CSV for your application.",
"help":"The address of partition table (by default 0x8000).\nAllows you to move the partition table, it gives more space for the bootloader.\nNote that the bootloader and app will both need to be compiled with the same PARTITION_TABLE_OFFSET value.\n\nThis number should be a multiple of 0x1000.\n\nNote that partition offsets in the partition table CSV file may need to be changed if this value is set to\na higher value. To have each partition offset adapt to the configured partition table offset, leave all\npartition offsets blank in the CSV file.",
"help":"Generate an MD5 checksum for the partition table for protecting the\nintegrity of the table. The generation should be turned off for legacy\nbootloaders which cannot recognize the MD5 checksum in the partition\ntable.",
"id":"PARTITION_TABLE_MD5",
"name":"PARTITION_TABLE_MD5",
"range":null,
"title":"Generate an MD5 checksum for the partition table",
"help":"This option sets compiler optimization level (gcc -O argument) for the app.\n\n- The \"Default\" setting will add the -0g flag to CFLAGS.\n- The \"Size\" setting will add the -0s flag to CFLAGS.\n- The \"Performance\" setting will add the -O2 flag to CFLAGS.\n- The \"None\" setting will add the -O0 flag to CFLAGS.\n\nThe \"Size\" setting cause the compiled code to be smaller and faster, but\nmay lead to difficulties of correlating code addresses to source file\nlines when debugging.\n\nThe \"Performance\" setting causes the compiled code to be larger and faster,\nbut will be easier to correlated code addresses to source file lines.\n\n\"None\" with -O0 produces compiled code without optimization.\n\nNote that custom optimization levels may be unsupported.\n\nCompiler optimization for the IDF bootloader is set separately,\nsee the BOOTLOADER_COMPILER_OPTIMIZATION setting.",
"help":"Enable silent assertions. Failed assertions will abort(), user needs to\nuse the aborting address to find the line number with the failed assertion.",
"help":"Assertions can be:\n\n- Enabled. Failure will print verbose assertion details. This is the default.\n\n- Set to \"silent\" to save code size (failed assertions will abort() but user\n needs to use the aborting address to find the line number with the failed assertion.)\n\n- Disabled entirely (not recommended for most configurations.) -DNDEBUG is added\n to CPPFLAGS in this case.",
"help":"Size (in bytes) of the emergency memory pool for C++ exceptions. This pool will be used to allocate\nmemory for thrown exceptions when there is not enough memory on the heap.",
"help":"Enabling this option compiles all IDF C++ files with exception support enabled.\n\nDisabling this option disables C++ exception support in all compiled files, and any libstdc++ code\nwhich throws an exception will abort instead.\n\nEnabling this option currently adds an additional ~500 bytes of heap overhead\nwhen an exception is thrown in user code for the first time.",
"help":"Enabling this option compiles all C++ files with RTTI support enabled.\nThis increases binary size (typically by tens of kB) but allows using\ndynamic_cast conversion and typeid operator.",
"help":"Stack smashing protection mode. Emit extra code to check for buffer overflows, such as stack\nsmashing attacks. This is done by adding a guard variable to functions with vulnerable objects.\nThe guards are initialized when a function is entered and then checked when the function exits.\nIf a guard check fails, program is halted. Protection has the following modes:\n\n- In NORMAL mode (GCC flag: -fstack-protector) only functions that call alloca, and functions with\n buffers larger than 8 bytes are protected.\n\n- STRONG mode (GCC flag: -fstack-protector-strong) is like NORMAL, but includes additional functions\n to be protected -- those that have local array definitions, or have references to local frame\n addresses.\n\n- In OVERALL mode (GCC flag: -fstack-protector-all) all functions are protected.\n\nModes have the following impact on code performance and coverage:\n\n- performance: NORMAL > STRONG > OVERALL\n\n- coverage: NORMAL < STRONG < OVERALL",
"help":"Adds -Wwrite-strings flag for the C/C++ compilers.\n\nFor C, this gives string constants the type ``const char[]`` so that\ncopying the address of one into a non-const ``char *`` pointer\nproduces a warning. This warning helps to find at compile time code\nthat tries to write into a string constant.\n\nFor C++, this warns about the deprecated conversion from string\nliterals to ``char *``.",
"help":"Allows to generate a structure for eFuse from the CSV file.",
"id":"EFUSE_CUSTOM_TABLE",
"name":"EFUSE_CUSTOM_TABLE",
"range":null,
"title":"Use custom eFuse table",
"type":"bool"
},
{
"children":[],
"depends_on":null,
"help":"All read and writes operations are redirected to RAM instead of eFuse registers.\nIf this option is set, all permanent changes (via eFuse) are disabled.\nLog output will state changes which would be applied, but they will not be.",
"help":"Select the speed for the SPI RAM chip.\nIf SPI RAM is enabled, we only support three combinations of SPI speed mode we supported now:\n\n1. Flash SPI running at 40Mhz and RAM SPI running at 40Mhz\n2. Flash SPI running at 80Mhz and RAM SPI running at 40Mhz\n3. Flash SPI running at 80Mhz and RAM SPI running at 80Mhz\n\nNote: If the third mode(80Mhz+80Mhz) is enabled for SPI RAM of type 32MBit, one of the HSPI/VSPI host\nwill be occupied by the system. Which SPI host to use can be selected by the config item\nSPIRAM_OCCUPY_SPI_HOST. Application code should never touch HSPI/VSPI hardware in this case. The\noption to select 80MHz will only be visible if the flash SPI speed is also 80MHz.\n(ESPTOOLPY_FLASHFREQ_80M is true)",
"help":"Normally, if psram initialization is enabled during compile time but not found at runtime, it\nis seen as an error making the CPU panic. If this is enabled, booting will complete\nbut no PSRAM will be available.",
"help":"If this is enabled, the SPI RAM will be enabled during initial boot. Unless you\nhave specific requirements, you'll want to leave this enabled so memory allocated\nduring boot-up can also be placed in SPI RAM.",
"help":"The SPI RAM can be accessed in multiple methods: by just having it available as an unmanaged\nmemory region in the CPU's memory map, by integrating it in the heap as 'special' memory\nneeding heap_caps_malloc to allocate, or by fully integrating it making malloc() also able to\nreturn SPI RAM pointers.",
"help":"If malloc() is capable of also allocating SPI-connected ram, its allocation strategy will prefer to\nallocate chunks less than this size in internal memory, while allocations larger than this will be\ndone from external RAM. If allocation from the preferred region fails, an attempt is made to allocate\nfrom the non-preferred region instead, so malloc() will not suddenly fail when either internal or\nexternal memory is full.",
"id":"SPIRAM_MALLOC_ALWAYSINTERNAL",
"name":"SPIRAM_MALLOC_ALWAYSINTERNAL",
"range":null,
"title":"Maximum malloc() size, in bytes, to always put in internal memory",
"help":"Because the external/internal RAM allocation strategy is not always perfect, it sometimes may happen\nthat the internal memory is entirely filled up. This causes allocations that are specifically done in\ninternal memory, for example the stack for new tasks or memory to service DMA or have memory that's\nalso available when SPI cache is down, to fail. This option reserves a pool specifically for requests\nlike that; the memory in this pool is not given out when a normal malloc() is called.\n\nSet this to 0 to disable this feature.\n\nNote that because FreeRTOS stacks are forced to internal memory, they will also use this memory pool;\nbe sure to keep this in mind when adjusting this value.\n\nNote also that the DMA reserved pool may not be one single contiguous memory region, depending on the\nconfigured size and the static memory usage of the app.",
"id":"SPIRAM_MALLOC_RESERVE_INTERNAL",
"name":"SPIRAM_MALLOC_RESERVE_INTERNAL",
"range":null,
"title":"Reserve this amount of bytes for data that specifically needs to be in DMA or internal memory",
"help":"If enabled the option,and add EXT_RAM_ATTR defined your variable,then your variable will be placed in\nPSRAM instead of internal memory, and placed most of variables of lwip,net802.11,pp,bluedroid library\nto external memory defaultly.",
"id":"SPIRAM_ALLOW_BSS_SEG_EXTERNAL_MEMORY",
"name":"SPIRAM_ALLOW_BSS_SEG_EXTERNAL_MEMORY",
"range":null,
"title":"Allow .bss segment placed in external memory",
"help":"Revision 1 of the ESP32 has a bug that can cause a write to PSRAM not to take place in some situations\nwhen the cache line needs to be fetched from external RAM and an interrupt occurs. This enables a\nfix in the compiler (-mfix-esp32-psram-cache-issue) that makes sure the specific code that is\nvulnerable to this will not be emitted.\n\nThis will also not use any bits of newlib that are located in ROM, opting for a version that is\ncompiled with the workaround and located in flash instead.\n\nThe workaround is not required for ESP32 revision 3 and above.",
"id":"SPIRAM_CACHE_WORKAROUND",
"name":"SPIRAM_CACHE_WORKAROUND",
"range":null,
"title":"Enable workaround for bug in SPI RAM cache for Rev1 ESP32s",
"help":"Select the amount of banks reserved for bank switching. Note that the amount of RAM allocatable with\nmalloc/esp_heap_alloc_caps will decrease by 32K for each page reserved here.\n\nNote that this reservation is only actually done if your program actually uses the himem API. Without\nany himem calls, the reservation is not done and the original amount of memory will be available\nto malloc/esp_heap_alloc_caps.",
"id":"SPIRAM_BANKSWITCH_RESERVE",
"name":"SPIRAM_BANKSWITCH_RESERVE",
"range":null,
"title":"Amount of 32K pages to reserve for bank switching",
"help":"The ESP32 only supports 4MiB of external RAM in its address space. The hardware does support larger\nmemories, but these have to be bank-switched in and out of this address space. Enabling this allows you\nto reserve some MMU pages for this, which allows the use of the esp_himem api to manage these banks.\n\n#Note that this is limited to 62 banks, as esp_spiram_writeback_cache needs some kind of mapping of\n#some banks below that mark to work. We cannot at this moment guarantee this to exist when himem is\n#enabled.",
"id":"SPIRAM_BANKSWITCH_ENABLE",
"name":"SPIRAM_BANKSWITCH_ENABLE",
"range":null,
"title":"Enable bank switching for >4MiB external RAM",
"help":"Because some bits of the ESP32 code environment cannot be recompiled with the cache workaround,\nnormally tasks cannot be safely run with their stack residing in external memory; for this reason\nxTaskCreate and friends always allocate stack in internal memory and xTaskCreateStatic will check if\nthe memory passed to it is in internal memory. If you have a task that needs a large amount of stack\nand does not call on ROM code in any way (no direct calls, but also no Bluetooth/WiFi), you can try to\ndisable this and use xTaskCreateStatic to create the tasks stack in external memory.",
"id":"SPIRAM_ALLOW_STACK_EXTERNAL_MEMORY",
"name":"SPIRAM_ALLOW_STACK_EXTERNAL_MEMORY",
"range":null,
"title":"Allow external memory as an argument to xTaskCreateStatic",
"help":"When both flash and PSRAM is working under 80MHz, and the PSRAM is of type 32MBit, one of the HSPI/VSPI\nhost will be used to output the clock. Select which one to use here.",
"help":"The PSRAM CLOCK IO can be any unused GPIO, user can config it based on hardware design. If user use\n1.8V flash and 1.8V psram, this value can only be one of 6, 7, 8, 9, 10, 11, 16, 17.",
"help":"The PSRAM CS IO can be any unused GPIO, user can config it based on hardware design. If user use\n1.8V flash and 1.8V psram, this value can only be one of 6, 7, 8, 9, 10, 11, 16, 17.",
"help":"User can config it based on hardware design. For ESP32-D2WD chip, the psram can only be 1.8V psram,\nso this value can only be one of 6, 7, 8, 9, 10, 11, 16, 17.",
"help":"User can config it based on hardware design. For ESP32-D2WD chip, the psram can only be 1.8V psram,\nso this value can only be one of 6, 7, 8, 9, 10, 11, 16, 17.",
"help":"The PSRAM CS IO can be any unused GPIO, user can config it based on hardware design.\n\nFor ESP32-PICO chip, the psram share clock with flash, so user do not need to configure the clock\nIO.\nFor the reference hardware design, please refer to\nhttps://www.espressif.com/sites/default/files/documentation/esp32-pico-d4_datasheet_en.pdf",
"help":"This value is ignored unless flash mode is set to DIO or DOUT and the SPI flash pins have been\noverriden by setting the eFuses SPI_PAD_CONFIG_xxx.\n\nWhen this is the case, the eFuse config only defines 3 of the 4 Quad I/O data pins. The WP pin (aka\nESP32 pin \"SD_DATA_3\" or SPI flash pin \"IO2\") is not specified in eFuse. And the psram only has QPI\nmode, the WP pin is necessary, so we need to configure this value here.\n\nWhen flash mode is set to QIO or QOUT, the PSRAM WP pin will be set as the value configured in\nbootloader.\n\nFor ESP32-PICO chip, the default value of this config should be 7.",
"id":"SPIRAM_SPIWP_SD3_PIN",
"name":"SPIRAM_SPIWP_SD3_PIN",
"range":null,
"title":"SPI PSRAM WP(SD3) Pin when customising pins via eFuse (read help)",
"help":"The ESP32 contains a feature which allows you to trace the execution path the processor\nhas taken through the program. This is stored in a chunk of 32K (16K for single-processor)\nof memory that can't be used for general purposes anymore. Disable this if you do not know\nwhat this is.\n\n# Memory to reverse for trace, used in linker script",
"id":"ESP32_TRAX_TWOBANKS",
"name":"ESP32_TRAX_TWOBANKS",
"range":null,
"title":"Reserve memory for tracing both pro as well as app cpu execution",
"help":"The ESP32 contains a feature which allows you to trace the execution path the processor\nhas taken through the program. This is stored in a chunk of 32K (16K for single-processor)\nof memory that can't be used for general purposes anymore. Disable this if you do not know\nwhat this is.",
"help":"Configure the number of universally administered (by IEEE) MAC addresses.\nDuring initialization, MAC addresses for each network interface are generated or derived from a\nsingle base MAC address.\nIf the number of universal MAC addresses is four, all four interfaces (WiFi station, WiFi softap,\nBluetooth and Ethernet) receive a universally administered MAC address. These are generated\nsequentially by adding 0, 1, 2 and 3 (respectively) to the final octet of the base MAC address.\nIf the number of universal MAC addresses is two, only two interfaces (WiFi station and Bluetooth)\nreceive a universally administered MAC address. These are generated sequentially by adding 0\nand 1 (respectively) to the base MAC address. The remaining two interfaces (WiFi softap and Ethernet)\nreceive local MAC addresses. These are derived from the universal WiFi station and Bluetooth MAC\naddresses, respectively.\nWhen using the default (Espressif-assigned) base MAC address, either setting can be used. When using\na custom universal MAC address range, the correct setting will depend on the allocation of MAC\naddresses in this range (either 2 or 4 per device.)",
"help":"Set to 'y' if you plan to load a firmware for the coprocessor.\n\nIf this option is enabled, further coprocessor configuration will appear in the Components menu.",
"id":"ESP32_ULP_COPROC_ENABLED",
"name":"ESP32_ULP_COPROC_ENABLED",
"range":null,
"title":"Enable Ultra Low Power (ULP) Coprocessor",
"type":"bool"
},
{
"children":[],
"depends_on":null,
"help":"The FreeRTOS panic and unhandled exception handers can detect a JTAG OCD debugger and\ninstead of panicking, have the debugger stop on the offending instruction.",
"id":"ESP32_DEBUG_OCDAWARE",
"name":"ESP32_DEBUG_OCDAWARE",
"range":null,
"title":"Make exception and panic handlers JTAG/OCD aware",
"help":"The brownout detector will reset the chip when the supply voltage is approximately\nbelow this level. Note that there may be some variation of brownout voltage level\nbetween each ESP32 chip.\n\n#The voltage levels here are estimates, more work needs to be done to figure out the exact voltages\n#of the brownout threshold levels.",
"help":"The ESP32 has a built-in brownout detector which can detect if the voltage is lower than\na specific value. If this happens, it will reset the chip in order to prevent unintended\nbehaviour.",
"help":"When brownout reset occurs, reduce PHY TX power to keep the code running\n\n# Note about the use of \"FRC1\" name: currently FRC1 timer is not used for\n# high resolution timekeeping anymore. Instead the esp_timer API is used.\n# FRC1 name in the option name is kept for compatibility.",
"id":"ESP32_REDUCE_PHY_TX_POWER",
"name":"ESP32_REDUCE_PHY_TX_POWER",
"range":null,
"title":"Reduce PHY TX power when brownout reset",
"help":"This setting defines which hardware timers are used to\nimplement 'gettimeofday' and 'time' functions in C library.\n\n- If both high-resolution and RTC timers are used, timekeeping will\n continue in deep sleep. Time will be reported at 1 microsecond\n resolution. This is the default, and the recommended option.\n- If only high-resolution timer is used, gettimeofday will\n provide time at microsecond resolution.\n Time will not be preserved when going into deep sleep mode.\n- If only RTC timer is used, timekeeping will continue in\n deep sleep, but time will be measured at 6.(6) microsecond\n resolution. Also the gettimeofday function itself may take\n longer to run.\n- If no timers are used, gettimeofday and time functions\n return -1 and set errno to ENOSYS.\n- When RTC is used for timekeeping, two RTC_STORE registers are\n used to keep time in deep sleep mode.",
"help":"Choose which clock is used as RTC clock source.\n\n- \"Internal 150kHz oscillator\" option provides lowest deep sleep current\n consumption, and does not require extra external components. However\n frequency stability with respect to temperature is poor, so time may\n drift in deep/light sleep modes.\n- \"External 32kHz crystal\" provides better frequency stability, at the\n expense of slightly higher (1uA) deep sleep current consumption.\n- \"External 32kHz oscillator\" allows using 32kHz clock generated by an\n external circuit. In this case, external clock signal must be connected\n to 32K_XP pin. Amplitude should be <1.2V in case of sine wave signal,\n and <1V in case of square wave signal. Common mode voltage should be\n 0.1 < Vcm < 0.5Vamp, where Vamp is the signal amplitude.\n Additionally, 1nF capacitor must be connected between 32K_XN pin and\n ground. 32K_XN pin can not be used as a GPIO in this case.\n- \"Internal 8.5MHz oscillator divided by 256\" option results in higher\n deep sleep current (by 5uA) but has better frequency stability than\n the internal 150kHz oscillator. It does not require external components.",
"help":"Choose which additional current is used for rtc external crystal.\n\n- With some 32kHz crystal configurations, the X32N and X32P pins may not\n have enough drive strength to keep the crystal oscillating during deep sleep.\n If this option is enabled, additional current from touchpad 9 is provided\n internally to drive the 32kHz crystal. If this option is enabled, deep sleep current\n is slightly higher (4-5uA) and the touchpad and ULP wakeup sources are not available.",
"id":"ESP32_RTC_EXT_CRYST_ADDIT_CURRENT",
"name":"ESP32_RTC_EXT_CRYST_ADDIT_CURRENT",
"range":null,
"title":"Additional current for external 32kHz crystal",
"type":"bool"
},
{
"children":[],
"depends_on":null,
"help":"When the startup code initializes RTC_SLOW_CLK, it can perform\ncalibration by comparing the RTC_SLOW_CLK frequency with main XTAL\nfrequency. This option sets the number of RTC_SLOW_CLK cycles measured\nby the calibration routine. Higher numbers increase calibration\nprecision, which may be important for applications which spend a lot of\ntime in deep sleep. Lower numbers reduce startup time.\n\nWhen this option is set to 0, clock calibration will not be performed at\nstartup, and approximate clock frequencies will be assumed:\n\n- 150000 Hz if internal RC oscillator is used as clock source. For this use value 1024.\n- 32768 Hz if the 32k crystal oscillator is used. For this use value 3000 or more.\n In case more value will help improve the definition of the launch of the crystal.\n If the crystal could not start, it will be switched to internal RC.",
"help":"To reduce the startup time of an external RTC crystal,\nwe bootstrap it with a 32kHz square wave for a fixed number of cycles.\nSetting 0 will disable bootstrapping (if disabled, the crystal may take\nlonger to start up or fail to oscillate under some conditions).\n\nIf this value is too high, a faulty crystal may initially start and then fail.\nIf this value is too low, an otherwise good crystal may not start.\n\nTo accurately determine if the crystal has started,\nset a larger \"Number of cycles for RTC_SLOW_CLK calibration\" (about 3000).",
"id":"ESP32_RTC_XTAL_BOOTSTRAP_CYCLES",
"name":"ESP32_RTC_XTAL_BOOTSTRAP_CYCLES",
"range":null,
"title":"Bootstrap cycles for external 32kHz crystal",
"help":"When ESP32 exits deep sleep, the CPU and the flash chip are powered on\nat the same time. CPU will run deep sleep stub first, and then\nproceed to load code from flash. Some flash chips need sufficient\ntime to pass between power on and first read operation. By default,\nwithout any extra delay, this time is approximately 900us, although\nsome flash chip types need more than that.\n\nBy default extra delay is set to 2000us. When optimizing startup time\nfor applications which require it, this value may be reduced.\n\nIf you are seeing \"flash read err, 1000\" message printed to the\nconsole after deep sleep reset, try increasing this value.",
"help":"ESP32 currently supports the following XTAL frequencies:\n\n- 26 MHz\n- 40 MHz\n\nStartup code can automatically estimate XTAL frequency. This feature\nuses the internal 8MHz oscillator as a reference. Because the internal\noscillator frequency is temperature dependent, it is not recommended\nto use automatic XTAL frequency detection in applications which need\nto work at high ambient temperatures and use high-temperature\nqualified chips and modules.",
"help":"If set, the first time the app boots it will disable the BASIC ROM Console\npermanently (by burning an eFuse).\n\nOtherwise, the BASIC ROM Console starts on reset if no valid bootloader is\nread from the flash.\n\n(Enabling secure boot also disables the BASIC ROM Console by default.)",
"id":"ESP32_DISABLE_BASIC_ROM_CONSOLE",
"name":"ESP32_DISABLE_BASIC_ROM_CONSOLE",
"range":null,
"title":"Permanently disable BASIC ROM Console",
"type":"bool"
},
{
"children":[],
"depends_on":"!BT_ENABLED",
"help":"If enabled, this disables the linking of binary libraries in the application build. Note\nthat after enabling this Wi-Fi/Bluetooth will not work.",
"id":"ESP32_NO_BLOBS",
"name":"ESP32_NO_BLOBS",
"range":null,
"title":"No Binary Blobs",
"type":"bool"
},
{
"children":[],
"depends_on":null,
"help":"Bootloaders before IDF v2.1 did less initialisation of the\nsystem clock. This setting needs to be enabled to build an app\nwhich can be booted by these older bootloaders.\n\nIf this setting is enabled, the app can be booted by any bootloader\nfrom IDF v1.0 up to the current version.\n\nIf this setting is disabled, the app can only be booted by bootloaders\nfrom IDF v2.1 or newer.\n\nEnabling this setting adds approximately 1KB to the app's IRAM usage.",
"id":"ESP32_COMPATIBLE_PRE_V2_1_BOOTLOADERS",
"name":"ESP32_COMPATIBLE_PRE_V2_1_BOOTLOADERS",
"range":null,
"title":"App compatible with bootloaders before IDF v2.1",
"type":"bool"
},
{
"children":[],
"depends_on":null,
"help":null,
"id":"ESP32_APP_INIT_CLK",
"name":"ESP32_APP_INIT_CLK",
"range":null,
"title":null,
"type":"bool"
},
{
"children":[],
"depends_on":"FREERTOS_UNICORE",
"help":"This option allows to place .rtc_data and .rtc_rodata sections into\nRTC fast memory segment to free the slow memory region for ULP programs.\nThis option depends on the CONFIG_FREERTOS_UNICORE option because RTC fast memory\ncan be accessed only by PRO_CPU core.",
"id":"ESP32_RTCDATA_IN_FAST_MEM",
"name":"ESP32_RTCDATA_IN_FAST_MEM",
"range":null,
"title":"Place RTC_DATA_ATTR and RTC_RODATA_ATTR variables into RTC fast memory segment",
"help":"RAM size dedicated for static variables (.data & .bss sections).\nPlease note that the actual length will be reduced by BT_RESERVE_DRAM if Bluetooth\ncontroller is enabled.",
"help":"If this option is disabled, the DRAM part of the heap starts right after the .bss section,\nwithin the dram0_0 region. As a result, adding or removing some static variables\nwill change the available heap size.\n\nIf this option is enabled, the DRAM part of the heap starts right after the dram0_0 region,\nwhere its length is set with ESP32_FIXED_STATIC_RAM_SIZE",
"id":"ESP32_USE_FIXED_STATIC_RAM_SIZE",
"name":"ESP32_USE_FIXED_STATIC_RAM_SIZE",
"range":null,
"title":"Use fixed static RAM size",
"type":"bool"
},
{
"children":[],
"depends_on":null,
"help":"To prevent interrupting DPORT workarounds,\nneed to disable interrupt with a maximum used level in the system.",
"id":"ESP32_DPORT_DIS_INTERRUPT_LVL",
"name":"ESP32_DPORT_DIS_INTERRUPT_LVL",
"range":null,
"title":"Disable the interrupt level for the DPORT workarounds",
"help":"If enabled, application can use IRAM as byte accessible region for storing data\n(Note: IRAM region cannot be used as task stack)\n\nThis is possible due to handling of exceptions `LoadStoreError (3)` and `LoadStoreAlignmentError (9)`\nEach unaligned read/write access will incur a penalty of maximum of 167 CPU cycles.",
"help":"If enabled, startup code configures dynamic frequency scaling.\nMax CPU frequency is set to CONFIG_ESP32_DEFAULT_CPU_FREQ_MHZ setting,\nmin frequency is set to XTAL frequency.\nIf disabled, DFS will not be active until the application\nconfigures it using esp_pm_configure function.",
"id":"PM_DFS_INIT_AUTO",
"name":"PM_DFS_INIT_AUTO",
"range":null,
"title":"Enable dynamic frequency scaling (DFS) at startup",
"help":"When APB clock frequency changes, high-resolution timer (esp_timer)\nscale and base value need to be adjusted. Each adjustment may cause\nsmall error, and over time such small errors may cause time drift.\nIf this option is enabled, RTC timer will be used as a reference to\ncompensate for the drift.\nIt is recommended that this option is only used if 32k XTAL is selected\nas RTC clock source.",
"id":"PM_USE_RTC_TIMER_REF",
"name":"PM_USE_RTC_TIMER_REF",
"range":null,
"title":"Use RTC timer to prevent time drift (EXPERIMENTAL)",
"help":"If enabled, esp_pm_* functions will keep track of the amount of time\neach of the power management locks has been held, and esp_pm_dump_locks\nfunction will print this information.\nThis feature can be used to analyze which locks are preventing the chip\nfrom going into a lower power state, and see what time the chip spends\nin each power saving mode. This feature does incur some run-time\noverhead, so should typically be disabled in production builds.",
"help":"If enabled, some GPIOs will be used to signal events such as RTOS ticks,\nfrequency switching, entry/exit from idle state. Refer to pm_trace.c\nfile for the list of GPIOs.\nThis feature is intended to be used when analyzing/debugging behavior\nof power management implementation, and should be kept disabled in\napplications.",
"help":"If enabled, application is compiled with support for power management.\nThis option has run-time overhead (increased interrupt latency,\nlonger time to enter idle state), and it also reduces accuracy of\nRTOS ticks and timers used for timekeeping.\nEnable this option if application uses power management APIs.",
"help":"Functions esp_err_to_name() and esp_err_to_name_r() return string representations of error codes from a\npre-generated lookup table. This option can be used to turn off the use of the look-up table in order to\nsave memory but this comes at the price of sacrificing distinguishable (meaningful) output string\nrepresentations.",
"id":"ESP_ERR_TO_NAME_LOOKUP",
"name":"ESP_ERR_TO_NAME_LOOKUP",
"range":null,
"title":"Enable lookup of error code strings",
"type":"bool"
},
{
"children":[],
"depends_on":null,
"help":"Config system event queue size in different application.",
"help":"Configure the \"main task\" stack size. This is the stack of the task\nwhich calls app_main(). If app_main() returns then this task is deleted\nand its stack memory is freed.",
"help":"Configure the IPC tasks stack size. One IPC task runs on each core\n(in dual core mode), and allows for cross-core function calls.\n\nSee IPC documentation for more details.\n\nThe default stack size should be enough for most common use cases.\nIt can be shrunk if you are sure that you do not use any custom\nIPC functionality.",
"help":"If this option is not enabled then the IPC task will keep behavior\nsame as prior to that of ESP-IDF v4.0, and hence IPC task will run\nat (configMAX_PRIORITIES - 1) priority.",
"id":"ESP_IPC_USES_CALLERS_PRIORITY",
"name":"ESP_IPC_USES_CALLERS_PRIORITY",
"range":null,
"title":"IPC runs at caller's priority",
"type":"bool"
},
{
"children":[],
"depends_on":null,
"help":"Minimal value of size, in bytes, accepted to execute a expression\nwith shared stack.",
"help":"Select whether to use UART for console output (through stdout and stderr).\n\n- Default is to use UART0 on pre-defined GPIOs.\n- If \"Custom\" is selected, UART0 or UART1 can be chosen,\n and any pins can be selected.\n- If \"None\" is selected, there will be no console output on any UART, except\n for initial output from ROM bootloader. This output can be further suppressed by\n bootstrapping GPIO13 pin to low logic level.",
"help":"This watchdog timer can detect if the FreeRTOS tick interrupt has not been called for a certain time,\neither because a task turned off interrupts and did not turn them on for a long time, or because an\ninterrupt handler did not return. It will try to invoke the panic handler first and failing that\nreset the SoC.",
"help":"If this option is enabled, the Task Watchdog Timer will be configured to\ntrigger the panic handler when it times out. This can also be configured\nat run time (see Task Watchdog Timer API Reference)",
"id":"ESP_TASK_WDT_PANIC",
"name":"ESP_TASK_WDT_PANIC",
"range":null,
"title":"Invoke panic handler on Task Watchdog timeout",
"help":"Timeout period configuration for the Task Watchdog Timer in seconds.\nThis is also configurable at run time (see Task Watchdog Timer API Reference)",
"help":"If this option is enabled, the Task Watchdog Timer will watch the CPU0\nIdle Task. Having the Task Watchdog watch the Idle Task allows for detection\nof CPU starvation as the Idle Task not being called is usually a symptom of\nCPU starvation. Starvation of the Idle Task is detrimental as FreeRTOS household\ntasks depend on the Idle Task getting some runtime every now and then.",
"help":"The Task Watchdog Timer can be used to make sure individual tasks are still\nrunning. Enabling this option will cause the Task Watchdog Timer to be\ninitialized automatically at startup. The Task Watchdog timer can be\ninitialized after startup as well (see Task Watchdog Timer API Reference)",
"id":"ESP_TASK_WDT",
"name":"ESP_TASK_WDT",
"range":null,
"title":"Initialize Task Watchdog Timer on startup",
"type":"bool"
},
{
"children":[],
"depends_on":"IDF_TARGET_ESP32",
"help":"If this option is disabled (default), the panic handler code is placed in flash not IRAM.\nThis means that if ESP-IDF crashes while flash cache is disabled, the panic handler will\nautomatically re-enable flash cache before running GDB Stub or Core Dump. This adds some minor\nrisk, if the flash cache status is also corrupted during the crash.\n\nIf this option is enabled, the panic handler code is placed in IRAM. This allows the panic\nhandler to run without needing to re-enable cache first. This may be necessary to debug some\ncomplex issues with crashes while flash cache is disabled (for example, when writing to\nSPI flash.)",
"id":"ESP_PANIC_HANDLER_IRAM",
"name":"ESP_PANIC_HANDLER_IRAM",
"range":null,
"title":"Place panic handler code in IRAM",
"type":"bool"
},
{
"children":[],
"depends_on":"!ESP32_TRAX && !ESP32S2_TRAX",
"help":"Debug stubs are used by OpenOCD to execute pre-compiled onboard code\nwhich does some useful debugging stuff, e.g. GCOV data dump.",
"help":"Specify how much output to see in logs by default.\nYou can set lower verbosity level at runtime using\nesp_log_level_set function.\n\nNote that this setting limits which log statements\nare compiled into the program. So setting this to, say,\n\"Warning\" would mean that changing log level to \"Debug\"\nat runtime will not be possible.",
"help":"Choose what sort of timestamp is displayed in the log output:\n\n- Milliseconds since boot is calulated from the RTOS tick count multiplied\n by the tick period. This time will reset after a software reboot.\n e.g. (90000)\n\n- System time is taken from POSIX time functions which use the ESP32's\n RTC and FRC1 timers to maintain an accurate time. The system time is\n initialized to 0 on startup, it can be set with an SNTP sync, or with\n POSIX time functions. This time will not reset after a software reboot.\n e.g. (00:01:30.000)\n\n- NOTE: Currently this will not get used in logging from binary blobs\n (i.e WiFi & Bluetooth libraries), these will always print\n milliseconds since boot.",
"help":"If this option is enabled, if SPI flash write verification fails then a log error line\nwill be written with the address, expected & actual values. This can be useful when\ndebugging hardware SPI flash problems.",
"help":"If this option is enabled, any SPI flash write which tries to set zero bits in the flash to\nones will log a warning. Such writes will not result in the requested data appearing identically\nin flash once written, as SPI NOR flash can only set bits to one when an entire sector is erased.\nAfter erasing, individual bits can only be written from one to zero.\n\nNote that some software (such as SPIFFS) which is aware of SPI NOR flash may write one bits as an\noptimisation, relying on the data in flash becoming a bitwise AND of the new data and any existing data.\nSuch software will log spurious warnings if this option is enabled.",
"id":"SPI_FLASH_WARN_SETTING_ZERO_TO_ONE",
"name":"SPI_FLASH_WARN_SETTING_ZERO_TO_ONE",
"range":null,
"title":"Log warning if writing zero bits to ones",
"help":"If this option is enabled, any time SPI flash is written then the data will be read\nback and verified. This can catch hardware problems with SPI flash, or flash which\nwas not erased before verification.",
"id":"SPI_FLASH_VERIFY_WRITE",
"name":"SPI_FLASH_VERIFY_WRITE",
"range":null,
"title":"Verify SPI flash writes",
"type":"bool"
},
{
"children":[],
"depends_on":null,
"help":"This option enables the following APIs:\n\n- spi_flash_reset_counters\n- spi_flash_dump_counters\n- spi_flash_get_counters\n\nThese APIs may be used to collect performance data for spi_flash APIs\nand to help understand behaviour of libraries which use SPI flash.",
"id":"SPI_FLASH_ENABLE_COUNTERS",
"name":"SPI_FLASH_ENABLE_COUNTERS",
"range":null,
"title":"Enable operation counters",
"type":"bool"
},
{
"children":[],
"depends_on":null,
"help":"Enable this flag to use patched versions of SPI flash ROM driver functions.\nThis option is needed to write to flash on ESP32-D2WD, and any configuration\nwhere external SPI flash is connected to non-default pins.",
"id":"SPI_FLASH_ROM_DRIVER_PATCH",
"name":"SPI_FLASH_ROM_DRIVER_PATCH",
"range":null,
"title":"Enable SPI flash ROM driver patched functions",
"help":"SPI flash APIs can optionally abort or return a failure code\nif erasing or writing addresses that fall at the beginning\nof flash (covering the bootloader and partition table) or that\noverlap the app partition that contains the running app.\n\nIt is not recommended to ever write to these regions from an IDF app,\nand this check prevents logic errors or corrupted firmware memory from\ndamaging these regions.\n\nNote that this feature *does not* check calls to the esp_rom_xxx SPI flash\nROM functions. These functions should not be called directly from IDF\napplications.",
"help":"Enable this to support auto detection of ISSI chips if chip vendor not directly\ngiven by ``chip_drv`` member of the chip struct. This adds support for variant\nchips, however will extend detecting time.",
"help":"Enable this to support auto detection of GD (GigaDevice) chips if chip vendor not\ndirectly given by ``chip_drv`` member of the chip struct. If you are using Wrover\nmodules, please don't disable this, otherwise your flash may not work in 4-bit\nmode.\n\nThis adds support for variant chips, however will extend detecting time and image\nsize. Note that the default chip driver supports the GD chips with product ID\n60H.",
"help":"Soc, esp32, and driver components, the most common\ncomponents. Some header of these components are included\nimplicitly by headers of other components before IDF v4.0.\nIt's not required for high-level components, but still\nincluded through long header chain everywhere.\n\nThis is harmful to the modularity. So it's changed in IDF\nv4.0.\n\nYou can still include these headers in a legacy way until it\nis totally deprecated by enable this option.",
"id":"LEGACY_INCLUDE_COMMON_HEADERS",
"name":"LEGACY_INCLUDE_COMMON_HEADERS",
"range":null,
"title":"Include headers across components as before IDF v4.0",
