menu "ESP32-specific" 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 config MEMMAP_SMP bool "Reserve memory for two cores" default "y" help The ESP32 contains two cores. If you plan to only use one, you can disable this item to save some memory. (ToDo: Make this automatically depend on unicore support) config MEMMAP_TRACEMEM bool default "n" config MEMMAP_TRACEMEM_TWOBANKS bool default "n" config ESP32_TRAX bool "Use TRAX tracing feature" default "n" select 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 && MEMMAP_SMP select 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 TRACEMEM_RESERVE_DRAM hex default 0x8000 if MEMMAP_TRACEMEM && MEMMAP_TRACEMEM_TWOBANKS default 0x4000 if MEMMAP_TRACEMEM && !MEMMAP_TRACEMEM_TWOBANKS default 0x0 choice ESP32_COREDUMP_TO_FLASH_OR_UART prompt "Core dump destination" default ESP32_ENABLE_COREDUMP_TO_NONE help Select place to store core dump: flash, uart or none (to disable core dumps generation). If core dump is configured to be stored in flash and custom partition table is used add corresponding entry to your CSV. For examples, please see predefined partition table CSV descriptions in the components/partition_table directory. config ESP32_ENABLE_COREDUMP_TO_FLASH bool "Flash" select ESP32_ENABLE_COREDUMP config ESP32_ENABLE_COREDUMP_TO_UART bool "UART" select ESP32_ENABLE_COREDUMP config ESP32_ENABLE_COREDUMP_TO_NONE bool "None" endchoice config ESP32_ENABLE_COREDUMP bool default F help Enables/disable core dump module. config ESP32_CORE_DUMP_UART_DELAY int "Core dump print to UART delay" depends on ESP32_ENABLE_COREDUMP_TO_UART default 0 help Config delay (in ms) before printing core dump to UART. Delay can be interrupted by pressing Enter key. config ESP32_CORE_DUMP_LOG_LEVEL int "Core dump module logging level" depends on ESP32_ENABLE_COREDUMP default 1 help Config core dump module logging level (0-5). choice ESP32_APPTRACE_DESTINATION prompt "AppTrace: destination" default ESP32_APPTRACE_DEST_NONE help Select destination for application trace: trace memory, uart or none (to disable). config ESP32_APPTRACE_DEST_TRAX bool "Trace memory" select ESP32_APPTRACE_ENABLE config ESP32_APPTRACE_DEST_UART bool "UART" select ESP32_APPTRACE_ENABLE config ESP32_APPTRACE_DEST_NONE bool "None" endchoice config ESP32_APPTRACE_ENABLE bool depends on !ESP32_TRAX select MEMMAP_TRACEMEM select MEMMAP_TRACEMEM_TWOBANKS default F help Enables/disable application tracing module. config ESP32_APPTRACE_ONPANIC_HOST_FLUSH_TMO int "AppTrace: Timeout for flushing last trace data to host on panic" depends on ESP32_APPTRACE_ENABLE default 4294967295 help Timeout for flushing last trace data to host in case of panic. In us. config ESP32_APPTRACE_ONPANIC_HOST_FLUSH_TRAX_THRESH int "AppTrace: Threshold for flushing last trace data to host on panic" depends on ESP32_APPTRACE_DEST_TRAX default 50 help Threshold for flushing last trace data to host on panic. In percents of TRAX memory block length. # Not implemented and/or needs new silicon rev to work config MEMMAP_SPISRAM bool "Use external SPI SRAM chip as main memory" depends on ESP32_NEEDS_NEW_SILICON_REV default "n" help The ESP32 can control an external SPI SRAM chip, adding the memory it contains to the main memory map. Enable this if you have this hardware and want to use it in the same way as on-chip RAM. choice BASE_MAC_ADDRESS_STORAGE prompt "Storage of the base MAC address" default BASE_MAC_STORED_DEFAULT_EFUSE help Select storage of the base MAC address which is used for all network interfaces when networking is initialized. If "Default place in EFUSE" is selected, esp32 will use the base MAC address which is written into default place in EFUSE when the chip is manufactured. If "Customer-defined place in EFUSE" is selected, ESP32 will use customer-defined base MAC address which is written into EFUSE Block 3 words 0, 1. If "Other customer-defined place" is selected, esp32 will use customer-defined base MAC address from other place(flash, EEPROM, etc). User code must call esp_base_mac_addr_set_external to set the base MAC address before network features are initialised. config BASE_MAC_STORED_DEFAULT_EFUSE bool "Default place in EFUSE" config BASE_MAC_STORED_CUSTOMER_DEFINED_EFUSE bool "Customer-defined place in EFUSE" config BASE_MAC_STORED_OTHER_CUSTOMER_DEFINED_PLACE bool "Other customer-defined place" endchoice choice NUMBER_OF_MAC_ADDRESS_GENERATED_FROM_EFUSE bool "Number of MAC address generated from the hardware MAC address in efuse" default FOUR_MAC_ADDRESS_FROM_EFUSE help Config the number of MAC address which is generated from the base MAC address in efuse. If the number is two, the MAC addresses of WiFi station and bluetooth are generated from the base MAC address in efuse. The MAC addresses of WiFi softap and ethernet are derived from that of WiFi station and bluetooth respectively. If the number is four, the MAC addresses of WiFi station, WiFi softap, bluetooth and ethernet are all generated from the base MAC address in efuse. config TWO_MAC_ADDRESS_FROM_EFUSE bool "Two" config FOUR_MAC_ADDRESS_FROM_EFUSE bool "Four" endchoice config NUMBER_OF_MAC_ADDRESS_GENERATED_FROM_EFUSE int default 2 if TWO_MAC_ADDRESS_FROM_EFUSE default 4 if FOUR_MAC_ADDRESS_FROM_EFUSE config SYSTEM_EVENT_QUEUE_SIZE int "System event queue size" default 32 help Config system event queue size in different application. config SYSTEM_EVENT_TASK_STACK_SIZE int "Event loop task stack size" default 4096 help Config system event task stack size in different application. config MAIN_TASK_STACK_SIZE int "Main task stack size" default 4096 help Config system event task stack size in different application. config NEWLIB_STDOUT_ADDCR bool "Standard-out output adds carriage return before newline" default y help Most people are used to end their printf strings with a newline. If this is sent as is to the serial port, most terminal programs will only move the cursor one line down, not also move it to the beginning of the line. This is usually done by an added CR character. Enabling this will make the standard output code automatically add a CR character before a LF. With this option enabled, C standard library functions which read from UART (like scanf) will convert "\r\n" character sequences back to "\n". This option doesn't affect behavior of the UART driver (drivers/uart.h). config NEWLIB_NANO_FORMAT bool "Enable 'nano' formatting options for printf/scanf family" default n help ESP32 ROM contains parts of newlib C library, including printf/scanf family of functions. These functions have been compiled with so-called "nano" formatting option. This option doesn't support 64-bit integer formats and C99 features, such as positional arguments. For more details about "nano" formatting option, please see newlib readme file, search for '--enable-newlib-nano-formatted-io': https://sourceware.org/newlib/README If this option is enabled, build system will use functions available in ROM, reducing the application binary size. Functions available in ROM run faster than functions which run from flash. Functions available in ROM can also run when flash instruction cache is disabled. If you need 64-bit integer formatting support or C99 features, keep this option disabled. choice CONSOLE_UART prompt "UART for console output" default CONSOLE_UART_DEFAULT help Select whether to use UART for console output (through stdout and stderr). - Default is to use UART0 on pins GPIO1(TX) and GPIO3(RX). - If "Custom" is selected, UART0 or UART1 can be chosen, and any pins can be selected. - If "None" is selected, there will be no console output on any UART, except for initial output from ROM bootloader. This output can be further suppressed by bootstrapping GPIO13 pin to low logic level. config CONSOLE_UART_DEFAULT bool "Default: UART0, TX=GPIO1, RX=GPIO3" config CONSOLE_UART_CUSTOM bool "Custom" config CONSOLE_UART_NONE bool "None" endchoice choice CONSOLE_UART_NUM prompt "UART peripheral to use for console output (0-1)" depends on CONSOLE_UART_CUSTOM default CONSOLE_UART_CUSTOM_NUM_0 help Due of a ROM bug, UART2 is not supported for console output via ets_printf. config CONSOLE_UART_CUSTOM_NUM_0 bool "UART0" config CONSOLE_UART_CUSTOM_NUM_1 bool "UART1" endchoice config CONSOLE_UART_NUM int default 0 if CONSOLE_UART_DEFAULT || CONSOLE_UART_NONE default 0 if CONSOLE_UART_CUSTOM_NUM_0 default 1 if CONSOLE_UART_CUSTOM_NUM_1 config CONSOLE_UART_TX_GPIO int "UART TX on GPIO#" depends on CONSOLE_UART_CUSTOM range 0 33 default 19 config CONSOLE_UART_RX_GPIO int "UART RX on GPIO#" depends on CONSOLE_UART_CUSTOM range 0 39 default 21 config CONSOLE_UART_BAUDRATE int "UART console baud rate" depends on !CONSOLE_UART_NONE default 115200 range 1200 4000000 config 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 ULP_COPROC_RESERVE_MEM int "RTC slow memory reserved for coprocessor" default 512 range 32 8192 depends on ULP_COPROC_ENABLED help Bytes of memory to reserve for ULP coprocessor firmware & data. Data is reserved at the beginning of RTC slow memory. # Set CONFIG_ULP_COPROC_RESERVE_MEM to 0 if ULP is disabled config ULP_COPROC_RESERVE_MEM int default 0 depends on !ULP_COPROC_ENABLED 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" 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 INT_WDT bool "Interrupt watchdog" default y help This watchdog timer can detect if the FreeRTOS tick interrupt has not been called for a certain time, either because a task turned off interrupts and did not turn them on for a long time, or because an interrupt handler did not return. It will try to invoke the panic handler first and failing that reset the SoC. config INT_WDT_TIMEOUT_MS int "Interrupt watchdog timeout (ms)" depends on INT_WDT default 300 range 10 10000 help The timeout of the watchdog, in miliseconds. Make this higher than the FreeRTOS tick rate. config INT_WDT_CHECK_CPU1 bool "Also watch CPU1 tick interrupt" depends on INT_WDT && !FREERTOS_UNICORE default y help Also detect if interrupts on CPU 1 are disabled for too long. config TASK_WDT bool "Task watchdog" default y help This watchdog timer can be used to make sure individual tasks are still running. config TASK_WDT_PANIC bool "Invoke panic handler when Task Watchdog is triggered" depends on TASK_WDT default n help Normally, the Task Watchdog will only print out a warning if it detects it has not been fed. If this is enabled, it will invoke the panic handler instead, which can then halt or reboot the chip. config TASK_WDT_TIMEOUT_S int "Task watchdog timeout (seconds)" depends on TASK_WDT range 1 60 default 5 help Timeout for the task WDT, in seconds. config TASK_WDT_CHECK_IDLE_TASK bool "Task watchdog watches CPU0 idle task" depends on TASK_WDT default y help With this turned on, the task WDT can detect if the idle task is not called within the task watchdog timeout period. The idle task not being called usually is a symptom of another task hoarding the CPU. It is also a bad thing because FreeRTOS household tasks depend on the idle task getting some runtime every now and then. Take Care: With this disabled, this watchdog will trigger if no tasks register themselves within the timeout value. config TASK_WDT_CHECK_IDLE_TASK_CPU1 bool "Task watchdog also watches CPU1 idle task" depends on TASK_WDT_CHECK_IDLE_TASK && !FREERTOS_UNICORE default y help Also check the idle task that runs on CPU1. #The brownout detector code is disabled (by making it depend on a nonexisting symbol) because the current revision of ESP32 #silicon has a bug in the brown-out detector, rendering it unusable for resetting the CPU. config BROWNOUT_DET bool "Hardware brownout detect & reset" default y depends on NEEDS_ESP32_NEW_SILICON_REV 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 BROWNOUT_DET_LVL_SEL prompt "Brownout voltage level" depends on BROWNOUT_DET default BROWNOUT_DET_LVL_SEL_25 help The brownout detector will reset the chip when the supply voltage is below this level. #The voltage levels here are estimates, more work needs to be done to figure out the exact voltages #of the brownout threshold levels. config BROWNOUT_DET_LVL_SEL_0 bool "2.1V" config BROWNOUT_DET_LVL_SEL_1 bool "2.2V" config BROWNOUT_DET_LVL_SEL_2 bool "2.3V" config BROWNOUT_DET_LVL_SEL_3 bool "2.4V" config BROWNOUT_DET_LVL_SEL_4 bool "2.5V" config BROWNOUT_DET_LVL_SEL_5 bool "2.6V" config BROWNOUT_DET_LVL_SEL_6 bool "2.7V" config BROWNOUT_DET_LVL_SEL_7 bool "2.8V" endchoice config BROWNOUT_DET_LVL int default 0 if BROWNOUT_DET_LVL_SEL_0 default 1 if BROWNOUT_DET_LVL_SEL_1 default 2 if BROWNOUT_DET_LVL_SEL_2 default 3 if BROWNOUT_DET_LVL_SEL_3 default 4 if BROWNOUT_DET_LVL_SEL_4 default 5 if BROWNOUT_DET_LVL_SEL_5 default 6 if BROWNOUT_DET_LVL_SEL_6 default 7 if BROWNOUT_DET_LVL_SEL_7 config BROWNOUT_DET_RESETDELAY int "Brownout reset delay (in uS)" depends on BROWNOUT_DET range 0 6820 default 1000 help The brownout detector can reset the chip after a certain delay, in order to make sure e.g. a voltage dip has entirely passed before trying to restart the chip. You can set the delay here. 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 only FRC1 timer is used, gettimeofday will provide time at microsecond resolution. Time will not be preserved when going into deep sleep mode. - If both FRC1 and RTC timers are used, timekeeping will continue in deep sleep. Time will be reported at 1 microsecond resolution. - 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 bool "RTC" config ESP32_TIME_SYSCALL_USE_RTC_FRC1 bool "RTC and FRC1" config ESP32_TIME_SYSCALL_USE_FRC1 bool "FRC1" config ESP32_TIME_SYSCALL_USE_NONE bool "None" endchoice choice ESP32_RTC_CLOCK_SOURCE prompt "RTC clock source" default ESP32_RTC_CLOCK_SOURCE_INTERNAL_RC help Choose which clock is used as RTC clock source. config ESP32_RTC_CLOCK_SOURCE_INTERNAL_RC bool "Internal 150kHz RC oscillator" config ESP32_RTC_CLOCK_SOURCE_EXTERNAL_CRYSTAL bool "External 32kHz crystal" endchoice config ESP32_RTC_CLK_CAL_CYCLES int "Number of cycles for RTC_SLOW_CLK calibration" default 1024 range 0 125000 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 - 32768 Hz if the 32k crystal oscillator is used config ESP32_DEEP_SLEEP_WAKEUP_DELAY int "Extra delay in deep sleep wake stub (in us)" default 0 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. If you are using a flash chip which needs more than 900us to become ready after power on, set this parameter to add extra delay to the default deep sleep stub. 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_AUTO 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 endmenu menuconfig WIFI_ENABLED bool "WiFi" default y help Select this option to enable WiFi stack and show the submenu with WiFi configuration choices. config SW_COEXIST_ENABLE bool "Software controls WiFi/Bluetooth coexistence" depends on WIFI_ENABLED && BT_ENABLED default n help If enabled, WiFi & Bluetooth coexistence is controlled by software rather than hardware. Recommended for heavy traffic scenarios. Both coexistence configuration options are automatically managed, no user intervention is required. config ESP32_WIFI_STATIC_RX_BUFFER_NUM int "Max number of WiFi static RX buffers" depends on WIFI_ENABLED range 2 25 default 10 help Set the number of WiFi static rx buffers. Each buffer takes approximately 1.6KB of RAM. The static rx buffers are allocated when esp_wifi_init is called, they are not freed until esp_wifi_deinit is called. WiFi hardware use these buffers to receive packets, generally larger number for higher throughput but more memory, smaller number for lower throughput but less memory. config ESP32_WIFI_DYNAMIC_RX_BUFFER_NUM int "Max number of WiFi dynamic RX buffers" depends on WIFI_ENABLED range 0 128 default 64 help Set the number of WiFi dynamic rx buffers, 0 means no limitation for dynamic rx buffer allocation. The size of dynamic rx buffers is not fixed. For each received packet in static rx buffers, WiFi driver makes a copy to dynamic rx buffers and then deliver it to high layer stack. The dynamic rx buffer is freed when the application, such as socket, successfully received the packet. For some applications, the WiFi driver receiving speed is faster than application consuming speed, we may run out of memory if no limitation for the dynamic rx buffer number. Generally the number of dynamic rx buffer should be no less than static rx buffer number if it is not 0. choice ESP32_WIFI_TX_BUFFER prompt "Type of WiFi TX buffers" depends on WIFI_ENABLED default ESP32_WIFI_DYNAMIC_TX_BUFFER help Select type of WiFi tx buffers and show the submenu with the number of WiFi tx buffers choice. If "STATIC" is selected, WiFi tx buffers are allocated when WiFi is initialized and released when WiFi is de-initialized. If "DYNAMIC" is selected, WiFi tx buffer is allocated when tx data is delivered from LWIP to WiFi and released when tx data is sent out by WiFi. The size of each static tx buffers is fixed to about 1.6KB and the size of dynamic tx buffers is depend on the length of the data delivered from LWIP. If PSRAM is enabled, "STATIC" should be selected to guarantee enough WiFi tx buffers. If PSRAM is disabled, "DYNAMIC" should be selected to improve the utilization of RAM. config ESP32_WIFI_STATIC_TX_BUFFER bool "STATIC" config ESP32_WIFI_DYNAMIC_TX_BUFFER bool "DYNAMIC" endchoice config ESP32_WIFI_TX_BUFFER_TYPE int depends on WIFI_ENABLED default 0 if ESP32_WIFI_STATIC_TX_BUFFER default 1 if ESP32_WIFI_DYNAMIC_TX_BUFFER config ESP32_WIFI_STATIC_TX_BUFFER_NUM int "Max number of WiFi static TX buffers" depends on WIFI_ENABLED depends on ESP32_WIFI_STATIC_TX_BUFFER range 16 64 default 32 help Set the number of WiFi static tx buffers. Each buffer takes approximately 1.6KB of RAM. The static rx buffers are allocated when esp_wifi_init is called, they are not released until esp_wifi_deinit is called. For each tx packet from high layer stack, WiFi driver make a copy of it. For some applications, especially the UDP application, the high layer deliver speed is faster than the WiFi tx speed, we may run out of static tx buffers. config ESP32_WIFI_DYNAMIC_TX_BUFFER_NUM int "Max number of WiFi dynamic TX buffers" depends on WIFI_ENABLED depends on ESP32_WIFI_DYNAMIC_TX_BUFFER range 16 64 default 32 help Set the number of WiFi dynamic tx buffers, 0 means no limitation for dynamic tx buffer allocation. The size of dynamic tx buffers is not fixed. For each tx packet from high layer stack, WiFi driver make a copy of it. For some applications, especially the UDP application, the high layer deliver speed is faster than the WiFi tx speed, we may run out of memory if no limitation for the dynamic tx buffer number. config ESP32_WIFI_AMPDU_ENABLED bool "WiFi AMPDU" depends on WIFI_ENABLED default y help Select this option to enable AMPDU feature config ESP32_WIFI_NVS_ENABLED bool "WiFi NVS flash" depends on WIFI_ENABLED default y help Select this option to enable WiFi NVS flash config PHY_ENABLED bool default y if WIFI_ENABLED || BT_ENABLED menu PHY visible if PHY_ENABLED config ESP32_PHY_CALIBRATION_AND_DATA_STORAGE bool "Do phy calibration and store calibration data in NVS" depends on PHY_ENABLED default y help If this option is enabled, NVS will be initialized and calibration data will be loaded from there. PHY calibration will be skipped on deep sleep wakeup. If calibration data is not found, full calibration will be performed and stored in NVS. In all other cases, only partial calibration will be performed. If unsure, choose 'y'. config ESP32_PHY_INIT_DATA_IN_PARTITION bool "Use a partition to store PHY init data" depends on PHY_ENABLED default n help If enabled, PHY init data will be loaded from a partition. When using a custom partition table, make sure that PHY data partition is included (type: 'data', subtype: 'phy'). With default partition tables, this is done automatically. If PHY init data is stored in a partition, it has to be flashed there, otherwise runtime error will occur. If this option is not enabled, PHY init data will be embedded into the application binary. If unsure, choose 'n'. config ESP32_PHY_MAX_WIFI_TX_POWER int "Max WiFi TX power (dBm)" range 0 20 default 20 depends on PHY_ENABLED && WIFI_ENABLED help Set maximum transmit power for WiFi radio. Actual transmit power for high data rates may be lower than this setting. config ESP32_PHY_MAX_TX_POWER int depends on PHY_ENABLED default 20 if !WIFI_ENABLED default ESP32_PHY_MAX_WIFI_TX_POWER if WIFI_ENABLED endmenu