Crash_Override/OVMS3-idf
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
OVMS3-idf/components/esp32/Kconfig
Xia Xiaotian a41443184e components/esp_wifi: improve coexistence performance according to specific WiFi/BT/BLE scienario 
1. Improve WiFi throughput in some Classic BT scienarios(idle, inquire scan,
       connected, sniff, a2dp pause, etc).

    2. Support WiFi + Classic BT + BLE mesh coexistence scienario.

    3. Improve WiFi scan and connect succeed ratio in coexistence scienario.

    4. Do not support to choose software coexistence preference anymore for it is
       determined according to coexistence scienario automatically.

components/lwip: increase TCP send buffer and receive window limitation when TCP window scale is enabled

components/ble_mesh: Fix some bugs about ble mesh

    1. fix send acl pkt after ble have sent terminate ind modify min adv interval to 10ms.
2020-02-12 16:13:28 +08:00

1462 lines
64 KiB
Text
Raw Blame History

menu "ESP32-specific"
# Hidden option to support checking for this specific target in C code and Kconfig files
config IDF_TARGET_ESP32
bool
default "y" if IDF_TARGET="esp32"
default "n"
choice ESP32_REV_MIN
prompt "Minimum Supported ESP32 Revision"
default ESP32_REV_MIN_0
help
Minimum revision that ESP-IDF would support.
ESP-IDF performs different strategy on different esp32 revision.
config ESP32_REV_MIN_0
bool "Rev 0"
config ESP32_REV_MIN_1
bool "Rev 1"
config ESP32_REV_MIN_2
bool "Rev 2"
config ESP32_REV_MIN_3
bool "Rev 3"
endchoice
config ESP32_REV_MIN
int
default 0 if ESP32_REV_MIN_0
default 1 if ESP32_REV_MIN_1
default 2 if ESP32_REV_MIN_2
default 3 if ESP32_REV_MIN_3
config ESP32_DPORT_WORKAROUND
bool
default "y" if !FREERTOS_UNICORE && ESP32_REV_MIN < 2
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 SPIRAM_SUPPORT
bool "Support for external, SPI-connected RAM"
default "n"
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 SPIRAM_SUPPORT
config SPIRAM_BOOT_INIT
bool "Initialize SPI RAM when booting the ESP32"
default "y"
help
If this is enabled, the SPI RAM will be enabled during initial boot. Unless you
have specific requirements, you'll want to leave this enabled so memory allocated
during boot-up can also be placed in SPI RAM.
config SPIRAM_IGNORE_NOTFOUND
bool "Ignore PSRAM when not found"
default "n"
depends on SPIRAM_BOOT_INIT && !SPIRAM_ALLOW_BSS_SEG_EXTERNAL_MEMORY
help
Normally, if psram initialization is enabled during compile time but not found at runtime, it
is seen as an error making the ESP32 panic. If this is enabled, the ESP32 will keep on
running but will not add the (non-existing) RAM to any allocator.
choice SPIRAM_USE
prompt "SPI RAM access method"
default SPIRAM_USE_MALLOC
help
The SPI RAM can be accessed in multiple methods: by just having it available as an unmanaged
memory region in the ESP32 memory map, by integrating it in the ESP32s heap as 'special' memory
needing heap_caps_malloc to allocate, or by fully integrating it making malloc() also able to
return SPI RAM pointers.
config SPIRAM_USE_MEMMAP
bool "Integrate RAM into ESP32 memory map"
config SPIRAM_USE_CAPS_ALLOC
bool "Make RAM allocatable using heap_caps_malloc(..., MALLOC_CAP_SPIRAM)"
config SPIRAM_USE_MALLOC
bool "Make RAM allocatable using malloc() as well"
select SUPPORT_STATIC_ALLOCATION
endchoice
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
config SPIRAM_MEMTEST
bool "Run memory test on SPI RAM initialization"
default "y"
depends on SPIRAM_BOOT_INIT
help
Runs a rudimentary memory test on initialization. Aborts when memory test fails. Disable this for
slightly faster startop.
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) && (ESP32_REV_MIN < 3)
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.
The workaround is not required for ESP32 revision 3 and above.
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_MALLOC_ALWAYSINTERNAL
int "Maximum malloc() size, in bytes, to always put in internal memory"
depends on SPIRAM_USE_MALLOC
default 16384
range 0 131072
help
If malloc() is capable of also allocating SPI-connected ram, its allocation strategy will prefer to
allocate chunks less than this size in internal memory, while allocations larger than this will be
done from external RAM. If allocation from the preferred region fails, an attempt is made to allocate
from the non-preferred region instead, so malloc() will not suddenly fail when either internal or
external memory is full.
config WIFI_LWIP_ALLOCATION_FROM_SPIRAM_FIRST
bool "Try to allocate memories of WiFi and LWIP in SPIRAM firstly. If failed, allocate internal memory"
depends on SPIRAM_USE_CAPS_ALLOC || SPIRAM_USE_MALLOC
default "n"
help
Try to allocate memories of WiFi and LWIP in SPIRAM firstly. If failed, try to allocate internal
memory then.
config SPIRAM_MALLOC_RESERVE_INTERNAL
int "Reserve this amount of bytes for data that specifically needs to be in DMA or internal memory"
depends on SPIRAM_USE_MALLOC
default 32768
range 0 262144
help
Because the external/internal RAM allocation strategy is not always perfect, it sometimes may happen
that the internal memory is entirely filled up. This causes allocations that are specifically done in
internal memory, for example the stack for new tasks or memory to service DMA or have memory that's
also available when SPI cache is down, to fail. This option reserves a pool specifically for requests
like that; the memory in this pool is not given out when a normal malloc() is called.
Set this to 0 to disable this feature.
Note that because FreeRTOS stacks are forced to internal memory, they will also use this memory pool;
be sure to keep this in mind when adjusting this value.
Note also that the DMA reserved pool may not be one single contiguous memory region, depending on the
configured size and the static memory usage of the app.
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.
config SPIRAM_ALLOW_BSS_SEG_EXTERNAL_MEMORY
bool "Allow .bss segment placed in external memory"
default n
depends on SPIRAM_SUPPORT
help
If enabled the option,and add EXT_RAM_ATTR defined your variable,then your variable will be placed in
PSRAM instead of internal memory, and placed most of variables of lwip,net802.11,pp,bluedroid library
to external memory defaultly.
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)"
config SPIRAM_OCCUPY_NO_HOST
bool "Will not try to use any host, will abort if not able to use the PSRAM"
endchoice
menu "PSRAM clock and cs IO for ESP32-DOWD"
config D0WD_PSRAM_CLK_IO
int "PSRAM CLK IO number"
depends on 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 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 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 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 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 FLASHMODE_DIO || 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 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 && !FREERTOS_UNICORE
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 NUMBER_OF_UNIVERSAL_MAC_ADDRESS
bool "Number of universally administered (by IEEE) MAC address"
default FOUR_UNIVERSAL_MAC_ADDRESS
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 TWO_UNIVERSAL_MAC_ADDRESS
bool "Two"
config FOUR_UNIVERSAL_MAC_ADDRESS
bool "Four"
endchoice
config NUMBER_OF_UNIVERSAL_MAC_ADDRESS
int
default 2 if TWO_UNIVERSAL_MAC_ADDRESS
default 4 if FOUR_UNIVERSAL_MAC_ADDRESS
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 2304
help
Config system event task stack size in different application.
config MAIN_TASK_STACK_SIZE
int "Main task stack size"
default 3584
help
Configure the "main task" stack size. This is the stack of the task
which calls app_main(). If app_main() returns then this task is deleted
and its stack memory is freed.
config IPC_TASK_STACK_SIZE
int "Inter-Processor Call (IPC) task stack size"
default 1024
range 512 65536 if !ESP32_APPTRACE_ENABLE
range 2048 65536 if ESP32_APPTRACE_ENABLE
help
Configure the IPC tasks stack size. One IPC task runs on each core
(in dual core mode), and allows for cross-core function calls.
See IPC documentation for more details.
The default stack size should be enough for most common use cases.
It can be shrunk if you are sure that you do not use any custom
IPC functionality.
config TIMER_TASK_STACK_SIZE
int "High-resolution timer task stack size"
default 3584
range 2048 65536
help
Configure the stack size of esp_timer/ets_timer task. This task is used
to dispatch callbacks of timers created using ets_timer and esp_timer
APIs. If you are seing stack overflow errors in timer task, increase
this value.
Note that this is not the same as FreeRTOS timer task. To configure
FreeRTOS timer task size, see "FreeRTOS timer task stack size" option
in "FreeRTOS" menu.
choice NEWLIB_STDOUT_LINE_ENDING
prompt "Line ending for UART output"
default NEWLIB_STDOUT_LINE_ENDING_CRLF
help
This option allows configuring the desired line endings sent to UART
when a newline ('\n', LF) appears on stdout.
Three options are possible:
CRLF: whenever LF is encountered, prepend it with CR
LF: no modification is applied, stdout is sent as is
CR: each occurence of LF is replaced with CR
This option doesn't affect behavior of the UART driver (drivers/uart.h).
config NEWLIB_STDOUT_LINE_ENDING_CRLF
bool "CRLF"
config NEWLIB_STDOUT_LINE_ENDING_LF
bool "LF"
config NEWLIB_STDOUT_LINE_ENDING_CR
bool "CR"
endchoice
choice NEWLIB_STDIN_LINE_ENDING
prompt "Line ending for UART input"
default NEWLIB_STDIN_LINE_ENDING_CR
help
This option allows configuring which input sequence on UART produces
a newline ('\n', LF) on stdin.
Three options are possible:
CRLF: CRLF is converted to LF
LF: no modification is applied, input is sent to stdin as is
CR: each occurence of CR is replaced with LF
This option doesn't affect behavior of the UART driver (drivers/uart.h).
config NEWLIB_STDIN_LINE_ENDING_CRLF
bool "CRLF"
config NEWLIB_STDIN_LINE_ENDING_LF
bool "LF"
config NEWLIB_STDIN_LINE_ENDING_CR
bool "CR"
endchoice
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
prompt "RTC slow memory reserved for coprocessor" if ULP_COPROC_ENABLED
default 512 if ULP_COPROC_ENABLED
range 32 8192 if ULP_COPROC_ENABLED
default 0 if !ULP_COPROC_ENABLED
range 0 0 if !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"
help
Invoke gdbstub on the serial port, allowing for gdb to attach to it to do a postmortem
of the crash.
endchoice
config GDBSTUB_SUPPORT_TASKS
bool "GDBStub: enable listing FreeRTOS tasks"
default y
depends on ESP32_PANIC_GDBSTUB
help
If enabled, GDBStub can supply the list of FreeRTOS tasks to GDB.
Thread list can be queried from GDB using 'info threads' command.
Note that if GDB task lists were corrupted, this feature may not work.
If GDBStub fails, try disabling this feature.
config GDBSTUB_MAX_TASKS
int "GDBStub: maximum number of tasks supported"
default 32
depends on GDBSTUB_SUPPORT_TASKS
help
Set the number of tasks which GDB Stub will support.
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 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 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 if !SPIRAM_SUPPORT
default 800 if SPIRAM_SUPPORT
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 "Initialize Task Watchdog Timer on startup"
default y
help
The Task Watchdog Timer can be used to make sure individual tasks are still
running. Enabling this option will cause the Task Watchdog Timer to be
initialized automatically at startup. The Task Watchdog timer can be
initialized after startup as well (see Task Watchdog Timer API Reference)
config TASK_WDT_PANIC
bool "Invoke panic handler on Task Watchdog timeout"
depends on TASK_WDT
default n
help
If this option is enabled, the Task Watchdog Timer will be configured to
trigger the panic handler when it times out. This can also be configured
at run time (see Task Watchdog Timer API Reference)
config TASK_WDT_TIMEOUT_S
int "Task Watchdog timeout period (seconds)"
depends on TASK_WDT
range 1 60
default 5
help
Timeout period configuration for the Task Watchdog Timer in seconds.
This is also configurable at run time (see Task Watchdog Timer API Reference)
config TASK_WDT_CHECK_IDLE_TASK_CPU0
bool "Watch CPU0 Idle Task"
depends on TASK_WDT
default y
help
If this option is enabled, the Task Watchdog Timer will watch the CPU0
Idle Task. Having the Task Watchdog watch the Idle Task allows for detection
of CPU starvation as the Idle Task not being called is usually a symptom of
CPU starvation. Starvation of the Idle Task is detrimental as FreeRTOS household
tasks depend on the Idle Task getting some runtime every now and then.
config TASK_WDT_CHECK_IDLE_TASK_CPU1
bool "Watch CPU1 Idle Task"
depends on TASK_WDT && !FREERTOS_UNICORE
default y
help
If this option is enabled, the Task Wtachdog Timer will wach the CPU1
Idle Task.
config BROWNOUT_DET
#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.
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 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 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 BROWNOUT_DET_LVL_SEL_0
bool "2.43V +/- 0.05"
config BROWNOUT_DET_LVL_SEL_1
bool "2.48V +/- 0.05"
config BROWNOUT_DET_LVL_SEL_2
bool "2.58V +/- 0.05"
config BROWNOUT_DET_LVL_SEL_3
bool "2.62V +/- 0.05"
config BROWNOUT_DET_LVL_SEL_4
bool "2.67V +/- 0.05"
config BROWNOUT_DET_LVL_SEL_5
bool "2.70V +/- 0.05"
config BROWNOUT_DET_LVL_SEL_6
bool "2.77V +/- 0.05"
config BROWNOUT_DET_LVL_SEL_7
bool "2.80V +/- 0.05"
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
#Reduce PHY TX power when brownout reset
config REDUCE_PHY_TX_POWER
bool "Reduce PHY TX power when brownout reset"
depends on 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_CLOCK_SOURCE
prompt "RTC clock source"
default ESP32_RTC_CLOCK_SOURCE_INTERNAL_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_CLOCK_SOURCE_INTERNAL_RC
bool "Internal 150kHz RC oscillator"
config ESP32_RTC_CLOCK_SOURCE_EXTERNAL_CRYSTAL
bool "External 32kHz crystal"
config ESP32_RTC_CLOCK_SOURCE_EXTERNAL_OSC
bool "External 32kHz oscillator at 32K_XP pin"
config ESP32_RTC_CLOCK_SOURCE_INTERNAL_8MD256
bool "Internal 8.5MHz oscillator, divided by 256 (~33kHz)"
endchoice
config ESP32_RTC_EXTERNAL_CRYSTAL_ADDITIONAL_CURRENT
bool "Additional current for external 32kHz crystal"
depends on ESP32_RTC_CLOCK_SOURCE_EXTERNAL_CRYSTAL
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_CLOCK_SOURCE_EXTERNAL_CRYSTAL
default 1024 if ESP32_RTC_CLOCK_SOURCE_INTERNAL_RC
range 0 27000 if ESP32_RTC_CLOCK_SOURCE_EXTERNAL_CRYSTAL || ESP32_RTC_CLOCK_SOURCE_EXTERNAL_OSC || ESP32_RTC_CLOCK_SOURCE_INTERNAL_8MD256 # NOERROR
range 0 32766 if ESP32_RTC_CLOCK_SOURCE_INTERNAL_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_CLOCK_SOURCE_EXTERNAL_CRYSTAL
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 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 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 ESP_TIMER_PROFILING
bool "Enable esp_timer profiling features"
default n
help
If enabled, esp_timer_dump will dump information such as number of times
the timer was started, number of times the timer has triggered, and the
total time it took for the callback to run.
This option has some effect on timer performance and the amount of memory
used for timer storage, and should only be used for debugging/testing
purposes.
config 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 ESP_ERR_TO_NAME_LOOKUP
bool "Enable lookup of error code strings"
default "y"
help
Functions esp_err_to_name() and esp_err_to_name_r() return string
representations of error codes from a pre-generated lookup table.
This option can be used to turn off the use of the look-up table in
order to save memory but this comes at the price of sacrificing
distinguishable (meaningful) output string representations.
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_DPORT_DIS_INTERRUPT_LVL
int "Disable the interrupt level for the DPORT workarounds"
default 5
help
To prevent interrupting DPORT workarounds,
need to disable interrupt with a maximum used level in the system.
endmenu # ESP32-Specific
menu Wi-Fi
config SW_COEXIST_ENABLE
bool "Software controls WiFi/Bluetooth coexistence"
depends on BT_ENABLED
default y
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.
If only Bluetooth is used, it is recommended to disable this option to reduce binary file
size.
config ESP32_WIFI_STATIC_RX_BUFFER_NUM
int "Max number of WiFi static RX buffers"
range 2 25 if !WIFI_LWIP_ALLOCATION_FROM_SPIRAM_FIRST
range 8 25 if WIFI_LWIP_ALLOCATION_FROM_SPIRAM_FIRST
default 10 if !WIFI_LWIP_ALLOCATION_FROM_SPIRAM_FIRST
default 16 if WIFI_LWIP_ALLOCATION_FROM_SPIRAM_FIRST
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 all 802.11 frames.
A higher number may allow higher throughput but increases memory use. If ESP32_WIFI_AMPDU_RX_ENABLED
is enabled, this value is recommended to set equal or bigger than ESP32_WIFI_RX_BA_WIN in order to
achieve better throughput and compatibility with both stations and APs.
config ESP32_WIFI_DYNAMIC_RX_BUFFER_NUM
int "Max number of WiFi dynamic RX buffers"
range 0 128 if !LWIP_WND_SCALE
range 0 1024 if LWIP_WND_SCALE
default 32
help
Set the number of WiFi dynamic RX buffers, 0 means unlimited RX buffers will be allocated
(provided sufficient free RAM). The size of each dynamic RX buffer depends on the size of
the received data frame.
For each received data frame, the WiFi driver makes a copy to an RX buffer and then delivers
it to the high layer TCP/IP stack. The dynamic RX buffer is freed after the higher layer has
successfully received the data frame.
For some applications, WiFi data frames may be received faster than the application can
process them. In these cases we may run out of memory if RX buffer number is unlimited (0).
If a dynamic RX buffer limit is set, it should be at least the number of static RX buffers.
choice ESP32_WIFI_TX_BUFFER
prompt "Type of WiFi TX buffers"
default ESP32_WIFI_DYNAMIC_TX_BUFFER
help
Select type of WiFi TX buffers:
If "Static" is selected, WiFi TX buffers are allocated when WiFi is initialized and released
when WiFi is de-initialized. The size of each static TX buffer is fixed to about 1.6KB.
If "Dynamic" is selected, each WiFi TX buffer is allocated as needed when a data frame is
delivered to the Wifi driver from the TCP/IP stack. The buffer is freed after the data frame
has been sent by the WiFi driver. The size of each dynamic TX buffer depends on the length
of each data frame sent by the TCP/IP layer.
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"
depends on !SPIRAM_USE_MALLOC
endchoice
config ESP32_WIFI_TX_BUFFER_TYPE
int
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 ESP32_WIFI_STATIC_TX_BUFFER
range 6 64
default 16
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 transmitted data frame from the higher layer TCP/IP stack, the WiFi driver makes a
copy of it in a TX buffer. For some applications especially UDP applications, the upper
layer can deliver frames faster than WiFi layer can transmit. In these cases, we may run out
of TX buffers.
config ESP32_WIFI_DYNAMIC_TX_BUFFER_NUM
int "Max number of WiFi dynamic TX buffers"
depends on ESP32_WIFI_DYNAMIC_TX_BUFFER
range 16 128
default 32
help
Set the number of WiFi dynamic TX buffers. The size of each dynamic TX buffer is not fixed,
it depends on the size of each transmitted data frame.
For each transmitted frame from the higher layer TCP/IP stack, the WiFi driver makes a copy
of it in a TX buffer. For some applications, especially UDP applications, the upper layer
can deliver frames faster than WiFi layer can transmit. In these cases, we may run out of TX
buffers.
config ESP32_WIFI_CSI_ENABLED
bool "WiFi CSI(Channel State Information)"
default n
help
Select this option to enable CSI(Channel State Information) feature. CSI takes about
CONFIG_ESP32_WIFI_STATIC_RX_BUFFER_NUM KB of RAM. If CSI is not used, it is better to disable
this feature in order to save memory.
config ESP32_WIFI_AMPDU_TX_ENABLED
bool "WiFi AMPDU TX"
default y
help
Select this option to enable AMPDU TX feature
config ESP32_WIFI_TX_BA_WIN
int "WiFi AMPDU TX BA window size"
depends on ESP32_WIFI_AMPDU_TX_ENABLED
range 2 32
default 6
help
Set the size of WiFi Block Ack TX window. Generally a bigger value means higher throughput but
more memory. Most of time we should NOT change the default value unless special reason, e.g.
test the maximum UDP TX throughput with iperf etc. For iperf test in shieldbox, the recommended
value is 9~12.
config ESP32_WIFI_AMPDU_RX_ENABLED
bool "WiFi AMPDU RX"
default y
help
Select this option to enable AMPDU RX feature
config ESP32_WIFI_RX_BA_WIN
int "WiFi AMPDU RX BA window size"
depends on ESP32_WIFI_AMPDU_RX_ENABLED
range 2 32 if !WIFI_LWIP_ALLOCATION_FROM_SPIRAM_FIRST
range 16 32 if WIFI_LWIP_ALLOCATION_FROM_SPIRAM_FIRST
default 6 if !WIFI_LWIP_ALLOCATION_FROM_SPIRAM_FIRST
default 16 if WIFI_LWIP_ALLOCATION_FROM_SPIRAM_FIRST
help
Set the size of WiFi Block Ack RX window. Generally a bigger value means higher throughput and better
compatibility but more memory. Most of time we should NOT change the default value unless special
reason, e.g. test the maximum UDP RX throughput with iperf etc. For iperf test in shieldbox, the
recommended value is 9~12. If PSRAM is used and WiFi memory is prefered to allocat in PSRAM first,
the default and minimum value should be 16 to achieve better throughput and compatibility with both
stations and APs.
config ESP32_WIFI_NVS_ENABLED
bool "WiFi NVS flash"
default y
help
Select this option to enable WiFi NVS flash
choice ESP32_WIFI_TASK_CORE_ID
depends on !FREERTOS_UNICORE
prompt "WiFi Task Core ID"
default ESP32_WIFI_TASK_PINNED_TO_CORE_0
help
Pinned WiFi task to core 0 or core 1.
config ESP32_WIFI_TASK_PINNED_TO_CORE_0
bool "Core 0"
config ESP32_WIFI_TASK_PINNED_TO_CORE_1
bool "Core 1"
endchoice
config ESP32_WIFI_SOFTAP_BEACON_MAX_LEN
int "Max length of WiFi SoftAP Beacon"
range 752 1256
default 752
help
ESP-MESH utilizes beacon frames to detect and resolve root node conflicts (see documentation). However the
default length of a beacon frame can simultaneously hold only five root node identifier structures,
meaning that a root node conflict of up to five nodes can be detected at one time. In the occurence of
more root nodes conflict involving more than five root nodes, the conflict resolution process will detect
five of the root nodes, resolve the conflict, and re-detect more root nodes. This process will repeat
until all root node conflicts are resolved. However this process can generally take a very long time.
To counter this situation, the beacon frame length can be increased such that more root nodes can be
detected simultaneously. Each additional root node will require 36 bytes and should be added ontop of the
default beacon frame length of
752 bytes. For example, if you want to detect 10 root nodes simultaneously, you need to set the beacon
frame length as
932 (752+36*5).
Setting a longer beacon length also assists with debugging as the conflicting root nodes can be identified
more quickly.
config ESP32_WIFI_MGMT_SBUF_NUM
int "WiFi mgmt short buffer number"
range 6 32
default 32
help
Set the number of WiFi management short buffer.
config ESP32_WIFI_DEBUG_LOG_ENABLE
bool "Enable WiFi debug log"
default n
help
Select this option to enable WiFi debug log
choice ESP32_WIFI_DEBUG_LOG_LEVEL
depends on ESP32_WIFI_DEBUG_LOG_ENABLE
prompt "WiFi debug log level"
default ESP32_WIFI_LOG_DEBUG
help
The WiFi log is divided into the following levels: ERROR,WARNING,INFO,DEBUG,VERBOSE.
The ERROR,WARNING,INFO levels are enabled by default, and the DEBUG,VERBOSE levels can be enabled here.
config ESP32_WIFI_DEBUG_LOG_DEBUG
bool "WiFi Debug Log Debug"
config ESP32_WIFI_DEBUG_LOG_VERBOSE
bool "WiFi Debug Log Verbose"
endchoice
choice ESP32_WIFI_DEBUG_LOG_MODULE
depends on ESP32_WIFI_DEBUG_LOG_ENABLE
prompt "WiFi debug log module"
default ESP32_WIFI_DEBUG_LOG_MODULE_WIFI
help
The WiFi log module contains three parts: WIFI,COEX,MESH. The WIFI module indicates the logs related to
WiFi, the COEX module indicates the logs related to WiFi and BT(or BLE) coexist, the MESH module indicates
the logs related to Mesh. When ESP32_WIFI_LOG_MODULE_ALL is enabled, all modules are selected.
config ESP32_WIFI_DEBUG_LOG_MODULE_ALL
bool "WiFi Debug Log Module All"
config ESP32_WIFI_DEBUG_LOG_MODULE_WIFI
bool "WiFi Debug Log Module WiFi"
config ESP32_WIFI_DEBUG_LOG_MODULE_COEX
bool "WiFi Debug Log Module Coex"
config ESP32_WIFI_DEBUG_LOG_MODULE_MESH
bool "WiFi Debug Log Module Mesh"
endchoice
config ESP32_WIFI_DEBUG_LOG_SUBMODULE
depends on ESP32_WIFI_DEBUG_LOG_ENABLE
bool "WiFi debug log submodule"
default n
help
Enable this option to set the WiFi debug log submodule.
Currently the log submodule contains the following parts: INIT,IOCTL,CONN,SCAN.
The INIT submodule indicates the initialization process.The IOCTL submodule indicates the API calling
process.
The CONN submodule indicates the connecting process.The SCAN submodule indicates the scaning process.
config ESP32_WIFI_DEBUG_LOG_SUBMODULE_ALL
depends on ESP32_WIFI_DEBUG_LOG_SUBMODULE
bool "WiFi Debug Log Submodule All"
default n
help
When this option is enabled, all debug submodules are selected.
config ESP32_WIFI_DEBUG_LOG_SUBMODULE_INIT
depends on ESP32_WIFI_DEBUG_LOG_SUBMODULE && (!ESP32_WIFI_DEBUG_LOG_SUBMODULE_ALL)
bool "WiFi Debug Log Submodule Init"
default n
config ESP32_WIFI_DEBUG_LOG_SUBMODULE_IOCTL
depends on ESP32_WIFI_DEBUG_LOG_SUBMODULE && (!ESP32_WIFI_DEBUG_LOG_SUBMODULE_ALL)
bool "WiFi Debug Log Submodule Ioctl"
default n
config ESP32_WIFI_DEBUG_LOG_SUBMODULE_CONN
depends on ESP32_WIFI_DEBUG_LOG_SUBMODULE && (!ESP32_WIFI_DEBUG_LOG_SUBMODULE_ALL)
bool "WiFi Debug Log Submodule Conn"
default n
config ESP32_WIFI_DEBUG_LOG_SUBMODULE_SCAN
depends on ESP32_WIFI_DEBUG_LOG_SUBMODULE && (!ESP32_WIFI_DEBUG_LOG_SUBMODULE_ALL)
bool "WiFi Debug Log Submodule Scan"
default n
config ESP32_WIFI_IRAM_OPT
bool "WiFi IRAM speed optimization"
default n if (BT_ENABLED && SPIRAM_SUPPORT)
default y
help
Select this option to place frequently called Wi-Fi library functions in IRAM.
When this option is disabled, more than 10Kbytes of IRAM memory will be saved
but Wi-Fi throughput will be reduced.
config ESP32_WIFI_RX_IRAM_OPT
bool "WiFi RX IRAM speed optimization"
default n if (BT_ENABLED && SPIRAM_SUPPORT)
default y
help
Select this option to place frequently called Wi-Fi library RX functions in IRAM.
When this option is disabled, more than 17Kbytes of IRAM memory will be saved
but Wi-Fi performance will be reduced.
endmenu # Wi-Fi
menu PHY
config ESP32_PHY_CALIBRATION_AND_DATA_STORAGE
bool "Store phy calibration data in NVS"
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. Normally, only partial calibration will be performed.
If this option is disabled, full calibration will be performed.
If it's easy that your board calibrate bad data, choose 'n'.
Two cases for example, you should choose 'n':
1.If your board is easy to be booted up with antenna disconnected.
2.Because of your board design, each time when you do calibration, the result are too unstable.
If unsure, choose 'y'.
config ESP32_PHY_INIT_DATA_IN_PARTITION
bool "Use a partition to store PHY init data"
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
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
default ESP32_PHY_MAX_WIFI_TX_POWER
endmenu # PHY
menu "Power Management"
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"
Reference in a new issue View git blame Copy permalink