alex/esp-idf
alex/esp-idf
1
0
Fork 0
mirror of https://github.com/espressif/esp-idf.git synced 2024-10-05 20:47:46 -04:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity
a86c80e3ec
esp-idf/components/esp32/Kconfig
KonstantinKondrashov a86c80e3ec all: Apply new version logic (major * 100 + minor)
2023-03-03 22:26:39 +00:00

914 lines
42 KiB
Plaintext
Raw Blame History

menu "ESP32-specific"
# TODO: this component simply shouldn't be included
# in the build at the CMake level, but this is currently
# not working so we just hide all items here
visible if IDF_TARGET_ESP32
config ESP32_ECO3_CACHE_LOCK_FIX
bool
default y
depends on !FREERTOS_UNICORE && ESP32_SPIRAM_SUPPORT
choice ESP32_REV_MIN
prompt "Minimum Supported ESP32 Revision"
default ESP32_REV_MIN_0
help
Required minimum chip revision. ESP-IDF will check for it and
reject to boot if the chip revision fails the check.
This ensures the chip used will have some modifications (features, or bugfixes).
The complied binary will only support chips above this revision,
this will also help to reduce binary size.
config ESP32_REV_MIN_0
bool "Rev v0.0 (ECO0)"
config ESP32_REV_MIN_1
bool "Rev v1.0 (ECO1)"
config ESP32_REV_MIN_1_1
bool "Rev v1.1 (ECO1.1)"
config ESP32_REV_MIN_2
bool "Rev v2.0 (ECO2)"
config ESP32_REV_MIN_3
bool "Rev v3.0 (ECO3)"
select ESP_INT_WDT if ESP32_ECO3_CACHE_LOCK_FIX
config ESP32_REV_MIN_3_1
bool "Rev v3.1 (ECO4)"
select ESP_INT_WDT if ESP32_ECO3_CACHE_LOCK_FIX
endchoice
config ESP32_REV_MIN
# we keep it for compatibility. Use ESP32_REV_MIN_FULL instead.
int
default 0 if ESP32_REV_MIN_0
default 1 if ESP32_REV_MIN_1 || ESP32_REV_MIN_1_1
default 2 if ESP32_REV_MIN_2
default 3 if ESP32_REV_MIN_3 || ESP32_REV_MIN_3_1
config ESP32_REV_MIN_FULL
int
default 0 if ESP32_REV_MIN_0
default 100 if ESP32_REV_MIN_1
default 101 if ESP32_REV_MIN_1_1
default 200 if ESP32_REV_MIN_2
default 300 if ESP32_REV_MIN_3
default 301 if ESP32_REV_MIN_3_1
config ESP_REV_MIN_FULL
int
default ESP32_REV_MIN_FULL
#
# MAX Revision
#
comment "Maximum Supported ESP32 Revision (Rev v3.99)"
# Maximum revision that IDF supports.
# It can not be changed by user.
# Only Espressif can change it when a new version will be supported in IDF.
# Supports all chips starting from ESP32_REV_MIN_FULL to ESP32_REV_MAX_FULL
config ESP32_REV_MAX_FULL
int
default 399
# keep in sync the "Maximum Supported Revision" description with this value
config ESP_REV_MAX_FULL
int
default ESP32_REV_MAX_FULL
config ESP32_DPORT_WORKAROUND
bool
default "y" if !FREERTOS_UNICORE && ESP32_REV_MIN_FULL < 200
choice ESP32_DEFAULT_CPU_FREQ_MHZ
prompt "CPU frequency"
default ESP32_DEFAULT_CPU_FREQ_40 if IDF_ENV_FPGA
default ESP32_DEFAULT_CPU_FREQ_160
help
CPU frequency to be set on application startup.
config ESP32_DEFAULT_CPU_FREQ_40
bool "40 MHz"
depends on IDF_ENV_FPGA
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 40 if ESP32_DEFAULT_CPU_FREQ_40
default 80 if ESP32_DEFAULT_CPU_FREQ_80
default 160 if ESP32_DEFAULT_CPU_FREQ_160
default 240 if ESP32_DEFAULT_CPU_FREQ_240
# Note: to support SPIRAM across multiple chips, check CONFIG_SPIRAM
# instead
config ESP32_SPIRAM_SUPPORT
bool "Support for external, SPI-connected RAM"
default "n"
select SPIRAM
help
This enables support for an external SPI RAM chip, connected in parallel with the
main SPI flash chip.
menu "SPI RAM config"
depends on ESP32_SPIRAM_SUPPORT
choice SPIRAM_TYPE
prompt "Type of SPI RAM chip in use"
default SPIRAM_TYPE_AUTO
config SPIRAM_TYPE_AUTO
bool "Auto-detect"
config SPIRAM_TYPE_ESPPSRAM16
bool "ESP-PSRAM16 or APS1604"
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 2097152 if SPIRAM_TYPE_ESPPSRAM16
default 4194304 if SPIRAM_TYPE_ESPPSRAM32
default 8388608 if SPIRAM_TYPE_ESPPSRAM64
default 0
choice SPIRAM_SPEED
prompt "Set RAM clock speed"
default SPIRAM_SPEED_40M
help
Select the speed for the SPI RAM chip.
If SPI RAM is enabled, we only support three combinations of SPI speed mode we supported now:
1. Flash SPI running at 40Mhz and RAM SPI running at 40Mhz
2. Flash SPI running at 80Mhz and RAM SPI running at 40Mhz
3. Flash SPI running at 80Mhz and RAM SPI running at 80Mhz
Note: If the third mode(80Mhz+80Mhz) is enabled for SPI RAM of type 32MBit, one of the HSPI/VSPI host
will be occupied by the system. Which SPI host to use can be selected by the config item
SPIRAM_OCCUPY_SPI_HOST. Application code should never touch HSPI/VSPI hardware in this case. The
option to select 80MHz will only be visible if the flash SPI speed is also 80MHz.
(ESPTOOLPY_FLASHFREQ_80M is true)
config SPIRAM_SPEED_40M
bool "40MHz clock speed"
config SPIRAM_SPEED_80M
depends on ESPTOOLPY_FLASHFREQ_80M
bool "80MHz clock speed"
endchoice
# insert non-chip-specific items here
source "$IDF_PATH/components/esp_hw_support/Kconfig.spiram.common"
config SPIRAM_CACHE_WORKAROUND
bool "Enable workaround for bug in SPI RAM cache for Rev1 ESP32s"
depends on (SPIRAM_USE_MEMMAP || SPIRAM_USE_CAPS_ALLOC || SPIRAM_USE_MALLOC) && (ESP32_REV_MIN_FULL < 300)
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.
menu "SPIRAM cache workaround debugging"
choice SPIRAM_CACHE_WORKAROUND_STRATEGY
prompt "Workaround strategy"
depends on SPIRAM_CACHE_WORKAROUND
default SPIRAM_CACHE_WORKAROUND_STRATEGY_MEMW
help
Select the workaround strategy. Note that the strategy for precompiled
libraries (libgcc, newlib, bt, wifi) is not affected by this selection.
Unless you know you need a different strategy, it's suggested you stay
with the default MEMW strategy. Note that DUPLDST can interfere with hardware
encryption and this will be automatically disabled if this workaround is selected.
'Insert nops' is the workaround that was used in older esp-idf versions. This workaround
still can cause faulty data transfers from/to SPI RAM in some situation.
config SPIRAM_CACHE_WORKAROUND_STRATEGY_MEMW
bool "Insert memw after vulnerable instructions (default)"
config SPIRAM_CACHE_WORKAROUND_STRATEGY_DUPLDST
bool "Duplicate LD/ST for 32-bit, memw for 8/16 bit"
config SPIRAM_CACHE_WORKAROUND_STRATEGY_NOPS
bool "Insert nops between vulnerable loads/stores (old strategy, obsolete)"
endchoice
#This needs to be Y only for the dupldst workaround
config SPIRAM_WORKAROUND_NEED_VOLATILE_SPINLOCK
bool
default "y" if SPIRAM_CACHE_WORKAROUND_STRATEGY_DUPLDST
endmenu
menu "SPIRAM workaround libraries placement"
visible if SPIRAM_CACHE_WORKAROUND
config SPIRAM_CACHE_LIBJMP_IN_IRAM
bool "Put libc's jump related functions in IRAM"
depends on SPIRAM_CACHE_WORKAROUND
default "y"
help
The functions affected by this option are: longjmp and setjmp.
Putting these function in IRAM will allow them to be called when flash cache is disabled
but it will also reduce the available size of free IRAM for the user application.
config SPIRAM_CACHE_LIBMATH_IN_IRAM
bool "Put libc's math related functions in IRAM"
depends on SPIRAM_CACHE_WORKAROUND
default "y"
help
The functions affected by this option are: abs, div, labs, ldiv, quorem, fpclassify,
and nan.
Putting these function in IRAM will allow them to be called when flash cache is disabled
but it will also reduce the available size of free IRAM for the user application.
config SPIRAM_CACHE_LIBNUMPARSER_IN_IRAM
bool "Put libc's number parsing related functions in IRAM"
depends on SPIRAM_CACHE_WORKAROUND
default "y"
help
The functions affected by this option are: utoa, itoa, atoi, atol, strtol, and strtoul.
Putting these function in IRAM will allow them to be called when flash cache is disabled
but it will also reduce the available size of free IRAM for the user application.
config SPIRAM_CACHE_LIBIO_IN_IRAM
bool "Put libc's I/O related functions in IRAM"
depends on SPIRAM_CACHE_WORKAROUND
default "y"
help
The functions affected by this option are: wcrtomb, fvwrite, wbuf, wsetup, fputwc, wctomb_r,
ungetc, makebuf, fflush, refill, and sccl.
Putting these function in IRAM will allow them to be called when flash cache is disabled
but it will also reduce the available size of free IRAM for the user application.
config SPIRAM_CACHE_LIBTIME_IN_IRAM
bool "Put libc's time related functions in IRAM"
depends on SPIRAM_CACHE_WORKAROUND
default "y"
help
The functions affected by this option are: asctime, asctime_r, ctime, ctime_r, lcltime, lcltime_r,
gmtime, gmtime_r, strftime, mktime, tzset_r, tzset, time, gettzinfo, systimes, month_lengths,
timelocal, tzvars, tzlock, tzcalc_limits, and strptime.
Putting these function in IRAM will allow them to be called when flash cache is disabled
but it will also reduce the available size of free IRAM for the user application.
config SPIRAM_CACHE_LIBCHAR_IN_IRAM
bool "Put libc's characters related functions in IRAM"
depends on SPIRAM_CACHE_WORKAROUND
default "y"
help
The functions affected by this option are: ctype_, toupper, tolower, toascii, strupr, bzero,
isalnum, isalpha, isascii, isblank, iscntrl, isdigit, isgraph, islower, isprint, ispunct,
isspace, and isupper.
Putting these function in IRAM will allow them to be called when flash cache is disabled
but it will also reduce the available size of free IRAM for the user application.
config SPIRAM_CACHE_LIBMEM_IN_IRAM
bool "Put libc's memory related functions in IRAM"
depends on SPIRAM_CACHE_WORKAROUND
default "y"
help
The functions affected by this option are: memccpy, memchr memmove, and memrchr.
Putting these function in IRAM will allow them to be called when flash cache is disabled
but it will also reduce the available size of free IRAM for the user application.
config SPIRAM_CACHE_LIBSTR_IN_IRAM
bool "Put libc's string related functions in IRAM"
depends on SPIRAM_CACHE_WORKAROUND
default "y"
help
The functions affected by this option are: strcasecmp, strcasestr, strchr, strcoll,
strcpy, strcspn, strdup, strdup_r, strlcat, strlcpy, strlen, strlwr, strncasecmp,
strncat, strncmp, strncpy, strndup, strndup_r, strrchr, strsep, strspn, strstr,
strtok_r, and strupr.
Putting these function in IRAM will allow them to be called when flash cache is disabled
but it will also reduce the available size of free IRAM for the user application.
config SPIRAM_CACHE_LIBRAND_IN_IRAM
bool "Put libc's random related functions in IRAM"
depends on SPIRAM_CACHE_WORKAROUND
default "y"
help
The functions affected by this option are: srand, rand, and rand_r.
Putting these function in IRAM will allow them to be called when flash cache is disabled
but it will also reduce the available size of free IRAM for the user application.
config SPIRAM_CACHE_LIBENV_IN_IRAM
bool "Put libc's environment related functions in IRAM"
depends on SPIRAM_CACHE_WORKAROUND
default "y"
help
The functions affected by this option are: environ, envlock, and getenv_r.
Putting these function in IRAM will allow them to be called when flash cache is disabled
but it will also reduce the available size of free IRAM for the user application.
config SPIRAM_CACHE_LIBFILE_IN_IRAM
bool "Put libc's file related functions in IRAM"
depends on SPIRAM_CACHE_WORKAROUND
default "y"
help
The functions affected by this option are: lock, isatty, fclose, open, close, creat, read,
rshift, sbrk, stdio, syssbrk, sysclose, sysopen, creat, sysread, syswrite, impure, fwalk,
and findfp.
Putting these function in IRAM will allow them to be called when flash cache is disabled
but it will also reduce the available size of free IRAM for the user application.
config SPIRAM_CACHE_LIBMISC_IN_IRAM
bool "Put libc's miscellaneous functions in IRAM, see help"
depends on SPIRAM_CACHE_WORKAROUND
default "y"
help
The functions affected by this option are: raise and system
Putting these function in IRAM will allow them to be called when flash cache is disabled
but it will also reduce the available size of free IRAM for the user application.
endmenu
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.
If spiram 2T mode is enabled, the size of 64Mbit psram will be changed as 32Mbit, so himem will be
unusable.
config SPIRAM_BANKSWITCH_RESERVE
int "Amount of 32K pages to reserve for bank switching"
depends on SPIRAM_BANKSWITCH_ENABLE
default 8
range 1 62
help
Select the amount of banks reserved for bank switching. Note that the amount of RAM allocatable with
malloc/esp_heap_alloc_caps will decrease by 32K for each page reserved here.
Note that this reservation is only actually done if your program actually uses the himem API. Without
any himem calls, the reservation is not done and the original amount of memory will be available
to malloc/esp_heap_alloc_caps.
config SPIRAM_ALLOW_STACK_EXTERNAL_MEMORY
bool "Allow external memory as an argument to xTaskCreateStatic"
default n
depends on SPIRAM_USE_MALLOC
help
Because some bits of the ESP32 code environment cannot be recompiled with the cache workaround,
normally tasks cannot be safely run with their stack residing in external memory; for this reason
xTaskCreate (and related task creaton functions) 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 enable this to cause xTaskCreateStatic to allow tasks stack in external
memory.
choice SPIRAM_OCCUPY_SPI_HOST
prompt "SPI host to use for 32MBit PSRAM"
default SPIRAM_OCCUPY_VSPI_HOST
depends on SPIRAM_SPEED_80M
help
When both flash and PSRAM is working under 80MHz, and the PSRAM is of type 32MBit, one of the HSPI/VSPI
host will be used to output the clock. Select which one to use here.
config SPIRAM_OCCUPY_HSPI_HOST
bool "HSPI host (SPI2)"
config SPIRAM_OCCUPY_VSPI_HOST
bool "VSPI host (SPI3)"
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 ESP32_SPIRAM_SUPPORT
range 0 33
default 17
help
The PSRAM CLOCK IO can be any unused GPIO, user can config it based on hardware design. If user use
1.8V flash and 1.8V psram, this value can only be one of 6, 7, 8, 9, 10, 11, 16, 17.
config D0WD_PSRAM_CS_IO
int "PSRAM CS IO number"
depends on ESP32_SPIRAM_SUPPORT
range 0 33
default 16
help
The PSRAM CS IO can be any unused GPIO, user can config it based on hardware design. If user use
1.8V flash and 1.8V psram, this value can only be one of 6, 7, 8, 9, 10, 11, 16, 17.
endmenu
menu "PSRAM clock and cs IO for ESP32-D2WD"
config D2WD_PSRAM_CLK_IO
int "PSRAM CLK IO number"
depends on ESP32_SPIRAM_SUPPORT
range 0 33
default 9
help
User can config it based on hardware design. For ESP32-D2WD chip, the psram can only be 1.8V psram,
so this value can only be one of 6, 7, 8, 9, 10, 11, 16, 17.
config D2WD_PSRAM_CS_IO
int "PSRAM CS IO number"
depends on ESP32_SPIRAM_SUPPORT
range 0 33
default 10
help
User can config it based on hardware design. For ESP32-D2WD chip, the psram can only be 1.8V psram,
so this value can only be one of 6, 7, 8, 9, 10, 11, 16, 17.
endmenu
menu "PSRAM clock and cs IO for ESP32-PICO"
config PICO_PSRAM_CS_IO
int "PSRAM CS IO number"
depends on ESP32_SPIRAM_SUPPORT
range 0 33
default 10
help
The PSRAM CS IO can be any unused GPIO, user can config it based on hardware design.
For ESP32-PICO chip, the psram share clock with flash, so user do not need to configure the clock
IO.
For the reference hardware design, please refer to
https://www.espressif.com/sites/default/files/documentation/esp32-pico-d4_datasheet_en.pdf
endmenu
config SPIRAM_CUSTOM_SPIWP_SD3_PIN
bool "Use custom SPI PSRAM WP(SD3) Pin when flash pins set in eFuse (read help)"
depends on IDF_TARGET_ESP32 && (ESPTOOLPY_FLASHMODE_DIO || ESPTOOLPY_FLASHMODE_DOUT)
default y if SPIRAM_SPIWP_SD3_PIN != 7 # backwards compatibility, can remove in IDF 5
default n
help
This setting is only used if the SPI flash pins have been overridden by setting the eFuses
SPI_PAD_CONFIG_xxx, and the SPI flash mode is DIO or DOUT.
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. The psram only has QPI
mode, so a WP pin setting is necessary.
If this config item is set to N (default), the correct WP pin will be automatically used for any
Espressif chip or module with integrated flash. If a custom setting is needed, set this config item
to Y and specify the GPIO number connected to the WP pin.
When flash mode is set to QIO or QOUT, the PSRAM WP pin will be set the same as the SPI Flash WP pin
configured in the bootloader.
config SPIRAM_SPIWP_SD3_PIN
int "Custom SPI PSRAM WP(SD3) Pin"
depends on IDF_TARGET_ESP32 && (ESPTOOLPY_FLASHMODE_DIO || ESPTOOLPY_FLASHMODE_DOUT)
#depends on SPIRAM_CUSTOM_SPIWP_SD3_PIN # backwards compatibility, can uncomment in IDF 5
range 0 33
default 7
help
The option "Use custom SPI PSRAM WP(SD3) pin" must be set or this value is ignored
If burning a customized set of SPI flash pins in eFuse and using DIO or DOUT mode for flash, set this
value to the GPIO number of the SPIRAM WP pin.
config SPIRAM_2T_MODE
bool "Enable SPI PSRAM 2T mode"
depends on ESP32_SPIRAM_SUPPORT
default "n"
help
Enable this option to fix single bit errors inside 64Mbit PSRAM.
Some 64Mbit PSRAM chips have a hardware issue in the RAM which causes bit errors at multiple
fixed bit positions.
Note: If this option is enabled, the 64Mbit PSRAM chip will appear to be 32Mbit in size.
Applications will not be affected unless the use the esp_himem APIs, which are not supported
in 2T mode.
endmenu # "SPI RAM config"
config ESP32_MEMMAP_TRACEMEM
bool
default "n"
config ESP32_MEMMAP_TRACEMEM_TWOBANKS
bool
default "n"
config ESP32_TRAX
bool "Use TRAX tracing feature"
default "n"
select ESP32_MEMMAP_TRACEMEM
help
The ESP32 contains a feature which allows you to trace the execution path the processor
has taken through the program. This is stored in a chunk of 32K (16K for single-processor)
of memory that can't be used for general purposes anymore. Disable this if you do not know
what this is.
config ESP32_TRAX_TWOBANKS
bool "Reserve memory for tracing both pro as well as app cpu execution"
default "n"
depends on ESP32_TRAX && !FREERTOS_UNICORE
select ESP32_MEMMAP_TRACEMEM_TWOBANKS
help
The ESP32 contains a feature which allows you to trace the execution path the processor
has taken through the program. This is stored in a chunk of 32K (16K for single-processor)
of memory that can't be used for general purposes anymore. Disable this if you do not know
what this is.
# Memory to reverse for trace, used in linker script
config ESP32_TRACEMEM_RESERVE_DRAM
hex
default 0x8000 if ESP32_MEMMAP_TRACEMEM && ESP32_MEMMAP_TRACEMEM_TWOBANKS
default 0x4000 if ESP32_MEMMAP_TRACEMEM && !ESP32_MEMMAP_TRACEMEM_TWOBANKS
default 0x0
config ESP32_ULP_COPROC_ENABLED
bool "Enable Ultra Low Power (ULP) Coprocessor"
default "n"
help
Set to 'y' if you plan to load a firmware for the coprocessor.
If this option is enabled, further coprocessor configuration will appear in the Components menu.
config ESP32_ULP_COPROC_RESERVE_MEM
int
prompt "RTC slow memory reserved for coprocessor" if ESP32_ULP_COPROC_ENABLED
default 512 if ESP32_ULP_COPROC_ENABLED
range 32 8176 if ESP32_ULP_COPROC_ENABLED
default 0 if !ESP32_ULP_COPROC_ENABLED
range 0 0 if !ESP32_ULP_COPROC_ENABLED
help
Bytes of memory to reserve for ULP coprocessor firmware & data.
Data is reserved at the beginning of RTC slow memory.
config ESP32_DEBUG_OCDAWARE
bool "Make exception and panic handlers JTAG/OCD aware"
default y
select FREERTOS_DEBUG_OCDAWARE
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_BROWNOUT_DET
bool "Hardware brownout detect & reset"
depends on !IDF_ENV_FPGA
default y
help
The ESP32 has a built-in brownout detector which can detect if the voltage is lower than
a specific value. If this happens, it will reset the chip in order to prevent unintended
behaviour.
choice ESP32_BROWNOUT_DET_LVL_SEL
prompt "Brownout voltage level"
depends on ESP32_BROWNOUT_DET
default ESP32_BROWNOUT_DET_LVL_SEL_0
help
The brownout detector will reset the chip when the supply voltage is approximately
below this level. Note that there may be some variation of brownout voltage level
between each ESP32 chip.
#The voltage levels here are estimates, more work needs to be done to figure out the exact voltages
#of the brownout threshold levels.
config ESP32_BROWNOUT_DET_LVL_SEL_0
bool "2.43V +/- 0.05"
config ESP32_BROWNOUT_DET_LVL_SEL_1
bool "2.48V +/- 0.05"
config ESP32_BROWNOUT_DET_LVL_SEL_2
bool "2.58V +/- 0.05"
config ESP32_BROWNOUT_DET_LVL_SEL_3
bool "2.62V +/- 0.05"
config ESP32_BROWNOUT_DET_LVL_SEL_4
bool "2.67V +/- 0.05"
config ESP32_BROWNOUT_DET_LVL_SEL_5
bool "2.70V +/- 0.05"
config ESP32_BROWNOUT_DET_LVL_SEL_6
bool "2.77V +/- 0.05"
config ESP32_BROWNOUT_DET_LVL_SEL_7
bool "2.80V +/- 0.05"
endchoice
config ESP32_BROWNOUT_DET_LVL
int
default 0 if ESP32_BROWNOUT_DET_LVL_SEL_0
default 1 if ESP32_BROWNOUT_DET_LVL_SEL_1
default 2 if ESP32_BROWNOUT_DET_LVL_SEL_2
default 3 if ESP32_BROWNOUT_DET_LVL_SEL_3
default 4 if ESP32_BROWNOUT_DET_LVL_SEL_4
default 5 if ESP32_BROWNOUT_DET_LVL_SEL_5
default 6 if ESP32_BROWNOUT_DET_LVL_SEL_6
default 7 if ESP32_BROWNOUT_DET_LVL_SEL_7
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"
select ESP_TIME_FUNCS_USE_RTC_TIMER
select ESP_TIME_FUNCS_USE_ESP_TIMER
config ESP32_TIME_SYSCALL_USE_RTC
bool "RTC"
select ESP_TIME_FUNCS_USE_RTC_TIMER
config ESP32_TIME_SYSCALL_USE_FRC1
bool "High-resolution timer"
select ESP_TIME_FUNCS_USE_ESP_TIMER
config ESP32_TIME_SYSCALL_USE_NONE
bool "None"
select ESP_TIME_FUNCS_USE_NONE
endchoice
choice ESP32_RTC_CLK_SRC
prompt "RTC clock source"
default ESP32_RTC_CLK_SRC_INT_RC
help
Choose which clock is used as RTC clock source.
- "Internal 150kHz oscillator" option provides lowest deep sleep current
consumption, and does not require extra external components. However
frequency stability with respect to temperature is poor, so time may
drift in deep/light sleep modes.
- "External 32kHz crystal" provides better frequency stability, at the
expense of slightly higher (1uA) deep sleep current consumption.
- "External 32kHz oscillator" allows using 32kHz clock generated by an
external circuit. In this case, external clock signal must be connected
to 32K_XN 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_XP pin and
ground. 32K_XP pin can not be used as a GPIO in this case.
- "Internal 8.5MHz oscillator divided by 256" option results in higher
deep sleep current (by 5uA) but has better frequency stability than
the internal 150kHz oscillator. It does not require external components.
config ESP32_RTC_CLK_SRC_INT_RC
bool "Internal 150kHz RC oscillator"
config ESP32_RTC_CLK_SRC_EXT_CRYS
bool "External 32kHz crystal"
select ESP_SYSTEM_RTC_EXT_XTAL
config ESP32_RTC_CLK_SRC_EXT_OSC
bool "External 32kHz oscillator at 32K_XN pin"
select ESP_SYSTEM_RTC_EXT_OSC
config ESP32_RTC_CLK_SRC_INT_8MD256
bool "Internal 8.5MHz oscillator, divided by 256 (~33kHz)"
endchoice
choice ESP32_RTC_EXT_CRYST_ADDIT_CURRENT_METHOD
prompt "Additional current for external 32kHz crystal"
depends on ESP32_RTC_CLK_SRC_EXT_CRYS
depends on ESP32_REV_MIN_FULL < 200
default ESP32_RTC_EXT_CRYST_ADDIT_CURRENT_NONE
help
With some 32kHz crystal configurations, the X32N and X32P pins may not have enough
drive strength to keep the crystal oscillating. Choose the method to provide
additional current from touchpad 9 to the external 32kHz crystal. Note that
the deep sleep current is slightly high (4-5uA) and the touchpad and the
wakeup sources of both touchpad and ULP are not available in method 1 and method 2.
This problem is fixed in ESP32 ECO 3, so this workaround is not needed. Setting the
project configuration to minimum revision ECO3 will disable this option, , allow
all wakeup sources, and save some code size.
- "None" option will not provide additional current to external crystal
- "Method 1" option can't ensure 100% to solve the external 32k crystal start failed
issue, but the touchpad can work in this method.
- "Method 2" option can solve the external 32k issue, but the touchpad can't work
in this method.
config ESP32_RTC_EXT_CRYST_ADDIT_CURRENT_NONE
bool "None"
config ESP32_RTC_EXT_CRYST_ADDIT_CURRENT
bool "Method 1"
config ESP32_RTC_EXT_CRYST_ADDIT_CURRENT_V2
bool "Method 2"
endchoice
config ESP32_RTC_CLK_CAL_CYCLES
int "Number of cycles for RTC_SLOW_CLK calibration"
default 3000 if ESP32_RTC_CLK_SRC_EXT_CRYS || ESP32_RTC_CLK_SRC_EXT_OSC || ESP32_RTC_CLK_SRC_INT_8MD256
default 1024 if ESP32_RTC_CLK_SRC_INT_RC
range 0 27000 if ESP32_RTC_CLK_SRC_EXT_CRYS || ESP32_RTC_CLK_SRC_EXT_OSC || ESP32_RTC_CLK_SRC_INT_8MD256
range 0 32766 if ESP32_RTC_CLK_SRC_INT_RC
help
When the startup code initializes RTC_SLOW_CLK, it can perform
calibration by comparing the RTC_SLOW_CLK frequency with main XTAL
frequency. This option sets the number of RTC_SLOW_CLK cycles measured
by the calibration routine. Higher numbers increase calibration
precision, which may be important for applications which spend a lot of
time in deep sleep. Lower numbers reduce startup time.
When this option is set to 0, clock calibration will not be performed at
startup, and approximate clock frequencies will be assumed:
- 150000 Hz if internal RC oscillator is used as clock source. For this use value 1024.
- 32768 Hz if the 32k crystal oscillator is used. For this use value 3000 or more.
In case more value will help improve the definition of the launch of the crystal.
If the crystal could not start, it will be switched to internal RC.
config ESP32_RTC_XTAL_CAL_RETRY
int "Number of attempts to repeat 32k XTAL calibration"
default 1
depends on ESP32_RTC_CLK_SRC_EXT_CRYS
help
Number of attempts to repeat 32k XTAL calibration
before giving up and switching to the internal RC.
Increase this option if the 32k crystal oscillator
does not start and switches to internal RC.
config ESP32_DEEP_SLEEP_WAKEUP_DELAY
int "Extra delay in deep sleep wake stub (in us)"
default 2000
range 0 5000
help
When ESP32 exits deep sleep, the CPU and the flash chip are powered on
at the same time. CPU will run deep sleep stub first, and then
proceed to load code from flash. Some flash chips need sufficient
time to pass between power on and first read operation. By default,
without any extra delay, this time is approximately 900us, although
some flash chip types need more than that.
By default extra delay is set to 2000us. When optimizing startup time
for applications which require it, this value may be reduced.
If you are seeing "flash read err, 1000" message printed to the
console after deep sleep reset, try increasing this value.
choice ESP32_XTAL_FREQ_SEL
prompt "Main XTAL frequency"
default ESP32_XTAL_FREQ_40
help
ESP32 currently supports the following XTAL frequencies:
- 26 MHz
- 40 MHz
Startup code can automatically estimate XTAL frequency. This feature
uses the internal 8MHz oscillator as a reference. Because the internal
oscillator frequency is temperature dependent, it is not recommended
to use automatic XTAL frequency detection in applications which need
to work at high ambient temperatures and use high-temperature
qualified chips and modules.
config ESP32_XTAL_FREQ_40
bool "40 MHz"
config ESP32_XTAL_FREQ_26
bool "26 MHz"
config ESP32_XTAL_FREQ_AUTO
bool "Autodetect"
endchoice
# Keep these values in sync with rtc_xtal_freq_t enum in soc/rtc.h
config ESP32_XTAL_FREQ
int
default 0 if ESP32_XTAL_FREQ_AUTO
default 40 if ESP32_XTAL_FREQ_40
default 26 if ESP32_XTAL_FREQ_26
config ESP32_DISABLE_BASIC_ROM_CONSOLE
bool "Permanently disable BASIC ROM Console"
default n
help
If set, the first time the app boots it will disable the BASIC ROM Console
permanently (by burning an eFuse).
Otherwise, the BASIC ROM Console starts on reset if no valid bootloader is
read from the flash.
(Enabling secure boot also disables the BASIC ROM Console by default.)
config ESP32_NO_BLOBS
bool "No Binary Blobs"
depends on !BT_ENABLED
default n
help
If enabled, this disables the linking of binary libraries in the application build. Note
that after enabling this Wi-Fi/Bluetooth will not work.
config ESP32_COMPATIBLE_PRE_V2_1_BOOTLOADERS
bool "App compatible with bootloaders before ESP-IDF v2.1"
select ESP32_COMPATIBLE_PRE_V3_1_BOOTLOADERS
default n
help
Bootloaders before ESP-IDF v2.1 did less initialisation of the
system clock. This setting needs to be enabled to build an app
which can be booted by these older bootloaders.
If this setting is enabled, the app can be booted by any bootloader
from IDF v1.0 up to the current version.
If this setting is disabled, the app can only be booted by bootloaders
from IDF v2.1 or newer.
Enabling this setting adds approximately 1KB to the app's IRAM usage.
config ESP32_COMPATIBLE_PRE_V3_1_BOOTLOADERS
bool "App compatible with bootloader and partition table before ESP-IDF v3.1"
default n
help
Partition tables before ESP-IDF V3.1 do not contain an MD5 checksum
field, and the bootloader before ESP-IDF v3.1 cannot read a partition
table that contains an MD5 checksum field.
Enable this option only if your app needs to boot on a bootloader and/or
partition table that was generated from a version *before* ESP-IDF v3.1.
If this option and Flash Encryption are enabled at the same time, and any
data partitions in the partition table are marked Encrypted, then the
partition encrypted flag should be manually verified in the app before accessing
the partition (see CVE-2021-27926).
config ESP32_APP_INIT_CLK
bool
default y if ESP32_COMPATIBLE_PRE_V2_1_BOOTLOADERS
default y if APP_BUILD_TYPE_ELF_RAM
config ESP32_RTCDATA_IN_FAST_MEM
bool "Place RTC_DATA_ATTR and RTC_RODATA_ATTR variables into RTC fast memory segment"
default n
depends on FREERTOS_UNICORE
help
This option allows to place .rtc_data and .rtc_rodata sections into
RTC fast memory segment to free the slow memory region for ULP programs.
This option depends on the CONFIG_FREERTOS_UNICORE option because RTC fast memory
can be accessed only by PRO_CPU core.
config ESP32_USE_FIXED_STATIC_RAM_SIZE
bool "Use fixed static RAM size"
default n
help
If this option is disabled, the DRAM part of the heap starts right after the .bss section,
within the dram0_0 region. As a result, adding or removing some static variables
will change the available heap size.
If this option is enabled, the DRAM part of the heap starts right after the dram0_0 region,
where its length is set with ESP32_FIXED_STATIC_RAM_SIZE
config ESP32_FIXED_STATIC_RAM_SIZE
hex "Fixed Static RAM size"
default 0x1E000
range 0 0x2c200
depends on ESP32_USE_FIXED_STATIC_RAM_SIZE
help
RAM size dedicated for static variables (.data & .bss sections).
Please note that the actual length will be reduced by BTDM_RESERVE_DRAM if Bluetooth
controller is enabled.
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.
config ESP32_IRAM_AS_8BIT_ACCESSIBLE_MEMORY
bool "Enable IRAM as 8 bit accessible memory"
depends on FREERTOS_UNICORE
help
If enabled, application can use IRAM as byte accessible region for storing data
(Note: IRAM region cannot be used as task stack)
This is possible due to handling of exceptions `LoadStoreError (3)` and `LoadStoreAlignmentError (9)`
Each unaligned read/write access will incur a penalty of maximum of 167 CPU cycles.
endmenu # ESP32-Specific
Reference in New Issue View Git Blame Copy Permalink