esp-idf/components/esp32/Kconfig

menu "ESP32-specific"
    # TODO: this component simply shouldn't be included
    # in the build at the CMake level, but this is currently
    # not working so we just hide all items here
    visible if IDF_TARGET_ESP32

    choice ESP32_DEFAULT_CPU_FREQ_MHZ
        prompt "CPU frequency"
        default ESP32_DEFAULT_CPU_FREQ_160
        help
            CPU frequency to be set on application startup.

        config ESP32_DEFAULT_CPU_FREQ_80
            bool "80 MHz"
        config ESP32_DEFAULT_CPU_FREQ_160
            bool "160 MHz"
        config ESP32_DEFAULT_CPU_FREQ_240
            bool "240 MHz"
    endchoice

    config ESP32_DEFAULT_CPU_FREQ_MHZ
        int
        default 80 if ESP32_DEFAULT_CPU_FREQ_80
        default 160 if ESP32_DEFAULT_CPU_FREQ_160
        default 240 if ESP32_DEFAULT_CPU_FREQ_240

        # Note: to support SPIRAM across multiple chips, check CONFIG_SPIRAM
        # instead
    config ESP32_SPIRAM_SUPPORT
        bool "Support for external, SPI-connected RAM"
        default "n"
        select SPIRAM
        help
            This enables support for an external SPI RAM chip, connected in parallel with the
            main SPI flash chip.

    menu "SPI RAM config"
        depends on ESP32_SPIRAM_SUPPORT

        choice SPIRAM_TYPE
            prompt "Type of SPI RAM chip in use"
            default SPIRAM_TYPE_AUTO

            config SPIRAM_TYPE_AUTO
                bool "Auto-detect"

            config SPIRAM_TYPE_ESPPSRAM32
                bool "ESP-PSRAM32 or IS25WP032"

            config SPIRAM_TYPE_ESPPSRAM64
                bool "ESP-PSRAM64 or LY68L6400"

        endchoice

        config SPIRAM_SIZE
            int
            default -1 if SPIRAM_TYPE_AUTO
            default 4194304 if SPIRAM_TYPE_ESPPSRAM32
            default 8388608 if SPIRAM_TYPE_ESPPSRAM64
            default 0

        choice SPIRAM_SPEED
            prompt "Set RAM clock speed"
            default SPIRAM_CACHE_SPEED_40M
            help
                Select the speed for the SPI RAM chip.
                If SPI RAM is enabled, we only support three combinations of SPI speed mode we supported now:

                1. Flash SPI running at 40Mhz and RAM SPI running at 40Mhz
                2. Flash SPI running at 80Mhz and RAM SPI running at 40Mhz
                3. Flash SPI running at 80Mhz and RAM SPI running at 80Mhz

                Note: If the third mode(80Mhz+80Mhz) is enabled for SPI RAM of type 32MBit, one of the HSPI/VSPI host
                will be occupied by the system. Which SPI host to use can be selected by the config item
                SPIRAM_OCCUPY_SPI_HOST. Application code should never touch HSPI/VSPI hardware in this case. The
                option to select 80MHz will only be visible if the flash SPI speed is also 80MHz.
                (ESPTOOLPY_FLASHFREQ_80M is true)

            config SPIRAM_SPEED_40M
                bool "40MHz clock speed"
            config SPIRAM_SPEED_80M
                depends on ESPTOOLPY_FLASHFREQ_80M
                bool "80MHz clock speed"
        endchoice

        # insert non-chip-specific items here
        source "$IDF_PATH/components/esp_common/Kconfig.spiram.common"

        config SPIRAM_CACHE_WORKAROUND
            bool "Enable workaround for bug in SPI RAM cache for Rev1 ESP32s"
            depends on SPIRAM_USE_MEMMAP || SPIRAM_USE_CAPS_ALLOC || SPIRAM_USE_MALLOC
            default "y"
            help
                Revision 1 of the ESP32 has a bug that can cause a write to PSRAM not to take place in some situations
                when the cache line needs to be fetched from external RAM and an interrupt occurs. This enables a
                fix in the compiler (-mfix-esp32-psram-cache-issue) that makes sure the specific code that is
                vulnerable to this will not be emitted.

                This will also not use any bits of newlib that are located in ROM, opting for a version that is
                compiled with the workaround and located in flash instead.

        config SPIRAM_BANKSWITCH_ENABLE
            bool "Enable bank switching for >4MiB external RAM"
            default y
            depends on SPIRAM_USE_MEMMAP || SPIRAM_USE_CAPS_ALLOC || SPIRAM_USE_MALLOC
            help
                The ESP32 only supports 4MiB of external RAM in its address space. The hardware does support larger
                memories, but these have to be bank-switched in and out of this address space. Enabling this allows you
                to reserve some MMU pages for this, which allows the use of the esp_himem api to manage these banks.

                #Note that this is limited to 62 banks, as esp_spiram_writeback_cache needs some kind of mapping of
                #some banks below that mark to work. We cannot at this moment guarantee this to exist when himem is
                #enabled.
        config SPIRAM_BANKSWITCH_RESERVE
            int "Amount of 32K pages to reserve for bank switching"
            depends on SPIRAM_BANKSWITCH_ENABLE
            default 8
            range 1 62
            help
                Select the amount of banks reserved for bank switching. Note that the amount of RAM allocatable with
                malloc/esp_heap_alloc_caps will decrease by 32K for each page reserved here.

                Note that this reservation is only actually done if your program actually uses the himem API. Without
                any himem calls, the reservation is not done and the original amount of memory will be available
                to malloc/esp_heap_alloc_caps.

        config SPIRAM_ALLOW_STACK_EXTERNAL_MEMORY
            bool "Allow external memory as an argument to xTaskCreateStatic"
            default n
            depends on SPIRAM_USE_MALLOC
            help
                Because some bits of the ESP32 code environment cannot be recompiled with the cache workaround,
                normally tasks cannot be safely run with their stack residing in external memory; for this reason
                xTaskCreate and friends always allocate stack in internal memory and xTaskCreateStatic will check if
                the memory passed to it is in internal memory. If you have a task that needs a large amount of stack
                and does not call on ROM code in any way (no direct calls, but also no Bluetooth/WiFi), you can try to
                disable this and use xTaskCreateStatic to create the tasks stack in external memory.

        choice SPIRAM_OCCUPY_SPI_HOST
            prompt "SPI host to use for 32MBit PSRAM"
            default SPIRAM_OCCUPY_VSPI_HOST
            depends on SPIRAM_SPEED_80M
            help
                When both flash and PSRAM is working under 80MHz, and the PSRAM is of type 32MBit, one of the HSPI/VSPI
                host will be used to output the clock. Select which one to use here.

            config SPIRAM_OCCUPY_HSPI_HOST
                bool "HSPI host (SPI2)"
            config SPIRAM_OCCUPY_VSPI_HOST
                bool "VSPI host (SPI3)"
        endchoice

        menu "PSRAM clock and cs IO for ESP32-DOWD"

            config D0WD_PSRAM_CLK_IO
                int "PSRAM CLK IO number"
                depends on ESP32_SPIRAM_SUPPORT
                range 0 33
                default 17
                help
                    The PSRAM CLOCK IO can be any unused GPIO, user can config it based on hardware design. If user use
                    1.8V flash and 1.8V psram, this value can only be one of 6, 7, 8, 9, 10, 11, 16, 17.

            config D0WD_PSRAM_CS_IO
                int "PSRAM CS IO number"
                depends on ESP32_SPIRAM_SUPPORT
                range 0 33
                default 16
                help
                    The PSRAM CS IO can be any unused GPIO, user can config it based on hardware design. If user use
                    1.8V flash and 1.8V psram, this value can only be one of 6, 7, 8, 9, 10, 11, 16, 17.
        endmenu

        menu "PSRAM clock and cs IO for ESP32-D2WD"

            config D2WD_PSRAM_CLK_IO
                int "PSRAM CLK IO number"
                depends on ESP32_SPIRAM_SUPPORT
                range 0 33
                default 9
                help
                    User can config it based on hardware design. For ESP32-D2WD chip, the psram can only be 1.8V psram,
                    so this value can only be one of 6, 7, 8, 9, 10, 11, 16, 17.

            config D2WD_PSRAM_CS_IO
                int "PSRAM CS IO number"
                depends on ESP32_SPIRAM_SUPPORT
                range 0 33
                default 10
                help
                    User can config it based on hardware design. For ESP32-D2WD chip, the psram can only be 1.8V psram,
                    so this value can only be one of 6, 7, 8, 9, 10, 11, 16, 17.
        endmenu

        menu "PSRAM clock and cs IO for ESP32-PICO"

            config PICO_PSRAM_CS_IO
                int "PSRAM CS IO number"
                depends on ESP32_SPIRAM_SUPPORT
                range 0 33
                default 10
                help
                    The PSRAM CS IO can be any unused GPIO, user can config it based on hardware design.

                    For ESP32-PICO chip, the psram share clock with flash, so user do not need to configure the clock
                    IO.
                    For the reference hardware design, please refer to
                    https://www.espressif.com/sites/default/files/documentation/esp32-pico-d4_datasheet_en.pdf

        endmenu

        config SPIRAM_SPIWP_SD3_PIN
            int "SPI PSRAM WP(SD3) Pin when customising pins via eFuse (read help)"
            depends on ESPTOOLPY_FLASHMODE_DIO || ESPTOOLPY_FLASHMODE_DOUT
            range 0 33
            default 7
            help
                This value is ignored unless flash mode is set to DIO or DOUT and the SPI flash pins have been
                overriden by setting the eFuses SPI_PAD_CONFIG_xxx.

                When this is the case, the eFuse config only defines 3 of the 4 Quad I/O data pins. The WP pin (aka
                ESP32 pin "SD_DATA_3" or SPI flash pin "IO2") is not specified in eFuse. And the psram only has QPI
                mode, the WP pin is necessary, so we need to configure this value here.

                When flash mode is set to QIO or QOUT, the PSRAM WP pin will be set as the value configured in
                bootloader.

                For ESP32-PICO chip, the default value of this config should be 7.

    endmenu # "SPI RAM config"

    config ESP32_MEMMAP_TRACEMEM
        bool
        default "n"

    config ESP32_MEMMAP_TRACEMEM_TWOBANKS
        bool
        default "n"

    config ESP32_TRAX
        bool "Use TRAX tracing feature"
        default "n"
        select ESP32_MEMMAP_TRACEMEM
        help
            The ESP32 contains a feature which allows you to trace the execution path the processor
            has taken through the program. This is stored in a chunk of 32K (16K for single-processor)
            of memory that can't be used for general purposes anymore. Disable this if you do not know
            what this is.

    config ESP32_TRAX_TWOBANKS
        bool "Reserve memory for tracing both pro as well as app cpu execution"
        default "n"
        depends on ESP32_TRAX && !FREERTOS_UNICORE
        select ESP32_MEMMAP_TRACEMEM_TWOBANKS
        help
            The ESP32 contains a feature which allows you to trace the execution path the processor
            has taken through the program. This is stored in a chunk of 32K (16K for single-processor)
            of memory that can't be used for general purposes anymore. Disable this if you do not know
            what this is.

            # Memory to reverse for trace, used in linker script
    config ESP32_TRACEMEM_RESERVE_DRAM
        hex
        default 0x8000 if ESP32_MEMMAP_TRACEMEM && ESP32_MEMMAP_TRACEMEM_TWOBANKS
        default 0x4000 if ESP32_MEMMAP_TRACEMEM && !ESP32_MEMMAP_TRACEMEM_TWOBANKS
        default 0x0

    choice ESP32_UNIVERSAL_MAC_ADDRESSES
        bool "Number of universally administered (by IEEE) MAC address"
        default ESP32_UNIVERSAL_MAC_ADDRESSES_FOUR
        help
            Configure the number of universally administered (by IEEE) MAC addresses.
            During initialisation, MAC addresses for each network interface are generated or derived from a
            single base MAC address.
            If the number of universal MAC addresses is four, all four interfaces (WiFi station, WiFi softap,
            Bluetooth and Ethernet) receive a universally administered MAC address. These are generated
            sequentially by adding 0, 1, 2 and 3 (respectively) to the final octet of the base MAC address.
            If the number of universal MAC addresses is two, only two interfaces (WiFi station and Bluetooth)
            receive a universally administered MAC address. These are generated sequentially by adding 0
            and 1 (respectively) to the base MAC address. The remaining two interfaces (WiFi softap and Ethernet)
            receive local MAC addresses. These are derived from the universal WiFi station and Bluetooth MAC
            addresses, respectively.
            When using the default (Espressif-assigned) base MAC address, either setting can be used. When using
            a custom universal MAC address range, the correct setting will depend on the allocation of MAC
            addresses in this range (either 2 or 4 per device.)

        config ESP32_UNIVERSAL_MAC_ADDRESSES_TWO
            bool "Two"
        config ESP32_UNIVERSAL_MAC_ADDRESSES_FOUR
            bool "Four"
    endchoice

    config ESP32_UNIVERSAL_MAC_ADDRESSES
        int
        default 2 if ESP32_UNIVERSAL_MAC_ADDRESSES_TWO
        default 4 if ESP32_UNIVERSAL_MAC_ADDRESSES_FOUR


    config ESP32_ULP_COPROC_ENABLED
        bool "Enable Ultra Low Power (ULP) Coprocessor"
        default "n"
        help
            Set to 'y' if you plan to load a firmware for the coprocessor.

            If this option is enabled, further coprocessor configuration will appear in the Components menu.

    config ESP32_ULP_COPROC_RESERVE_MEM
        int
        prompt "RTC slow memory reserved for coprocessor" if ESP32_ULP_COPROC_ENABLED
        default 512 if ESP32_ULP_COPROC_ENABLED
        range 32 8192 if ESP32_ULP_COPROC_ENABLED
        default 0 if !ESP32_ULP_COPROC_ENABLED
        range 0 0 if !ESP32_ULP_COPROC_ENABLED
        help
            Bytes of memory to reserve for ULP coprocessor firmware & data.

            Data is reserved at the beginning of RTC slow memory.

    choice ESP32_PANIC
        prompt "Panic handler behaviour"
        default ESP32_PANIC_PRINT_REBOOT
        help
            If FreeRTOS detects unexpected behaviour or an unhandled exception, the panic handler is
            invoked. Configure the panic handlers action here.

        config ESP32_PANIC_PRINT_HALT
            bool "Print registers and halt"
            help
                Outputs the relevant registers over the serial port and halt the
                processor. Needs a manual reset to restart.

        config ESP32_PANIC_PRINT_REBOOT
            bool "Print registers and reboot"
            help
                Outputs the relevant registers over the serial port and immediately
                reset the processor.

        config ESP32_PANIC_SILENT_REBOOT
            bool "Silent reboot"
            help
                Just resets the processor without outputting anything

        config ESP32_PANIC_GDBSTUB
            bool "Invoke GDBStub"
            select ESP_GDBSTUB_ENABLED
            help
                Invoke gdbstub on the serial port, allowing for gdb to attach to it to do a postmortem
                of the crash.
    endchoice

    config ESP32_DEBUG_OCDAWARE
        bool "Make exception and panic handlers JTAG/OCD aware"
        default y
        help
            The FreeRTOS panic and unhandled exception handers can detect a JTAG OCD debugger and
            instead of panicking, have the debugger stop on the offending instruction.

    config ESP32_DEBUG_STUBS_ENABLE
        bool "OpenOCD debug stubs"
        default COMPILER_OPTIMIZATION_LEVEL_DEBUG
        depends on !ESP32_TRAX
        help
            Debug stubs are used by OpenOCD to execute pre-compiled onboard code which does some useful debugging,
            e.g. GCOV data dump.

    config ESP32_BROWNOUT_DET
        bool "Hardware brownout detect & reset"
        default y
        help
            The ESP32 has a built-in brownout detector which can detect if the voltage is lower than
            a specific value. If this happens, it will reset the chip in order to prevent unintended
            behaviour.

    choice ESP32_BROWNOUT_DET_LVL_SEL
        prompt "Brownout voltage level"
        depends on ESP32_BROWNOUT_DET
        default BROWNOUT_DET_LVL_SEL_25
        help
            The brownout detector will reset the chip when the supply voltage is approximately
            below this level. Note that there may be some variation of brownout voltage level
            between each ESP32 chip.

            #The voltage levels here are estimates, more work needs to be done to figure out the exact voltages
            #of the brownout threshold levels.
        config ESP32_BROWNOUT_DET_LVL_SEL_0
            bool "2.43V +/- 0.05"
        config ESP32_BROWNOUT_DET_LVL_SEL_1
            bool "2.48V +/- 0.05"
        config ESP32_BROWNOUT_DET_LVL_SEL_2
            bool "2.58V +/- 0.05"
        config ESP32_BROWNOUT_DET_LVL_SEL_3
            bool "2.62V +/- 0.05"
        config ESP32_BROWNOUT_DET_LVL_SEL_4
            bool "2.67V +/- 0.05"
        config ESP32_BROWNOUT_DET_LVL_SEL_5
            bool "2.70V +/- 0.05"
        config ESP32_BROWNOUT_DET_LVL_SEL_6
            bool "2.77V +/- 0.05"
        config ESP32_BROWNOUT_DET_LVL_SEL_7
            bool "2.80V +/- 0.05"
    endchoice

    config ESP32_BROWNOUT_DET_LVL
        int
        default 0 if ESP32_BROWNOUT_DET_LVL_SEL_0
        default 1 if ESP32_BROWNOUT_DET_LVL_SEL_1
        default 2 if ESP32_BROWNOUT_DET_LVL_SEL_2
        default 3 if ESP32_BROWNOUT_DET_LVL_SEL_3
        default 4 if ESP32_BROWNOUT_DET_LVL_SEL_4
        default 5 if ESP32_BROWNOUT_DET_LVL_SEL_5
        default 6 if ESP32_BROWNOUT_DET_LVL_SEL_6
        default 7 if ESP32_BROWNOUT_DET_LVL_SEL_7


        #Reduce PHY TX power when brownout reset
    config ESP32_REDUCE_PHY_TX_POWER
        bool "Reduce PHY TX power when brownout reset"
        depends on ESP32_BROWNOUT_DET
        default y
        help
            When brownout reset occurs, reduce PHY TX power to keep the code running

            # Note about the use of "FRC1" name: currently FRC1 timer is not used for
            # high resolution timekeeping anymore. Instead the esp_timer API, implemented
            # using FRC2 timer, is used.
            # FRC1 name in the option name is kept for compatibility.
    choice ESP32_TIME_SYSCALL
        prompt "Timers used for gettimeofday function"
        default ESP32_TIME_SYSCALL_USE_RTC_FRC1
        help
            This setting defines which hardware timers are used to
            implement 'gettimeofday' and 'time' functions in C library.

            - If both high-resolution and RTC timers are used, timekeeping will
              continue in deep sleep. Time will be reported at 1 microsecond
              resolution. This is the default, and the recommended option.
            - If only high-resolution timer is used, gettimeofday will
              provide time at microsecond resolution.
              Time will not be preserved when going into deep sleep mode.
            - If only RTC timer is used, timekeeping will continue in
              deep sleep, but time will be measured at 6.(6) microsecond
              resolution. Also the gettimeofday function itself may take
              longer to run.
            - If no timers are used, gettimeofday and time functions
              return -1 and set errno to ENOSYS.
            - When RTC is used for timekeeping, two RTC_STORE registers are
              used to keep time in deep sleep mode.

        config ESP32_TIME_SYSCALL_USE_RTC_FRC1
            bool "RTC and high-resolution timer"
        config ESP32_TIME_SYSCALL_USE_RTC
            bool "RTC"
        config ESP32_TIME_SYSCALL_USE_FRC1
            bool "High-resolution timer"
        config ESP32_TIME_SYSCALL_USE_NONE
            bool "None"
    endchoice

    choice ESP32_RTC_CLK_SRC
        prompt "RTC clock source"
        default ESP32_RTC_CLK_SRC_INT_RC
        help
            Choose which clock is used as RTC clock source.

            - "Internal 150kHz oscillator" option provides lowest deep sleep current
              consumption, and does not require extra external components. However
              frequency stability with respect to temperature is poor, so time may
              drift in deep/light sleep modes.
            - "External 32kHz crystal" provides better frequency stability, at the
              expense of slightly higher (1uA) deep sleep current consumption.
            - "External 32kHz oscillator" allows using 32kHz clock generated by an
              external circuit. In this case, external clock signal must be connected
              to 32K_XP pin. Amplitude should be <1.2V in case of sine wave signal,
              and <1V in case of square wave signal. Common mode voltage should be
              0.1 < Vcm < 0.5Vamp, where Vamp is the signal amplitude.
              Additionally, 1nF capacitor must be connected between 32K_XN pin and
              ground. 32K_XN pin can not be used as a GPIO in this case.
            - "Internal 8.5MHz oscillator divided by 256" option results in higher
              deep sleep current (by 5uA) but has better frequency stability than
              the internal 150kHz oscillator. It does not require external components.

        config ESP32_RTC_CLK_SRC_INT_RC
            bool "Internal 150kHz RC oscillator"
        config ESP32_RTC_CLK_SRC_EXT_CRYS
            bool "External 32kHz crystal"
        config ESP32_RTC_CLK_SRC_EXT_OSC
            bool "External 32kHz oscillator at 32K_XP pin"
        config ESP32_RTC_CLK_SRC_INT_8MD256
            bool "Internal 8.5MHz oscillator, divided by 256 (~33kHz)"
    endchoice

    config ESP32_RTC_EXT_CRYST_ADDIT_CURRENT
        bool "Additional current for external 32kHz crystal"
        depends on ESP32_RTC_CLK_SRC_EXT_CRYS
        default "n"
        help
            Choose which additional current is used for rtc external crystal.

            - With some 32kHz crystal configurations, the X32N and X32P pins may not
              have enough drive strength to keep the crystal oscillating during deep sleep.
              If this option is enabled, additional current from touchpad 9 is provided
              internally to drive the 32kHz crystal. If this option is enabled, deep sleep current
              is slightly higher (4-5uA) and the touchpad and ULP wakeup sources are not available.

    config ESP32_RTC_CLK_CAL_CYCLES
        int "Number of cycles for RTC_SLOW_CLK calibration"
        default 3000 if ESP32_RTC_CLK_SRC_EXT_CRYS
        default 1024 if ESP32_RTC_CLK_SRC_INT_RC
        range 0 27000 if ESP32_RTC_CLK_SRC_EXT_CRYS || ESP32_RTC_CLK_SRC_EXT_OSC || ESP32_RTC_CLK_SRC_INT_8MD256
        range 0 32766 if ESP32_RTC_CLK_SRC_INT_RC
        help
            When the startup code initializes RTC_SLOW_CLK, it can perform
            calibration by comparing the RTC_SLOW_CLK frequency with main XTAL
            frequency. This option sets the number of RTC_SLOW_CLK cycles measured
            by the calibration routine. Higher numbers increase calibration
            precision, which may be important for applications which spend a lot of
            time in deep sleep. Lower numbers reduce startup time.

            When this option is set to 0, clock calibration will not be performed at
            startup, and approximate clock frequencies will be assumed:

            - 150000 Hz if internal RC oscillator is used as clock source. For this use value 1024.
            - 32768 Hz if the 32k crystal oscillator is used. For this use value 3000 or more.
              In case more value will help improve the definition of the launch of the crystal.
              If the crystal could not start, it will be switched to internal RC.

    config ESP32_RTC_XTAL_BOOTSTRAP_CYCLES
        int "Bootstrap cycles for external 32kHz crystal"
        depends on ESP32_RTC_CLK_SRC_EXT_CRYS
        default 5
        range 0 32768
        help
            To reduce the startup time of an external RTC crystal,
            we bootstrap it with a 32kHz square wave for a fixed number of cycles.
            Setting 0 will disable bootstrapping (if disabled, the crystal may take
            longer to start up or fail to oscillate under some conditions).

            If this value is too high, a faulty crystal may initially start and then fail.
            If this value is too low, an otherwise good crystal may not start.

            To accurately determine if the crystal has started,
            set a larger "Number of cycles for RTC_SLOW_CLK calibration" (about 3000).

    config ESP32_DEEP_SLEEP_WAKEUP_DELAY
        int "Extra delay in deep sleep wake stub (in us)"
        default 2000
        range 0 5000
        help
            When ESP32 exits deep sleep, the CPU and the flash chip are powered on
            at the same time. CPU will run deep sleep stub first, and then
            proceed to load code from flash. Some flash chips need sufficient
            time to pass between power on and first read operation. By default,
            without any extra delay, this time is approximately 900us, although
            some flash chip types need more than that.

            By default extra delay is set to 2000us. When optimizing startup time
            for applications which require it, this value may be reduced.

            If you are seeing "flash read err, 1000" message printed to the
            console after deep sleep reset, try increasing this value.

    choice ESP32_XTAL_FREQ_SEL
        prompt "Main XTAL frequency"
        default ESP32_XTAL_FREQ_40
        help
            ESP32 currently supports the following XTAL frequencies:

            - 26 MHz
            - 40 MHz

            Startup code can automatically estimate XTAL frequency. This feature
            uses the internal 8MHz oscillator as a reference. Because the internal
            oscillator frequency is temperature dependent, it is not recommended
            to use automatic XTAL frequency detection in applications which need
            to work at high ambient temperatures and use high-temperature
            qualified chips and modules.
        config ESP32_XTAL_FREQ_40
            bool "40 MHz"
        config ESP32_XTAL_FREQ_26
            bool "26 MHz"
        config ESP32_XTAL_FREQ_AUTO
            bool "Autodetect"
    endchoice

    # Keep these values in sync with rtc_xtal_freq_t enum in soc/rtc.h
    config ESP32_XTAL_FREQ
        int
        default 0 if ESP32_XTAL_FREQ_AUTO
        default 40 if ESP32_XTAL_FREQ_40
        default 26 if ESP32_XTAL_FREQ_26

    config ESP32_DISABLE_BASIC_ROM_CONSOLE
        bool "Permanently disable BASIC ROM Console"
        default n
        help
            If set, the first time the app boots it will disable the BASIC ROM Console
            permanently (by burning an eFuse).

            Otherwise, the BASIC ROM Console starts on reset if no valid bootloader is
            read from the flash.

            (Enabling secure boot also disables the BASIC ROM Console by default.)

    config ESP32_NO_BLOBS
        bool "No Binary Blobs"
        depends on !BT_ENABLED
        default n
        help
            If enabled, this disables the linking of binary libraries in the application build. Note
            that after enabling this Wi-Fi/Bluetooth will not work.

    config ESP32_COMPATIBLE_PRE_V2_1_BOOTLOADERS
        bool "App compatible with bootloaders before IDF v2.1"
        default n
        help
            Bootloaders before IDF v2.1 did less initialisation of the
            system clock. This setting needs to be enabled to build an app
            which can be booted by these older bootloaders.

            If this setting is enabled, the app can be booted by any bootloader
            from IDF v1.0 up to the current version.

            If this setting is disabled, the app can only be booted by bootloaders
            from IDF v2.1 or newer.

            Enabling this setting adds approximately 1KB to the app's IRAM usage.

    config ESP32_RTCDATA_IN_FAST_MEM
        bool "Place RTC_DATA_ATTR and RTC_RODATA_ATTR variables into RTC fast memory segment"
        default n
        depends on FREERTOS_UNICORE
        help
            This option allows to place .rtc_data and .rtc_rodata sections into
            RTC fast memory segment to free the slow memory region for ULP programs.
            This option depends on the CONFIG_FREERTOS_UNICORE option because RTC fast memory
            can be accessed only by PRO_CPU core.

    config ESP32_USE_FIXED_STATIC_RAM_SIZE
        bool "Use fixed static RAM size"
        default n
        help
            If this option is disabled, the DRAM part of the heap starts right after the .bss section,
            within the dram0_0 region. As a result, adding or removing some static variables
            will change the available heap size.

            If this option is enabled, the DRAM part of the heap starts right after the dram0_0 region,
            where its length is set with ESP32_FIXED_STATIC_RAM_SIZE

    config ESP32_FIXED_STATIC_RAM_SIZE
        hex "Fixed Static RAM size"
        default 0x1E000
        range 0 0x2c200
        depends on ESP32_USE_FIXED_STATIC_RAM_SIZE
        help
            RAM size dedicated for static variables (.data & .bss sections).
            Please note that the actual length will be reduced by BT_RESERVE_DRAM if Bluetooth
            controller is enabled.

endmenu  # ESP32-Specific

menu "Power Management"
    # TODO: this component simply shouldn't be included
    # in the build at the CMake level, but this is currently
    # not working so we just hide all items here
    visible if IDF_TARGET_ESP32

    config PM_ENABLE
        bool "Support for power management"
        default n
        help
            If enabled, application is compiled with support for power management.
            This option has run-time overhead (increased interrupt latency,
            longer time to enter idle state), and it also reduces accuracy of
            RTOS ticks and timers used for timekeeping.
            Enable this option if application uses power management APIs.

    config PM_DFS_INIT_AUTO
        bool "Enable dynamic frequency scaling (DFS) at startup"
        depends on PM_ENABLE
        default n
        help
            If enabled, startup code configures dynamic frequency scaling.
            Max CPU frequency is set to CONFIG_ESP32_DEFAULT_CPU_FREQ_MHZ setting,
            min frequency is set to XTAL frequency.
            If disabled, DFS will not be active until the application
            configures it using esp_pm_configure function.

    config PM_USE_RTC_TIMER_REF
        bool "Use RTC timer to prevent time drift (EXPERIMENTAL)"
        depends on PM_ENABLE && (ESP32_TIME_SYSCALL_USE_RTC || ESP32_TIME_SYSCALL_USE_RTC_FRC1)
        default n
        help
            When APB clock frequency changes, high-resolution timer (esp_timer)
            scale and base value need to be adjusted. Each adjustment may cause
            small error, and over time such small errors may cause time drift.
            If this option is enabled, RTC timer will be used as a reference to
            compensate for the drift.
            It is recommended that this option is only used if 32k XTAL is selected
            as RTC clock source.

    config PM_PROFILING
        bool "Enable profiling counters for PM locks"
        depends on PM_ENABLE
        default n
        help
            If enabled, esp_pm_* functions will keep track of the amount of time
            each of the power management locks has been held, and esp_pm_dump_locks
            function will print this information.
            This feature can be used to analyze which locks are preventing the chip
            from going into a lower power state, and see what time the chip spends
            in each power saving mode. This feature does incur some run-time
            overhead, so should typically be disabled in production builds.

    config PM_TRACE
        bool "Enable debug tracing of PM using GPIOs"
        depends on PM_ENABLE
        default n
        help
            If enabled, some GPIOs will be used to signal events such as RTOS ticks,
            frequency switching, entry/exit from idle state. Refer to pm_trace.c
            file for the list of GPIOs.
            This feature is intended to be used when analyzing/debugging behavior
            of power management implementation, and should be kept disabled in
            applications.


endmenu # "Power Management"