3 # Hidden option to support checking for this specific target in C code and Kconfig files
4 config IDF_TARGET_ESP32
6 default "y" if IDF_TARGET="esp32"
9 choice ESP32_DEFAULT_CPU_FREQ_MHZ
10 prompt "CPU frequency"
11 default ESP32_DEFAULT_CPU_FREQ_160
13 CPU frequency to be set on application startup.
15 config ESP32_DEFAULT_CPU_FREQ_80
17 config ESP32_DEFAULT_CPU_FREQ_160
19 config ESP32_DEFAULT_CPU_FREQ_240
23 config ESP32_DEFAULT_CPU_FREQ_MHZ
25 default 80 if ESP32_DEFAULT_CPU_FREQ_80
26 default 160 if ESP32_DEFAULT_CPU_FREQ_160
27 default 240 if ESP32_DEFAULT_CPU_FREQ_240
30 bool "Support for external, SPI-connected RAM"
33 This enables support for an external SPI RAM chip, connected in parallel with the
37 depends on SPIRAM_SUPPORT
39 config SPIRAM_BOOT_INIT
40 bool "Initialize SPI RAM when booting the ESP32"
43 If this is enabled, the SPI RAM will be enabled during initial boot. Unless you
44 have specific requirements, you'll want to leave this enabled so memory allocated
45 during boot-up can also be placed in SPI RAM.
47 config SPIRAM_IGNORE_NOTFOUND
48 bool "Ignore PSRAM when not found"
50 depends on SPIRAM_BOOT_INIT && !SPIRAM_ALLOW_BSS_SEG_EXTERNAL_MEMORY
52 Normally, if psram initialization is enabled during compile time but not found at runtime, it
53 is seen as an error making the ESP32 panic. If this is enabled, the ESP32 will keep on
54 running but will not add the (non-existing) RAM to any allocator.
57 prompt "SPI RAM access method"
58 default SPIRAM_USE_MALLOC
60 The SPI RAM can be accessed in multiple methods: by just having it available as an unmanaged
61 memory region in the ESP32 memory map, by integrating it in the ESP32s heap as 'special' memory
62 needing heap_caps_malloc to allocate, or by fully integrating it making malloc() also able to
63 return SPI RAM pointers.
65 config SPIRAM_USE_MEMMAP
66 bool "Integrate RAM into ESP32 memory map"
67 config SPIRAM_USE_CAPS_ALLOC
68 bool "Make RAM allocatable using heap_caps_malloc(..., MALLOC_CAP_SPIRAM)"
69 config SPIRAM_USE_MALLOC
70 bool "Make RAM allocatable using malloc() as well"
71 select SUPPORT_STATIC_ALLOCATION
75 prompt "Type of SPI RAM chip in use"
76 default SPIRAM_TYPE_AUTO
78 config SPIRAM_TYPE_AUTO
81 config SPIRAM_TYPE_ESPPSRAM32
82 bool "ESP-PSRAM32 or IS25WP032"
84 config SPIRAM_TYPE_ESPPSRAM64
85 bool "ESP-PSRAM64 or LY68L6400"
91 default -1 if SPIRAM_TYPE_AUTO
92 default 4194304 if SPIRAM_TYPE_ESPPSRAM32
93 default 8388608 if SPIRAM_TYPE_ESPPSRAM64
97 prompt "Set RAM clock speed"
98 default SPIRAM_CACHE_SPEED_40M
100 Select the speed for the SPI RAM chip.
101 If SPI RAM is enabled, we only support three combinations of SPI speed mode we supported now:
103 1. Flash SPI running at 40Mhz and RAM SPI running at 40Mhz
104 2. Flash SPI running at 80Mhz and RAM SPI running at 40Mhz
105 3. Flash SPI running at 80Mhz and RAM SPI running at 80Mhz
107 Note: If the third mode(80Mhz+80Mhz) is enabled for SPI RAM of type 32MBit, one of the HSPI/VSPI host
108 will be occupied by the system. Which SPI host to use can be selected by the config item
109 SPIRAM_OCCUPY_SPI_HOST. Application code should never touch HSPI/VSPI hardware in this case. The
110 option to select 80MHz will only be visible if the flash SPI speed is also 80MHz.
111 (ESPTOOLPY_FLASHFREQ_80M is true)
113 config SPIRAM_SPEED_40M
114 bool "40MHz clock speed"
115 config SPIRAM_SPEED_80M
116 depends on ESPTOOLPY_FLASHFREQ_80M
117 bool "80MHz clock speed"
120 config SPIRAM_MEMTEST
121 bool "Run memory test on SPI RAM initialization"
123 depends on SPIRAM_BOOT_INIT
125 Runs a rudimentary memory test on initialization. Aborts when memory test fails. Disable this for
126 slightly faster startop.
128 config SPIRAM_CACHE_WORKAROUND
129 bool "Enable workaround for bug in SPI RAM cache for Rev1 ESP32s"
130 depends on SPIRAM_USE_MEMMAP || SPIRAM_USE_CAPS_ALLOC || SPIRAM_USE_MALLOC
133 Revision 1 of the ESP32 has a bug that can cause a write to PSRAM not to take place in some situations
134 when the cache line needs to be fetched from external RAM and an interrupt occurs. This enables a
135 fix in the compiler that makes sure the specific code that is vulnerable to this will not be emitted.
137 This will also not use any bits of newlib that are located in ROM, opting for a version that is
138 compiled with the workaround and located in flash instead.
140 config SPIRAM_BANKSWITCH_ENABLE
141 bool "Enable bank switching for >4MiB external RAM"
143 depends on SPIRAM_USE_MEMMAP || SPIRAM_USE_CAPS_ALLOC || SPIRAM_USE_MALLOC
145 The ESP32 only supports 4MiB of external RAM in its address space. The hardware does support larger
146 memories, but these have to be bank-switched in and out of this address space. Enabling this allows you
147 to reserve some MMU pages for this, which allows the use of the esp_himem api to manage these banks.
149 #Note that this is limited to 62 banks, as esp_spiram_writeback_cache needs some kind of mapping of
150 #some banks below that mark to work. We cannot at this moment guarantee this to exist when himem is
152 config SPIRAM_BANKSWITCH_RESERVE
153 int "Amount of 32K pages to reserve for bank switching"
154 depends on SPIRAM_BANKSWITCH_ENABLE
158 Select the amount of banks reserved for bank switching. Note that the amount of RAM allocatable with
159 malloc/esp_heap_alloc_caps will decrease by 32K for each page reserved here.
161 Note that this reservation is only actually done if your program actually uses the himem API. Without
162 any himem calls, the reservation is not done and the original amount of memory will be available
163 to malloc/esp_heap_alloc_caps.
165 config SPIRAM_MALLOC_ALWAYSINTERNAL
166 int "Maximum malloc() size, in bytes, to always put in internal memory"
167 depends on SPIRAM_USE_MALLOC
171 If malloc() is capable of also allocating SPI-connected ram, its allocation strategy will prefer to
172 allocate chunks less than this size in internal memory, while allocations larger than this will be
173 done from external RAM. If allocation from the preferred region fails, an attempt is made to allocate
174 from the non-preferred region instead, so malloc() will not suddenly fail when either internal or
175 external memory is full.
177 config WIFI_LWIP_ALLOCATION_FROM_SPIRAM_FIRST
178 bool "Try to allocate memories of WiFi and LWIP in SPIRAM firstly. If failed, allocate internal memory"
179 depends on SPIRAM_USE_CAPS_ALLOC || SPIRAM_USE_MALLOC
182 Try to allocate memories of WiFi and LWIP in SPIRAM firstly. If failed, try to allocate internal
185 config SPIRAM_MALLOC_RESERVE_INTERNAL
186 int "Reserve this amount of bytes for data that specifically needs to be in DMA or internal memory"
187 depends on SPIRAM_USE_MALLOC
191 Because the external/internal RAM allocation strategy is not always perfect, it sometimes may happen
192 that the internal memory is entirely filled up. This causes allocations that are specifically done in
193 internal memory, for example the stack for new tasks or memory to service DMA or have memory that's
194 also available when SPI cache is down, to fail. This option reserves a pool specifically for requests
195 like that; the memory in this pool is not given out when a normal malloc() is called.
197 Set this to 0 to disable this feature.
199 Note that because FreeRTOS stacks are forced to internal memory, they will also use this memory pool;
200 be sure to keep this in mind when adjusting this value.
202 Note also that the DMA reserved pool may not be one single contiguous memory region, depending on the
203 configured size and the static memory usage of the app.
206 config SPIRAM_ALLOW_STACK_EXTERNAL_MEMORY
207 bool "Allow external memory as an argument to xTaskCreateStatic"
209 depends on SPIRAM_USE_MALLOC
211 Because some bits of the ESP32 code environment cannot be recompiled with the cache workaround,
212 normally tasks cannot be safely run with their stack residing in external memory; for this reason
213 xTaskCreate and friends always allocate stack in internal memory and xTaskCreateStatic will check if
214 the memory passed to it is in internal memory. If you have a task that needs a large amount of stack
215 and does not call on ROM code in any way (no direct calls, but also no Bluetooth/WiFi), you can try to
216 disable this and use xTaskCreateStatic to create the tasks stack in external memory.
218 config SPIRAM_ALLOW_BSS_SEG_EXTERNAL_MEMORY
219 bool "Allow .bss segment placed in external memory"
221 depends on SPIRAM_SUPPORT
223 If enabled the option,and add EXT_RAM_ATTR defined your variable,then your variable will be placed in
224 PSRAM instead of internal memory, and placed most of variables of lwip,net802.11,pp,bluedroid library
225 to external memory defaultly.
227 choice SPIRAM_OCCUPY_SPI_HOST
228 prompt "SPI host to use for 32MBit PSRAM"
229 default SPIRAM_OCCUPY_VSPI_HOST
230 depends on SPIRAM_SPEED_80M
232 When both flash and PSRAM is working under 80MHz, and the PSRAM is of type 32MBit, one of the HSPI/VSPI
233 host will be used to output the clock. Select which one to use here.
235 config SPIRAM_OCCUPY_HSPI_HOST
236 bool "HSPI host (SPI2)"
237 config SPIRAM_OCCUPY_VSPI_HOST
238 bool "VSPI host (SPI3)"
241 config PICO_PSRAM_CS_IO
242 int "PSRAM CS IO for ESP32-PICO chip"
243 depends on SPIRAM_SUPPORT
247 When ESP32-PICO chip connect a external psram, the clock IO and data IO is fixed, but the CS IO can be
248 any unused GPIO, user can config it based on hardware design.
252 config MEMMAP_TRACEMEM
256 config MEMMAP_TRACEMEM_TWOBANKS
261 bool "Use TRAX tracing feature"
263 select MEMMAP_TRACEMEM
265 The ESP32 contains a feature which allows you to trace the execution path the processor
266 has taken through the program. This is stored in a chunk of 32K (16K for single-processor)
267 of memory that can't be used for general purposes anymore. Disable this if you do not know
270 config ESP32_TRAX_TWOBANKS
271 bool "Reserve memory for tracing both pro as well as app cpu execution"
273 depends on ESP32_TRAX && !FREERTOS_UNICORE
274 select MEMMAP_TRACEMEM_TWOBANKS
276 The ESP32 contains a feature which allows you to trace the execution path the processor
277 has taken through the program. This is stored in a chunk of 32K (16K for single-processor)
278 of memory that can't be used for general purposes anymore. Disable this if you do not know
281 # Memory to reverse for trace, used in linker script
282 config TRACEMEM_RESERVE_DRAM
284 default 0x8000 if MEMMAP_TRACEMEM && MEMMAP_TRACEMEM_TWOBANKS
285 default 0x4000 if MEMMAP_TRACEMEM && !MEMMAP_TRACEMEM_TWOBANKS
288 choice NUMBER_OF_UNIVERSAL_MAC_ADDRESS
289 bool "Number of universally administered (by IEEE) MAC address"
290 default FOUR_UNIVERSAL_MAC_ADDRESS
292 Configure the number of universally administered (by IEEE) MAC addresses.
293 During initialisation, MAC addresses for each network interface are generated or derived from a
294 single base MAC address.
295 If the number of universal MAC addresses is four, all four interfaces (WiFi station, WiFi softap,
296 Bluetooth and Ethernet) receive a universally administered MAC address. These are generated
297 sequentially by adding 0, 1, 2 and 3 (respectively) to the final octet of the base MAC address.
298 If the number of universal MAC addresses is two, only two interfaces (WiFi station and Bluetooth)
299 receive a universally administered MAC address. These are generated sequentially by adding 0
300 and 1 (respectively) to the base MAC address. The remaining two interfaces (WiFi softap and Ethernet)
301 receive local MAC addresses. These are derived from the universal WiFi station and Bluetooth MAC
302 addresses, respectively.
303 When using the default (Espressif-assigned) base MAC address, either setting can be used. When using
304 a custom universal MAC address range, the correct setting will depend on the allocation of MAC
305 addresses in this range (either 2 or 4 per device.)
307 config TWO_UNIVERSAL_MAC_ADDRESS
309 config FOUR_UNIVERSAL_MAC_ADDRESS
313 config NUMBER_OF_UNIVERSAL_MAC_ADDRESS
315 default 2 if TWO_UNIVERSAL_MAC_ADDRESS
316 default 4 if FOUR_UNIVERSAL_MAC_ADDRESS
318 config SYSTEM_EVENT_QUEUE_SIZE
319 int "System event queue size"
322 Config system event queue size in different application.
324 config SYSTEM_EVENT_TASK_STACK_SIZE
325 int "Event loop task stack size"
328 Config system event task stack size in different application.
330 config MAIN_TASK_STACK_SIZE
331 int "Main task stack size"
334 Configure the "main task" stack size. This is the stack of the task
335 which calls app_main(). If app_main() returns then this task is deleted
336 and its stack memory is freed.
338 config IPC_TASK_STACK_SIZE
339 int "Inter-Processor Call (IPC) task stack size"
341 range 512 65536 if !ESP32_APPTRACE_ENABLE
342 range 2048 65536 if ESP32_APPTRACE_ENABLE
344 Configure the IPC tasks stack size. One IPC task runs on each core
345 (in dual core mode), and allows for cross-core function calls.
347 See IPC documentation for more details.
349 The default stack size should be enough for most common use cases.
350 It can be shrunk if you are sure that you do not use any custom
353 config TIMER_TASK_STACK_SIZE
354 int "High-resolution timer task stack size"
358 Configure the stack size of esp_timer/ets_timer task. This task is used
359 to dispatch callbacks of timers created using ets_timer and esp_timer
360 APIs. If you are seing stack overflow errors in timer task, increase
363 Note that this is not the same as FreeRTOS timer task. To configure
364 FreeRTOS timer task size, see "FreeRTOS timer task stack size" option
367 choice NEWLIB_STDOUT_LINE_ENDING
368 prompt "Line ending for UART output"
369 default NEWLIB_STDOUT_LINE_ENDING_CRLF
371 This option allows configuring the desired line endings sent to UART
372 when a newline ('\n', LF) appears on stdout.
373 Three options are possible:
375 CRLF: whenever LF is encountered, prepend it with CR
377 LF: no modification is applied, stdout is sent as is
379 CR: each occurence of LF is replaced with CR
381 This option doesn't affect behavior of the UART driver (drivers/uart.h).
383 config NEWLIB_STDOUT_LINE_ENDING_CRLF
385 config NEWLIB_STDOUT_LINE_ENDING_LF
387 config NEWLIB_STDOUT_LINE_ENDING_CR
391 choice NEWLIB_STDIN_LINE_ENDING
392 prompt "Line ending for UART input"
393 default NEWLIB_STDIN_LINE_ENDING_CR
395 This option allows configuring which input sequence on UART produces
396 a newline ('\n', LF) on stdin.
397 Three options are possible:
399 CRLF: CRLF is converted to LF
401 LF: no modification is applied, input is sent to stdin as is
403 CR: each occurence of CR is replaced with LF
405 This option doesn't affect behavior of the UART driver (drivers/uart.h).
407 config NEWLIB_STDIN_LINE_ENDING_CRLF
409 config NEWLIB_STDIN_LINE_ENDING_LF
411 config NEWLIB_STDIN_LINE_ENDING_CR
415 config NEWLIB_NANO_FORMAT
416 bool "Enable 'nano' formatting options for printf/scanf family"
419 ESP32 ROM contains parts of newlib C library, including printf/scanf family
420 of functions. These functions have been compiled with so-called "nano"
421 formatting option. This option doesn't support 64-bit integer formats and C99
422 features, such as positional arguments.
424 For more details about "nano" formatting option, please see newlib readme file,
425 search for '--enable-newlib-nano-formatted-io':
426 https://sourceware.org/newlib/README
428 If this option is enabled, build system will use functions available in
429 ROM, reducing the application binary size. Functions available in ROM run
430 faster than functions which run from flash. Functions available in ROM can
431 also run when flash instruction cache is disabled.
433 If you need 64-bit integer formatting support or C99 features, keep this
437 prompt "UART for console output"
438 default CONSOLE_UART_DEFAULT
440 Select whether to use UART for console output (through stdout and stderr).
442 - Default is to use UART0 on pins GPIO1(TX) and GPIO3(RX).
443 - If "Custom" is selected, UART0 or UART1 can be chosen,
444 and any pins can be selected.
445 - If "None" is selected, there will be no console output on any UART, except
446 for initial output from ROM bootloader. This output can be further suppressed by
447 bootstrapping GPIO13 pin to low logic level.
449 config CONSOLE_UART_DEFAULT
450 bool "Default: UART0, TX=GPIO1, RX=GPIO3"
451 config CONSOLE_UART_CUSTOM
453 config CONSOLE_UART_NONE
457 choice CONSOLE_UART_NUM
458 prompt "UART peripheral to use for console output (0-1)"
459 depends on CONSOLE_UART_CUSTOM
460 default CONSOLE_UART_CUSTOM_NUM_0
462 Due of a ROM bug, UART2 is not supported for console output
465 config CONSOLE_UART_CUSTOM_NUM_0
467 config CONSOLE_UART_CUSTOM_NUM_1
471 config CONSOLE_UART_NUM
473 default 0 if CONSOLE_UART_DEFAULT || CONSOLE_UART_NONE
474 default 0 if CONSOLE_UART_CUSTOM_NUM_0
475 default 1 if CONSOLE_UART_CUSTOM_NUM_1
477 config CONSOLE_UART_TX_GPIO
478 int "UART TX on GPIO#"
479 depends on CONSOLE_UART_CUSTOM
483 config CONSOLE_UART_RX_GPIO
484 int "UART RX on GPIO#"
485 depends on CONSOLE_UART_CUSTOM
489 config CONSOLE_UART_BAUDRATE
490 int "UART console baud rate"
491 depends on !CONSOLE_UART_NONE
495 config ULP_COPROC_ENABLED
496 bool "Enable Ultra Low Power (ULP) Coprocessor"
499 Set to 'y' if you plan to load a firmware for the coprocessor.
501 If this option is enabled, further coprocessor configuration will appear in the Components menu.
503 config ULP_COPROC_RESERVE_MEM
505 prompt "RTC slow memory reserved for coprocessor" if ULP_COPROC_ENABLED
506 default 512 if ULP_COPROC_ENABLED
507 range 32 8192 if ULP_COPROC_ENABLED
508 default 0 if !ULP_COPROC_ENABLED
509 range 0 0 if !ULP_COPROC_ENABLED
511 Bytes of memory to reserve for ULP coprocessor firmware & data.
513 Data is reserved at the beginning of RTC slow memory.
516 prompt "Panic handler behaviour"
517 default ESP32_PANIC_PRINT_REBOOT
519 If FreeRTOS detects unexpected behaviour or an unhandled exception, the panic handler is
520 invoked. Configure the panic handlers action here.
522 config ESP32_PANIC_PRINT_HALT
523 bool "Print registers and halt"
525 Outputs the relevant registers over the serial port and halt the
526 processor. Needs a manual reset to restart.
528 config ESP32_PANIC_PRINT_REBOOT
529 bool "Print registers and reboot"
531 Outputs the relevant registers over the serial port and immediately
534 config ESP32_PANIC_SILENT_REBOOT
537 Just resets the processor without outputting anything
539 config ESP32_PANIC_GDBSTUB
540 bool "Invoke GDBStub"
542 Invoke gdbstub on the serial port, allowing for gdb to attach to it to do a postmortem
546 config ESP32_DEBUG_OCDAWARE
547 bool "Make exception and panic handlers JTAG/OCD aware"
550 The FreeRTOS panic and unhandled exception handers can detect a JTAG OCD debugger and
551 instead of panicking, have the debugger stop on the offending instruction.
553 config ESP32_DEBUG_STUBS_ENABLE
554 bool "OpenOCD debug stubs"
555 default OPTIMIZATION_LEVEL_DEBUG
556 depends on !ESP32_TRAX
558 Debug stubs are used by OpenOCD to execute pre-compiled onboard code which does some useful debugging,
562 bool "Interrupt watchdog"
565 This watchdog timer can detect if the FreeRTOS tick interrupt has not been called for a certain time,
566 either because a task turned off interrupts and did not turn them on for a long time, or because an
567 interrupt handler did not return. It will try to invoke the panic handler first and failing that
570 config INT_WDT_TIMEOUT_MS
571 int "Interrupt watchdog timeout (ms)"
573 default 300 if !SPIRAM_SUPPORT
574 default 800 if SPIRAM_SUPPORT
577 The timeout of the watchdog, in miliseconds. Make this higher than the FreeRTOS tick rate.
579 config INT_WDT_CHECK_CPU1
580 bool "Also watch CPU1 tick interrupt"
581 depends on INT_WDT && !FREERTOS_UNICORE
584 Also detect if interrupts on CPU 1 are disabled for too long.
587 bool "Initialize Task Watchdog Timer on startup"
590 The Task Watchdog Timer can be used to make sure individual tasks are still
591 running. Enabling this option will cause the Task Watchdog Timer to be
592 initialized automatically at startup. The Task Watchdog timer can be
593 initialized after startup as well (see Task Watchdog Timer API Reference)
595 config TASK_WDT_PANIC
596 bool "Invoke panic handler on Task Watchdog timeout"
600 If this option is enabled, the Task Watchdog Timer will be configured to
601 trigger the panic handler when it times out. This can also be configured
602 at run time (see Task Watchdog Timer API Reference)
604 config TASK_WDT_TIMEOUT_S
605 int "Task Watchdog timeout period (seconds)"
610 Timeout period configuration for the Task Watchdog Timer in seconds.
611 This is also configurable at run time (see Task Watchdog Timer API Reference)
613 config TASK_WDT_CHECK_IDLE_TASK_CPU0
614 bool "Watch CPU0 Idle Task"
618 If this option is enabled, the Task Watchdog Timer will watch the CPU0
619 Idle Task. Having the Task Watchdog watch the Idle Task allows for detection
620 of CPU starvation as the Idle Task not being called is usually a symptom of
621 CPU starvation. Starvation of the Idle Task is detrimental as FreeRTOS household
622 tasks depend on the Idle Task getting some runtime every now and then.
624 config TASK_WDT_CHECK_IDLE_TASK_CPU1
625 bool "Watch CPU1 Idle Task"
626 depends on TASK_WDT && !FREERTOS_UNICORE
629 If this option is enabled, the Task Wtachdog Timer will wach the CPU1
633 #The brownout detector code is disabled (by making it depend on a nonexisting symbol) because the current
634 #revision of ESP32 silicon has a bug in the brown-out detector, rendering it unusable for resetting the CPU.
635 bool "Hardware brownout detect & reset"
638 The ESP32 has a built-in brownout detector which can detect if the voltage is lower than
639 a specific value. If this happens, it will reset the chip in order to prevent unintended
642 choice BROWNOUT_DET_LVL_SEL
643 prompt "Brownout voltage level"
644 depends on BROWNOUT_DET
645 default BROWNOUT_DET_LVL_SEL_25
647 The brownout detector will reset the chip when the supply voltage is approximately
648 below this level. Note that there may be some variation of brownout voltage level
649 between each ESP32 chip.
651 #The voltage levels here are estimates, more work needs to be done to figure out the exact voltages
652 #of the brownout threshold levels.
653 config BROWNOUT_DET_LVL_SEL_0
654 bool "2.43V +/- 0.05"
655 config BROWNOUT_DET_LVL_SEL_1
656 bool "2.48V +/- 0.05"
657 config BROWNOUT_DET_LVL_SEL_2
658 bool "2.58V +/- 0.05"
659 config BROWNOUT_DET_LVL_SEL_3
660 bool "2.62V +/- 0.05"
661 config BROWNOUT_DET_LVL_SEL_4
662 bool "2.67V +/- 0.05"
663 config BROWNOUT_DET_LVL_SEL_5
664 bool "2.70V +/- 0.05"
665 config BROWNOUT_DET_LVL_SEL_6
666 bool "2.77V +/- 0.05"
667 config BROWNOUT_DET_LVL_SEL_7
668 bool "2.80V +/- 0.05"
671 config BROWNOUT_DET_LVL
673 default 0 if BROWNOUT_DET_LVL_SEL_0
674 default 1 if BROWNOUT_DET_LVL_SEL_1
675 default 2 if BROWNOUT_DET_LVL_SEL_2
676 default 3 if BROWNOUT_DET_LVL_SEL_3
677 default 4 if BROWNOUT_DET_LVL_SEL_4
678 default 5 if BROWNOUT_DET_LVL_SEL_5
679 default 6 if BROWNOUT_DET_LVL_SEL_6
680 default 7 if BROWNOUT_DET_LVL_SEL_7
683 #Reduce PHY TX power when brownout reset
684 config REDUCE_PHY_TX_POWER
685 bool "Reduce PHY TX power when brownout reset"
686 depends on BROWNOUT_DET
689 When brownout reset occurs, reduce PHY TX power to keep the code running
691 # Note about the use of "FRC1" name: currently FRC1 timer is not used for
692 # high resolution timekeeping anymore. Instead the esp_timer API, implemented
693 # using FRC2 timer, is used.
694 # FRC1 name in the option name is kept for compatibility.
695 choice ESP32_TIME_SYSCALL
696 prompt "Timers used for gettimeofday function"
697 default ESP32_TIME_SYSCALL_USE_RTC_FRC1
699 This setting defines which hardware timers are used to
700 implement 'gettimeofday' and 'time' functions in C library.
702 - If both high-resolution and RTC timers are used, timekeeping will
703 continue in deep sleep. Time will be reported at 1 microsecond
704 resolution. This is the default, and the recommended option.
705 - If only high-resolution timer is used, gettimeofday will
706 provide time at microsecond resolution.
707 Time will not be preserved when going into deep sleep mode.
708 - If only RTC timer is used, timekeeping will continue in
709 deep sleep, but time will be measured at 6.(6) microsecond
710 resolution. Also the gettimeofday function itself may take
712 - If no timers are used, gettimeofday and time functions
713 return -1 and set errno to ENOSYS.
714 - When RTC is used for timekeeping, two RTC_STORE registers are
715 used to keep time in deep sleep mode.
717 config ESP32_TIME_SYSCALL_USE_RTC_FRC1
718 bool "RTC and high-resolution timer"
719 config ESP32_TIME_SYSCALL_USE_RTC
721 config ESP32_TIME_SYSCALL_USE_FRC1
722 bool "High-resolution timer"
723 config ESP32_TIME_SYSCALL_USE_NONE
727 choice ESP32_RTC_CLOCK_SOURCE
728 prompt "RTC clock source"
729 default ESP32_RTC_CLOCK_SOURCE_INTERNAL_RC
731 Choose which clock is used as RTC clock source.
733 - "Internal 150kHz oscillator" option provides lowest deep sleep current
734 consumption, and does not require extra external components. However
735 frequency stability with respect to temperature is poor, so time may
736 drift in deep/light sleep modes.
737 - "External 32kHz crystal" provides better frequency stability, at the
738 expense of slightly higher (1uA) deep sleep current consumption.
739 - "External 32kHz oscillator" allows using 32kHz clock generated by an
740 external circuit. In this case, external clock signal must be connected
741 to 32K_XP pin. Amplitude should be <1.2V in case of sine wave signal,
742 and <1V in case of square wave signal. Common mode voltage should be
743 0.1 < Vcm < 0.5Vamp, where Vamp is the signal amplitude.
744 Additionally, 1nF capacitor must be connected between 32K_XN pin and
745 ground. 32K_XN pin can not be used as a GPIO in this case.
746 - "Internal 8.5MHz oscillator divided by 256" option results in higher
747 deep sleep current (by 5uA) but has better frequency stability than
748 the internal 150kHz oscillator. It does not require external components.
750 config ESP32_RTC_CLOCK_SOURCE_INTERNAL_RC
751 bool "Internal 150kHz RC oscillator"
752 config ESP32_RTC_CLOCK_SOURCE_EXTERNAL_CRYSTAL
753 bool "External 32kHz crystal"
754 config ESP32_RTC_CLOCK_SOURCE_EXTERNAL_OSC
755 bool "External 32kHz oscillator at 32K_XP pin"
756 config ESP32_RTC_CLOCK_SOURCE_INTERNAL_8MD256
757 bool "Internal 8.5MHz oscillator, divided by 256 (~33kHz)"
760 config ESP32_RTC_CLK_CAL_CYCLES
761 int "Number of cycles for RTC_SLOW_CLK calibration"
762 default 3000 if ESP32_RTC_CLOCK_SOURCE_EXTERNAL_CRYSTAL
763 default 1024 if ESP32_RTC_CLOCK_SOURCE_INTERNAL_RC
764 range 0 27000 if ESP32_RTC_CLOCK_SOURCE_EXTERNAL_CRYSTAL || ESP32_RTC_CLOCK_SOURCE_EXTERNAL_OSC || ESP32_RTC_CLOCK_SOURCE_INTERNAL_8MD256 # NOERROR
765 range 0 32766 if ESP32_RTC_CLOCK_SOURCE_INTERNAL_RC
767 When the startup code initializes RTC_SLOW_CLK, it can perform
768 calibration by comparing the RTC_SLOW_CLK frequency with main XTAL
769 frequency. This option sets the number of RTC_SLOW_CLK cycles measured
770 by the calibration routine. Higher numbers increase calibration
771 precision, which may be important for applications which spend a lot of
772 time in deep sleep. Lower numbers reduce startup time.
774 When this option is set to 0, clock calibration will not be performed at
775 startup, and approximate clock frequencies will be assumed:
777 - 150000 Hz if internal RC oscillator is used as clock source. For this use value 1024.
778 - 32768 Hz if the 32k crystal oscillator is used. For this use value 3000 or more.
779 In case more value will help improve the definition of the launch of the crystal.
780 If the crystal could not start, it will be switched to internal RC.
782 config ESP32_RTC_XTAL_BOOTSTRAP_CYCLES
783 int "Bootstrap cycles for external 32kHz crystal"
784 depends on ESP32_RTC_CLOCK_SOURCE_EXTERNAL_CRYSTAL
788 To reduce the startup time of an external RTC crystal,
789 we bootstrap it with a 32kHz square wave for a fixed number of cycles.
790 Setting 0 will disable bootstrapping (if disabled, the crystal may take
791 longer to start up or fail to oscillate under some conditions).
793 If this value is too high, a faulty crystal may initially start and then fail.
794 If this value is too low, an otherwise good crystal may not start.
796 To accurately determine if the crystal has started,
797 set a larger "Number of cycles for RTC_SLOW_CLK calibration" (about 3000).
799 config ESP32_DEEP_SLEEP_WAKEUP_DELAY
800 int "Extra delay in deep sleep wake stub (in us)"
804 When ESP32 exits deep sleep, the CPU and the flash chip are powered on
805 at the same time. CPU will run deep sleep stub first, and then
806 proceed to load code from flash. Some flash chips need sufficient
807 time to pass between power on and first read operation. By default,
808 without any extra delay, this time is approximately 900us, although
809 some flash chip types need more than that.
811 By default extra delay is set to 2000us. When optimizing startup time
812 for applications which require it, this value may be reduced.
814 If you are seeing "flash read err, 1000" message printed to the
815 console after deep sleep reset, try increasing this value.
817 choice ESP32_XTAL_FREQ_SEL
818 prompt "Main XTAL frequency"
819 default ESP32_XTAL_FREQ_40
821 ESP32 currently supports the following XTAL frequencies:
826 Startup code can automatically estimate XTAL frequency. This feature
827 uses the internal 8MHz oscillator as a reference. Because the internal
828 oscillator frequency is temperature dependent, it is not recommended
829 to use automatic XTAL frequency detection in applications which need
830 to work at high ambient temperatures and use high-temperature
831 qualified chips and modules.
832 config ESP32_XTAL_FREQ_40
834 config ESP32_XTAL_FREQ_26
836 config ESP32_XTAL_FREQ_AUTO
840 # Keep these values in sync with rtc_xtal_freq_t enum in soc/rtc.h
841 config ESP32_XTAL_FREQ
843 default 0 if ESP32_XTAL_FREQ_AUTO
844 default 40 if ESP32_XTAL_FREQ_40
845 default 26 if ESP32_XTAL_FREQ_26
847 config DISABLE_BASIC_ROM_CONSOLE
848 bool "Permanently disable BASIC ROM Console"
851 If set, the first time the app boots it will disable the BASIC ROM Console
852 permanently (by burning an eFuse).
854 Otherwise, the BASIC ROM Console starts on reset if no valid bootloader is
857 (Enabling secure boot also disables the BASIC ROM Console by default.)
860 bool "No Binary Blobs"
861 depends on !BT_ENABLED
864 If enabled, this disables the linking of binary libraries in the application build. Note
865 that after enabling this Wi-Fi/Bluetooth will not work.
867 config ESP_TIMER_PROFILING
868 bool "Enable esp_timer profiling features"
871 If enabled, esp_timer_dump will dump information such as number of times
872 the timer was started, number of times the timer has triggered, and the
873 total time it took for the callback to run.
874 This option has some effect on timer performance and the amount of memory
875 used for timer storage, and should only be used for debugging/testing
878 config COMPATIBLE_PRE_V2_1_BOOTLOADERS
879 bool "App compatible with bootloaders before IDF v2.1"
882 Bootloaders before IDF v2.1 did less initialisation of the
883 system clock. This setting needs to be enabled to build an app
884 which can be booted by these older bootloaders.
886 If this setting is enabled, the app can be booted by any bootloader
887 from IDF v1.0 up to the current version.
889 If this setting is disabled, the app can only be booted by bootloaders
890 from IDF v2.1 or newer.
892 Enabling this setting adds approximately 1KB to the app's IRAM usage.
894 config ESP_ERR_TO_NAME_LOOKUP
895 bool "Enable lookup of error code strings"
898 Functions esp_err_to_name() and esp_err_to_name_r() return string
899 representations of error codes from a pre-generated lookup table.
900 This option can be used to turn off the use of the look-up table in
901 order to save memory but this comes at the price of sacrificing
902 distinguishable (meaningful) output string representations.
904 config ESP32_RTCDATA_IN_FAST_MEM
905 bool "Place RTC_DATA_ATTR and RTC_RODATA_ATTR variables into RTC fast memory segment"
907 depends on FREERTOS_UNICORE
909 This option allows to place .rtc_data and .rtc_rodata sections into
910 RTC fast memory segment to free the slow memory region for ULP programs.
911 This option depends on the CONFIG_FREERTOS_UNICORE option because RTC fast memory
912 can be accessed only by PRO_CPU core.
914 endmenu # ESP32-Specific
918 config SW_COEXIST_ENABLE
919 bool "Software controls WiFi/Bluetooth coexistence"
920 depends on BT_ENABLED
923 If enabled, WiFi & Bluetooth coexistence is controlled by software rather than hardware.
924 Recommended for heavy traffic scenarios. Both coexistence configuration options are
925 automatically managed, no user intervention is required.
927 choice SW_COEXIST_PREFERENCE
928 prompt "WiFi/Bluetooth coexistence performance preference"
929 depends on SW_COEXIST_ENABLE
930 default SW_COEXIST_PREFERENCE_BALANCE
932 Choose Bluetooth/WiFi/Balance for different preference.
933 If choose WiFi, it will make WiFi performance better. Such, keep WiFi Audio more fluent.
934 If choose Bluetooth, it will make Bluetooth performance better. Such, keep Bluetooth(A2DP) Audio more
936 If choose Balance, the performance of WiFi and bluetooth will be balance. It's default. Normally, just
937 choose balance, the A2DP audio can play fluently, too.
938 Except config preference in menuconfig, you can also call esp_coex_preference_set() dynamically.
940 config SW_COEXIST_PREFERENCE_WIFI
943 config SW_COEXIST_PREFERENCE_BT
944 bool "Bluetooth(include BR/EDR and BLE)"
946 config SW_COEXIST_PREFERENCE_BALANCE
951 config SW_COEXIST_PREFERENCE_VALUE
953 depends on SW_COEXIST_ENABLE
954 default 0 if SW_COEXIST_PREFERENCE_WIFI
955 default 1 if SW_COEXIST_PREFERENCE_BT
956 default 2 if SW_COEXIST_PREFERENCE_BALANCE
958 config ESP32_WIFI_STATIC_RX_BUFFER_NUM
959 int "Max number of WiFi static RX buffers"
963 Set the number of WiFi static RX buffers. Each buffer takes approximately 1.6KB of RAM.
964 The static rx buffers are allocated when esp_wifi_init is called, they are not freed
965 until esp_wifi_deinit is called.
967 WiFi hardware use these buffers to receive all 802.11 frames.
968 A higher number may allow higher throughput but increases memory use.
970 config ESP32_WIFI_DYNAMIC_RX_BUFFER_NUM
971 int "Max number of WiFi dynamic RX buffers"
975 Set the number of WiFi dynamic RX buffers, 0 means unlimited RX buffers will be allocated
976 (provided sufficient free RAM). The size of each dynamic RX buffer depends on the size of
977 the received data frame.
979 For each received data frame, the WiFi driver makes a copy to an RX buffer and then delivers
980 it to the high layer TCP/IP stack. The dynamic RX buffer is freed after the higher layer has
981 successfully received the data frame.
983 For some applications, WiFi data frames may be received faster than the application can
984 process them. In these cases we may run out of memory if RX buffer number is unlimited (0).
986 If a dynamic RX buffer limit is set, it should be at least the number of static RX buffers.
988 choice ESP32_WIFI_TX_BUFFER
989 prompt "Type of WiFi TX buffers"
990 default ESP32_WIFI_DYNAMIC_TX_BUFFER
992 Select type of WiFi TX buffers:
994 If "Static" is selected, WiFi TX buffers are allocated when WiFi is initialized and released
995 when WiFi is de-initialized. The size of each static TX buffer is fixed to about 1.6KB.
997 If "Dynamic" is selected, each WiFi TX buffer is allocated as needed when a data frame is
998 delivered to the Wifi driver from the TCP/IP stack. The buffer is freed after the data frame
999 has been sent by the WiFi driver. The size of each dynamic TX buffer depends on the length
1000 of each data frame sent by the TCP/IP layer.
1002 If PSRAM is enabled, "Static" should be selected to guarantee enough WiFi TX buffers.
1003 If PSRAM is disabled, "Dynamic" should be selected to improve the utilization of RAM.
1005 config ESP32_WIFI_STATIC_TX_BUFFER
1007 config ESP32_WIFI_DYNAMIC_TX_BUFFER
1009 depends on !SPIRAM_USE_MALLOC
1012 config ESP32_WIFI_TX_BUFFER_TYPE
1014 default 0 if ESP32_WIFI_STATIC_TX_BUFFER
1015 default 1 if ESP32_WIFI_DYNAMIC_TX_BUFFER
1017 config ESP32_WIFI_STATIC_TX_BUFFER_NUM
1018 int "Max number of WiFi static TX buffers"
1019 depends on ESP32_WIFI_STATIC_TX_BUFFER
1023 Set the number of WiFi static TX buffers. Each buffer takes approximately 1.6KB of RAM.
1024 The static RX buffers are allocated when esp_wifi_init() is called, they are not released
1025 until esp_wifi_deinit() is called.
1027 For each transmitted data frame from the higher layer TCP/IP stack, the WiFi driver makes a
1028 copy of it in a TX buffer. For some applications especially UDP applications, the upper
1029 layer can deliver frames faster than WiFi layer can transmit. In these cases, we may run out
1032 config ESP32_WIFI_DYNAMIC_TX_BUFFER_NUM
1033 int "Max number of WiFi dynamic TX buffers"
1034 depends on ESP32_WIFI_DYNAMIC_TX_BUFFER
1038 Set the number of WiFi dynamic TX buffers. The size of each dynamic TX buffer is not fixed,
1039 it depends on the size of each transmitted data frame.
1041 For each transmitted frame from the higher layer TCP/IP stack, the WiFi driver makes a copy
1042 of it in a TX buffer. For some applications, especially UDP applications, the upper layer
1043 can deliver frames faster than WiFi layer can transmit. In these cases, we may run out of TX
1046 config ESP32_WIFI_CSI_ENABLED
1047 bool "WiFi CSI(Channel State Information)"
1050 Select this option to enable CSI(Channel State Information) feature. CSI takes about
1051 CONFIG_ESP32_WIFI_STATIC_RX_BUFFER_NUM KB of RAM. If CSI is not used, it is better to disable
1052 this feature in order to save memory.
1054 config ESP32_WIFI_AMPDU_TX_ENABLED
1055 bool "WiFi AMPDU TX"
1058 Select this option to enable AMPDU TX feature
1061 config ESP32_WIFI_TX_BA_WIN
1062 int "WiFi AMPDU TX BA window size"
1063 depends on ESP32_WIFI_AMPDU_TX_ENABLED
1067 Set the size of WiFi Block Ack TX window. Generally a bigger value means higher throughput but
1068 more memory. Most of time we should NOT change the default value unless special reason, e.g.
1069 test the maximum UDP TX throughput with iperf etc. For iperf test in shieldbox, the recommended
1072 config ESP32_WIFI_AMPDU_RX_ENABLED
1073 bool "WiFi AMPDU RX"
1076 Select this option to enable AMPDU RX feature
1078 config ESP32_WIFI_RX_BA_WIN
1079 int "WiFi AMPDU RX BA window size"
1080 depends on ESP32_WIFI_AMPDU_RX_ENABLED
1084 Set the size of WiFi Block Ack RX window. Generally a bigger value means higher throughput but
1085 more memory. Most of time we should NOT change the default value unless special reason, e.g.
1086 test the maximum UDP RX throughput with iperf etc. For iperf test in shieldbox, the recommended
1089 config ESP32_WIFI_NVS_ENABLED
1090 bool "WiFi NVS flash"
1093 Select this option to enable WiFi NVS flash
1095 choice ESP32_WIFI_TASK_CORE_ID
1096 depends on !FREERTOS_UNICORE
1097 prompt "WiFi Task Core ID"
1098 default ESP32_WIFI_TASK_PINNED_TO_CORE_0
1100 Pinned WiFi task to core 0 or core 1.
1102 config ESP32_WIFI_TASK_PINNED_TO_CORE_0
1104 config ESP32_WIFI_TASK_PINNED_TO_CORE_1
1108 config ESP32_WIFI_SOFTAP_BEACON_MAX_LEN
1109 int "Max length of WiFi SoftAP Beacon"
1113 ESP-MESH utilizes beacon frames to detect and resolve root node conflicts (see documentation). However the
1114 default length of a beacon frame can simultaneously hold only five root node identifier structures,
1115 meaning that a root node conflict of up to five nodes can be detected at one time. In the occurence of
1116 more root nodes conflict involving more than five root nodes, the conflict resolution process will detect
1117 five of the root nodes, resolve the conflict, and re-detect more root nodes. This process will repeat
1118 until all root node conflicts are resolved. However this process can generally take a very long time.
1120 To counter this situation, the beacon frame length can be increased such that more root nodes can be
1121 detected simultaneously. Each additional root node will require 36 bytes and should be added ontop of the
1122 default beacon frame length of
1123 752 bytes. For example, if you want to detect 10 root nodes simultaneously, you need to set the beacon
1127 Setting a longer beacon length also assists with debugging as the conflicting root nodes can be identified
1130 config ESP32_WIFI_DEBUG_LOG_ENABLE
1131 bool "Enable WiFi debug log"
1134 Select this option to enable WiFi debug log
1136 choice ESP32_WIFI_DEBUG_LOG_LEVEL
1137 depends on ESP32_WIFI_DEBUG_LOG_ENABLE
1138 prompt "WiFi debug log level"
1139 default ESP32_WIFI_LOG_DEBUG
1141 The WiFi log is divided into the following levels: ERROR,WARNING,INFO,DEBUG,VERBOSE.
1142 The ERROR,WARNING,INFO levels are enabled by default, and the DEBUG,VERBOSE levels can be enabled here.
1144 config ESP32_WIFI_DEBUG_LOG_DEBUG
1145 bool "WiFi Debug Log Debug"
1146 config ESP32_WIFI_DEBUG_LOG_VERBOSE
1147 bool "WiFi Debug Log Verbose"
1150 choice ESP32_WIFI_DEBUG_LOG_MODULE
1151 depends on ESP32_WIFI_DEBUG_LOG_ENABLE
1152 prompt "WiFi debug log module"
1153 default ESP32_WIFI_DEBUG_LOG_MODULE_WIFI
1155 The WiFi log module contains three parts: WIFI,COEX,MESH. The WIFI module indicates the logs related to
1156 WiFi, the COEX module indicates the logs related to WiFi and BT(or BLE) coexist, the MESH module indicates
1157 the logs related to Mesh. When ESP32_WIFI_LOG_MODULE_ALL is enabled, all modules are selected.
1159 config ESP32_WIFI_DEBUG_LOG_MODULE_ALL
1160 bool "WiFi Debug Log Module All"
1161 config ESP32_WIFI_DEBUG_LOG_MODULE_WIFI
1162 bool "WiFi Debug Log Module WiFi"
1163 config ESP32_WIFI_DEBUG_LOG_MODULE_COEX
1164 bool "WiFi Debug Log Module Coex"
1165 config ESP32_WIFI_DEBUG_LOG_MODULE_MESH
1166 bool "WiFi Debug Log Module Mesh"
1169 config ESP32_WIFI_DEBUG_LOG_SUBMODULE
1170 depends on ESP32_WIFI_DEBUG_LOG_ENABLE
1171 bool "WiFi debug log submodule"
1174 Enable this option to set the WiFi debug log submodule.
1175 Currently the log submodule contains the following parts: INIT,IOCTL,CONN,SCAN.
1176 The INIT submodule indicates the initialization process.The IOCTL submodule indicates the API calling
1178 The CONN submodule indicates the connecting process.The SCAN submodule indicates the scaning process.
1180 config ESP32_WIFI_DEBUG_LOG_SUBMODULE_ALL
1181 depends on ESP32_WIFI_DEBUG_LOG_SUBMODULE
1182 bool "WiFi Debug Log Submodule All"
1185 When this option is enabled, all debug submodules are selected.
1187 config ESP32_WIFI_DEBUG_LOG_SUBMODULE_INIT
1188 depends on ESP32_WIFI_DEBUG_LOG_SUBMODULE && (!ESP32_WIFI_DEBUG_LOG_SUBMODULE_ALL)
1189 bool "WiFi Debug Log Submodule Init"
1192 config ESP32_WIFI_DEBUG_LOG_SUBMODULE_IOCTL
1193 depends on ESP32_WIFI_DEBUG_LOG_SUBMODULE && (!ESP32_WIFI_DEBUG_LOG_SUBMODULE_ALL)
1194 bool "WiFi Debug Log Submodule Ioctl"
1197 config ESP32_WIFI_DEBUG_LOG_SUBMODULE_CONN
1198 depends on ESP32_WIFI_DEBUG_LOG_SUBMODULE && (!ESP32_WIFI_DEBUG_LOG_SUBMODULE_ALL)
1199 bool "WiFi Debug Log Submodule Conn"
1202 config ESP32_WIFI_DEBUG_LOG_SUBMODULE_SCAN
1203 depends on ESP32_WIFI_DEBUG_LOG_SUBMODULE && (!ESP32_WIFI_DEBUG_LOG_SUBMODULE_ALL)
1204 bool "WiFi Debug Log Submodule Scan"
1207 config ESP32_WIFI_IRAM_OPT
1208 bool "WiFi IRAM speed optimization"
1211 Select this option to place frequently called Wi-Fi library functions in IRAM.
1212 When this option is disabled, more than 10Kbytes of IRAM memory will be saved
1213 but Wi-Fi throughput will be reduced.
1219 config ESP32_PHY_CALIBRATION_AND_DATA_STORAGE
1220 bool "Store phy calibration data in NVS"
1223 If this option is enabled, NVS will be initialized and calibration data will be loaded from there.
1224 PHY calibration will be skipped on deep sleep wakeup. If calibration data is not found, full calibration
1225 will be performed and stored in NVS. Normally, only partial calibration will be performed.
1226 If this option is disabled, full calibration will be performed.
1228 If it's easy that your board calibrate bad data, choose 'n'.
1229 Two cases for example, you should choose 'n':
1230 1.If your board is easy to be booted up with antenna disconnected.
1231 2.Because of your board design, each time when you do calibration, the result are too unstable.
1232 If unsure, choose 'y'.
1234 config ESP32_PHY_INIT_DATA_IN_PARTITION
1235 bool "Use a partition to store PHY init data"
1238 If enabled, PHY init data will be loaded from a partition.
1239 When using a custom partition table, make sure that PHY data
1240 partition is included (type: 'data', subtype: 'phy').
1241 With default partition tables, this is done automatically.
1242 If PHY init data is stored in a partition, it has to be flashed there,
1243 otherwise runtime error will occur.
1245 If this option is not enabled, PHY init data will be embedded
1246 into the application binary.
1248 If unsure, choose 'n'.
1250 config ESP32_PHY_MAX_WIFI_TX_POWER
1251 int "Max WiFi TX power (dBm)"
1255 Set maximum transmit power for WiFi radio. Actual transmit power for high
1256 data rates may be lower than this setting.
1258 config ESP32_PHY_MAX_TX_POWER
1260 default ESP32_PHY_MAX_WIFI_TX_POWER
1265 menu "Power Management"
1268 bool "Support for power management"
1271 If enabled, application is compiled with support for power management.
1272 This option has run-time overhead (increased interrupt latency,
1273 longer time to enter idle state), and it also reduces accuracy of
1274 RTOS ticks and timers used for timekeeping.
1275 Enable this option if application uses power management APIs.
1277 config PM_DFS_INIT_AUTO
1278 bool "Enable dynamic frequency scaling (DFS) at startup"
1279 depends on PM_ENABLE
1282 If enabled, startup code configures dynamic frequency scaling.
1283 Max CPU frequency is set to CONFIG_ESP32_DEFAULT_CPU_FREQ_MHZ setting,
1284 min frequency is set to XTAL frequency.
1285 If disabled, DFS will not be active until the application
1286 configures it using esp_pm_configure function.
1288 config PM_USE_RTC_TIMER_REF
1289 bool "Use RTC timer to prevent time drift (EXPERIMENTAL)"
1290 depends on PM_ENABLE && (ESP32_TIME_SYSCALL_USE_RTC || ESP32_TIME_SYSCALL_USE_RTC_FRC1)
1293 When APB clock frequency changes, high-resolution timer (esp_timer)
1294 scale and base value need to be adjusted. Each adjustment may cause
1295 small error, and over time such small errors may cause time drift.
1296 If this option is enabled, RTC timer will be used as a reference to
1297 compensate for the drift.
1298 It is recommended that this option is only used if 32k XTAL is selected
1299 as RTC clock source.
1302 bool "Enable profiling counters for PM locks"
1303 depends on PM_ENABLE
1306 If enabled, esp_pm_* functions will keep track of the amount of time
1307 each of the power management locks has been held, and esp_pm_dump_locks
1308 function will print this information.
1309 This feature can be used to analyze which locks are preventing the chip
1310 from going into a lower power state, and see what time the chip spends
1311 in each power saving mode. This feature does incur some run-time
1312 overhead, so should typically be disabled in production builds.
1315 bool "Enable debug tracing of PM using GPIOs"
1316 depends on PM_ENABLE
1319 If enabled, some GPIOs will be used to signal events such as RTOS ticks,
1320 frequency switching, entry/exit from idle state. Refer to pm_trace.c
1321 file for the list of GPIOs.
1322 This feature is intended to be used when analyzing/debugging behavior
1323 of power management implementation, and should be kept disabled in
1327 endmenu # "Power Management"