2017-01-18 07:05:26 -05:00
|
|
|
menu "ESP32-specific"
|
2019-06-19 03:31:47 -04:00
|
|
|
# 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
|
2016-08-17 11:08:22 -04:00
|
|
|
|
2019-07-28 23:35:00 -04:00
|
|
|
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
|
|
|
|
|
2019-01-25 11:10:53 -05:00
|
|
|
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
|
|
|
|
|
2019-06-19 03:31:47 -04:00
|
|
|
# Note: to support SPIRAM across multiple chips, check CONFIG_SPIRAM
|
|
|
|
# instead
|
2019-04-30 06:51:55 -04:00
|
|
|
config ESP32_SPIRAM_SUPPORT
|
2019-01-25 11:10:53 -05:00
|
|
|
bool "Support for external, SPI-connected RAM"
|
|
|
|
default "n"
|
2019-06-05 00:34:19 -04:00
|
|
|
select SPIRAM
|
2019-01-25 11:10:53 -05:00
|
|
|
help
|
|
|
|
This enables support for an external SPI RAM chip, connected in parallel with the
|
|
|
|
main SPI flash chip.
|
|
|
|
|
|
|
|
menu "SPI RAM config"
|
2019-04-30 06:51:55 -04:00
|
|
|
depends on ESP32_SPIRAM_SUPPORT
|
2019-01-25 11:10:53 -05:00
|
|
|
|
|
|
|
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"
|
2019-09-23 10:10:57 -04:00
|
|
|
default SPIRAM_SPEED_40M
|
2019-01-25 11:10:53 -05:00
|
|
|
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
|
|
|
|
|
2019-06-19 03:31:47 -04:00
|
|
|
# insert non-chip-specific items here
|
|
|
|
source "$IDF_PATH/components/esp_common/Kconfig.spiram.common"
|
|
|
|
|
2019-01-25 11:10:53 -05:00
|
|
|
config SPIRAM_CACHE_WORKAROUND
|
|
|
|
bool "Enable workaround for bug in SPI RAM cache for Rev1 ESP32s"
|
2019-09-16 22:28:51 -04:00
|
|
|
depends on (SPIRAM_USE_MEMMAP || SPIRAM_USE_CAPS_ALLOC || SPIRAM_USE_MALLOC) && (ESP32_REV_MIN < 3)
|
2019-01-25 11:10:53 -05:00
|
|
|
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
|
2019-02-21 20:20:11 -05:00
|
|
|
fix in the compiler (-mfix-esp32-psram-cache-issue) that makes sure the specific code that is
|
|
|
|
vulnerable to this will not be emitted.
|
2019-01-25 11:10:53 -05:00
|
|
|
|
|
|
|
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.
|
|
|
|
|
2019-09-16 22:28:51 -04:00
|
|
|
The workaround is not required for ESP32 revision 3 and above.
|
|
|
|
|
2019-01-25 11:10:53 -05:00
|
|
|
config SPIRAM_BANKSWITCH_ENABLE
|
|
|
|
bool "Enable bank switching for >4MiB external RAM"
|
|
|
|
default y
|
|
|
|
depends on SPIRAM_USE_MEMMAP || SPIRAM_USE_CAPS_ALLOC || SPIRAM_USE_MALLOC
|
|
|
|
help
|
|
|
|
The ESP32 only supports 4MiB of external RAM in its address space. The hardware does support larger
|
|
|
|
memories, but these have to be bank-switched in and out of this address space. Enabling this allows you
|
|
|
|
to reserve some MMU pages for this, which allows the use of the esp_himem api to manage these banks.
|
|
|
|
|
|
|
|
#Note that this is limited to 62 banks, as esp_spiram_writeback_cache needs some kind of mapping of
|
|
|
|
#some banks below that mark to work. We cannot at this moment guarantee this to exist when himem is
|
|
|
|
#enabled.
|
|
|
|
config SPIRAM_BANKSWITCH_RESERVE
|
|
|
|
int "Amount of 32K pages to reserve for bank switching"
|
|
|
|
depends on SPIRAM_BANKSWITCH_ENABLE
|
|
|
|
default 8
|
|
|
|
range 1 62
|
|
|
|
help
|
|
|
|
Select the amount of banks reserved for bank switching. Note that the amount of RAM allocatable with
|
|
|
|
malloc/esp_heap_alloc_caps will decrease by 32K for each page reserved here.
|
|
|
|
|
|
|
|
Note that this reservation is only actually done if your program actually uses the himem API. Without
|
|
|
|
any himem calls, the reservation is not done and the original amount of memory will be available
|
|
|
|
to malloc/esp_heap_alloc_caps.
|
|
|
|
|
|
|
|
config SPIRAM_ALLOW_STACK_EXTERNAL_MEMORY
|
|
|
|
bool "Allow external memory as an argument to xTaskCreateStatic"
|
|
|
|
default n
|
|
|
|
depends on SPIRAM_USE_MALLOC
|
|
|
|
help
|
|
|
|
Because some bits of the ESP32 code environment cannot be recompiled with the cache workaround,
|
|
|
|
normally tasks cannot be safely run with their stack residing in external memory; for this reason
|
|
|
|
xTaskCreate and friends always allocate stack in internal memory and xTaskCreateStatic will check if
|
|
|
|
the memory passed to it is in internal memory. If you have a task that needs a large amount of stack
|
|
|
|
and does not call on ROM code in any way (no direct calls, but also no Bluetooth/WiFi), you can try to
|
|
|
|
disable this and use xTaskCreateStatic to create the tasks stack in external memory.
|
|
|
|
|
|
|
|
choice SPIRAM_OCCUPY_SPI_HOST
|
|
|
|
prompt "SPI host to use for 32MBit PSRAM"
|
|
|
|
default SPIRAM_OCCUPY_VSPI_HOST
|
|
|
|
depends on SPIRAM_SPEED_80M
|
|
|
|
help
|
|
|
|
When both flash and PSRAM is working under 80MHz, and the PSRAM is of type 32MBit, one of the HSPI/VSPI
|
|
|
|
host will be used to output the clock. Select which one to use here.
|
|
|
|
|
|
|
|
config SPIRAM_OCCUPY_HSPI_HOST
|
|
|
|
bool "HSPI host (SPI2)"
|
|
|
|
config SPIRAM_OCCUPY_VSPI_HOST
|
|
|
|
bool "VSPI host (SPI3)"
|
|
|
|
endchoice
|
|
|
|
|
2019-05-07 04:36:37 -04:00
|
|
|
menu "PSRAM clock and cs IO for ESP32-DOWD"
|
|
|
|
|
|
|
|
config D0WD_PSRAM_CLK_IO
|
|
|
|
int "PSRAM CLK IO number"
|
|
|
|
depends on ESP32_SPIRAM_SUPPORT
|
|
|
|
range 0 33
|
|
|
|
default 17
|
|
|
|
help
|
|
|
|
The PSRAM CLOCK IO can be any unused GPIO, user can config it based on hardware design. If user use
|
|
|
|
1.8V flash and 1.8V psram, this value can only be one of 6, 7, 8, 9, 10, 11, 16, 17.
|
|
|
|
|
|
|
|
config D0WD_PSRAM_CS_IO
|
|
|
|
int "PSRAM CS IO number"
|
|
|
|
depends on ESP32_SPIRAM_SUPPORT
|
|
|
|
range 0 33
|
|
|
|
default 16
|
|
|
|
help
|
|
|
|
The PSRAM CS IO can be any unused GPIO, user can config it based on hardware design. If user use
|
|
|
|
1.8V flash and 1.8V psram, this value can only be one of 6, 7, 8, 9, 10, 11, 16, 17.
|
|
|
|
endmenu
|
|
|
|
|
|
|
|
menu "PSRAM clock and cs IO for ESP32-D2WD"
|
|
|
|
|
|
|
|
config D2WD_PSRAM_CLK_IO
|
|
|
|
int "PSRAM CLK IO number"
|
|
|
|
depends on ESP32_SPIRAM_SUPPORT
|
|
|
|
range 0 33
|
|
|
|
default 9
|
|
|
|
help
|
|
|
|
User can config it based on hardware design. For ESP32-D2WD chip, the psram can only be 1.8V psram,
|
|
|
|
so this value can only be one of 6, 7, 8, 9, 10, 11, 16, 17.
|
|
|
|
|
|
|
|
config D2WD_PSRAM_CS_IO
|
|
|
|
int "PSRAM CS IO number"
|
|
|
|
depends on ESP32_SPIRAM_SUPPORT
|
|
|
|
range 0 33
|
|
|
|
default 10
|
|
|
|
help
|
|
|
|
User can config it based on hardware design. For ESP32-D2WD chip, the psram can only be 1.8V psram,
|
|
|
|
so this value can only be one of 6, 7, 8, 9, 10, 11, 16, 17.
|
|
|
|
endmenu
|
|
|
|
|
|
|
|
menu "PSRAM clock and cs IO for ESP32-PICO"
|
|
|
|
|
|
|
|
config PICO_PSRAM_CS_IO
|
|
|
|
int "PSRAM CS IO number"
|
|
|
|
depends on ESP32_SPIRAM_SUPPORT
|
|
|
|
range 0 33
|
|
|
|
default 10
|
|
|
|
help
|
|
|
|
The PSRAM CS IO can be any unused GPIO, user can config it based on hardware design.
|
|
|
|
|
|
|
|
For ESP32-PICO chip, the psram share clock with flash, so user do not need to configure the clock
|
|
|
|
IO.
|
|
|
|
For the reference hardware design, please refer to
|
|
|
|
https://www.espressif.com/sites/default/files/documentation/esp32-pico-d4_datasheet_en.pdf
|
|
|
|
|
|
|
|
endmenu
|
|
|
|
|
|
|
|
config SPIRAM_SPIWP_SD3_PIN
|
|
|
|
int "SPI PSRAM WP(SD3) Pin when customising pins via eFuse (read help)"
|
|
|
|
depends on ESPTOOLPY_FLASHMODE_DIO || ESPTOOLPY_FLASHMODE_DOUT
|
2019-01-25 11:10:53 -05:00
|
|
|
range 0 33
|
2019-05-07 04:36:37 -04:00
|
|
|
default 7
|
2019-01-25 11:10:53 -05:00
|
|
|
help
|
2019-05-07 04:36:37 -04:00
|
|
|
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.
|
2019-01-25 11:10:53 -05:00
|
|
|
|
2019-05-07 04:36:37 -04:00
|
|
|
endmenu # "SPI RAM config"
|
2019-01-25 11:10:53 -05:00
|
|
|
|
2019-04-30 06:51:55 -04:00
|
|
|
config ESP32_MEMMAP_TRACEMEM
|
2019-01-25 11:10:53 -05:00
|
|
|
bool
|
|
|
|
default "n"
|
|
|
|
|
2019-04-30 06:51:55 -04:00
|
|
|
config ESP32_MEMMAP_TRACEMEM_TWOBANKS
|
2019-01-25 11:10:53 -05:00
|
|
|
bool
|
|
|
|
default "n"
|
|
|
|
|
|
|
|
config ESP32_TRAX
|
|
|
|
bool "Use TRAX tracing feature"
|
|
|
|
default "n"
|
2019-04-30 06:51:55 -04:00
|
|
|
select ESP32_MEMMAP_TRACEMEM
|
2019-01-25 11:10:53 -05:00
|
|
|
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
|
2019-04-30 06:51:55 -04:00
|
|
|
select ESP32_MEMMAP_TRACEMEM_TWOBANKS
|
2019-01-25 11:10:53 -05:00
|
|
|
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
|
2019-04-30 06:51:55 -04:00
|
|
|
config ESP32_TRACEMEM_RESERVE_DRAM
|
2019-01-25 11:10:53 -05:00
|
|
|
hex
|
2019-04-30 06:51:55 -04:00
|
|
|
default 0x8000 if ESP32_MEMMAP_TRACEMEM && ESP32_MEMMAP_TRACEMEM_TWOBANKS
|
|
|
|
default 0x4000 if ESP32_MEMMAP_TRACEMEM && !ESP32_MEMMAP_TRACEMEM_TWOBANKS
|
2019-01-25 11:10:53 -05:00
|
|
|
default 0x0
|
|
|
|
|
2019-04-30 06:51:55 -04:00
|
|
|
choice ESP32_UNIVERSAL_MAC_ADDRESSES
|
2019-01-25 11:10:53 -05:00
|
|
|
bool "Number of universally administered (by IEEE) MAC address"
|
2019-04-30 06:51:55 -04:00
|
|
|
default ESP32_UNIVERSAL_MAC_ADDRESSES_FOUR
|
2019-01-25 11:10:53 -05:00
|
|
|
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.)
|
|
|
|
|
2019-04-30 06:51:55 -04:00
|
|
|
config ESP32_UNIVERSAL_MAC_ADDRESSES_TWO
|
2019-01-25 11:10:53 -05:00
|
|
|
bool "Two"
|
2019-04-30 06:51:55 -04:00
|
|
|
config ESP32_UNIVERSAL_MAC_ADDRESSES_FOUR
|
2019-01-25 11:10:53 -05:00
|
|
|
bool "Four"
|
|
|
|
endchoice
|
|
|
|
|
2019-04-30 06:51:55 -04:00
|
|
|
config ESP32_UNIVERSAL_MAC_ADDRESSES
|
2019-01-25 11:10:53 -05:00
|
|
|
int
|
2019-04-30 06:51:55 -04:00
|
|
|
default 2 if ESP32_UNIVERSAL_MAC_ADDRESSES_TWO
|
|
|
|
default 4 if ESP32_UNIVERSAL_MAC_ADDRESSES_FOUR
|
2019-01-25 11:10:53 -05:00
|
|
|
|
|
|
|
|
2019-04-30 06:51:55 -04:00
|
|
|
config ESP32_ULP_COPROC_ENABLED
|
2019-01-25 11:10:53 -05:00
|
|
|
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.
|
|
|
|
|
2019-04-30 06:51:55 -04:00
|
|
|
config ESP32_ULP_COPROC_RESERVE_MEM
|
2019-01-25 11:10:53 -05:00
|
|
|
int
|
2019-04-30 06:51:55 -04:00
|
|
|
prompt "RTC slow memory reserved for coprocessor" if ESP32_ULP_COPROC_ENABLED
|
|
|
|
default 512 if ESP32_ULP_COPROC_ENABLED
|
|
|
|
range 32 8192 if ESP32_ULP_COPROC_ENABLED
|
|
|
|
default 0 if !ESP32_ULP_COPROC_ENABLED
|
|
|
|
range 0 0 if !ESP32_ULP_COPROC_ENABLED
|
2019-01-25 11:10:53 -05:00
|
|
|
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"
|
2019-06-13 12:43:49 -04:00
|
|
|
select ESP_GDBSTUB_ENABLED
|
2019-01-25 11:10:53 -05:00
|
|
|
help
|
|
|
|
Invoke gdbstub on the serial port, allowing for gdb to attach to it to do a postmortem
|
|
|
|
of the crash.
|
|
|
|
endchoice
|
|
|
|
|
|
|
|
config ESP32_DEBUG_OCDAWARE
|
|
|
|
bool "Make exception and panic handlers JTAG/OCD aware"
|
|
|
|
default y
|
2019-10-16 08:23:05 -04:00
|
|
|
select FREERTOS_DEBUG_OCDAWARE
|
2019-01-25 11:10:53 -05:00
|
|
|
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"
|
2019-09-03 01:12:58 -04:00
|
|
|
default COMPILER_OPTIMIZATION_DEFAULT
|
2019-01-25 11:10:53 -05:00
|
|
|
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.
|
|
|
|
|
2019-04-30 06:51:55 -04:00
|
|
|
config ESP32_BROWNOUT_DET
|
2019-01-25 11:10:53 -05:00
|
|
|
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.
|
|
|
|
|
2019-04-30 06:51:55 -04:00
|
|
|
choice ESP32_BROWNOUT_DET_LVL_SEL
|
2019-01-25 11:10:53 -05:00
|
|
|
prompt "Brownout voltage level"
|
2019-04-30 06:51:55 -04:00
|
|
|
depends on ESP32_BROWNOUT_DET
|
2019-09-23 10:10:57 -04:00
|
|
|
default ESP32_BROWNOUT_DET_LVL_SEL_0
|
2019-01-25 11:10:53 -05:00
|
|
|
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.
|
2019-04-30 06:51:55 -04:00
|
|
|
config ESP32_BROWNOUT_DET_LVL_SEL_0
|
2019-01-25 11:10:53 -05:00
|
|
|
bool "2.43V +/- 0.05"
|
2019-04-30 06:51:55 -04:00
|
|
|
config ESP32_BROWNOUT_DET_LVL_SEL_1
|
2019-01-25 11:10:53 -05:00
|
|
|
bool "2.48V +/- 0.05"
|
2019-04-30 06:51:55 -04:00
|
|
|
config ESP32_BROWNOUT_DET_LVL_SEL_2
|
2019-01-25 11:10:53 -05:00
|
|
|
bool "2.58V +/- 0.05"
|
2019-04-30 06:51:55 -04:00
|
|
|
config ESP32_BROWNOUT_DET_LVL_SEL_3
|
2019-01-25 11:10:53 -05:00
|
|
|
bool "2.62V +/- 0.05"
|
2019-04-30 06:51:55 -04:00
|
|
|
config ESP32_BROWNOUT_DET_LVL_SEL_4
|
2019-01-25 11:10:53 -05:00
|
|
|
bool "2.67V +/- 0.05"
|
2019-04-30 06:51:55 -04:00
|
|
|
config ESP32_BROWNOUT_DET_LVL_SEL_5
|
2019-01-25 11:10:53 -05:00
|
|
|
bool "2.70V +/- 0.05"
|
2019-04-30 06:51:55 -04:00
|
|
|
config ESP32_BROWNOUT_DET_LVL_SEL_6
|
2019-01-25 11:10:53 -05:00
|
|
|
bool "2.77V +/- 0.05"
|
2019-04-30 06:51:55 -04:00
|
|
|
config ESP32_BROWNOUT_DET_LVL_SEL_7
|
2019-01-25 11:10:53 -05:00
|
|
|
bool "2.80V +/- 0.05"
|
|
|
|
endchoice
|
|
|
|
|
2019-04-30 06:51:55 -04:00
|
|
|
config ESP32_BROWNOUT_DET_LVL
|
2019-01-25 11:10:53 -05:00
|
|
|
int
|
2019-04-30 06:51:55 -04:00
|
|
|
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
|
2019-01-25 11:10:53 -05:00
|
|
|
|
|
|
|
|
|
|
|
#Reduce PHY TX power when brownout reset
|
2019-04-30 06:51:55 -04:00
|
|
|
config ESP32_REDUCE_PHY_TX_POWER
|
2019-01-25 11:10:53 -05:00
|
|
|
bool "Reduce PHY TX power when brownout reset"
|
2019-04-30 06:51:55 -04:00
|
|
|
depends on ESP32_BROWNOUT_DET
|
2019-01-25 11:10:53 -05:00
|
|
|
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
|
|
|
|
|
2019-04-30 06:51:55 -04:00
|
|
|
choice ESP32_RTC_CLK_SRC
|
2019-01-25 11:10:53 -05:00
|
|
|
prompt "RTC clock source"
|
2019-04-30 06:51:55 -04:00
|
|
|
default ESP32_RTC_CLK_SRC_INT_RC
|
2019-01-25 11:10:53 -05:00
|
|
|
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.
|
|
|
|
|
2019-04-30 06:51:55 -04:00
|
|
|
config ESP32_RTC_CLK_SRC_INT_RC
|
2019-01-25 11:10:53 -05:00
|
|
|
bool "Internal 150kHz RC oscillator"
|
2019-04-30 06:51:55 -04:00
|
|
|
config ESP32_RTC_CLK_SRC_EXT_CRYS
|
2019-01-25 11:10:53 -05:00
|
|
|
bool "External 32kHz crystal"
|
2019-04-30 06:51:55 -04:00
|
|
|
config ESP32_RTC_CLK_SRC_EXT_OSC
|
2019-01-25 11:10:53 -05:00
|
|
|
bool "External 32kHz oscillator at 32K_XP pin"
|
2019-04-30 06:51:55 -04:00
|
|
|
config ESP32_RTC_CLK_SRC_INT_8MD256
|
2019-01-25 11:10:53 -05:00
|
|
|
bool "Internal 8.5MHz oscillator, divided by 256 (~33kHz)"
|
|
|
|
endchoice
|
|
|
|
|
2019-04-30 06:51:55 -04:00
|
|
|
config ESP32_RTC_EXT_CRYST_ADDIT_CURRENT
|
2018-12-22 01:19:46 -05:00
|
|
|
bool "Additional current for external 32kHz crystal"
|
2019-04-30 06:51:55 -04:00
|
|
|
depends on ESP32_RTC_CLK_SRC_EXT_CRYS
|
2018-12-22 01:19:46 -05:00
|
|
|
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.
|
|
|
|
|
2019-01-25 11:10:53 -05:00
|
|
|
config ESP32_RTC_CLK_CAL_CYCLES
|
|
|
|
int "Number of cycles for RTC_SLOW_CLK calibration"
|
2019-04-30 06:51:55 -04:00
|
|
|
default 3000 if ESP32_RTC_CLK_SRC_EXT_CRYS
|
|
|
|
default 1024 if ESP32_RTC_CLK_SRC_INT_RC
|
|
|
|
range 0 27000 if ESP32_RTC_CLK_SRC_EXT_CRYS || ESP32_RTC_CLK_SRC_EXT_OSC || ESP32_RTC_CLK_SRC_INT_8MD256
|
|
|
|
range 0 32766 if ESP32_RTC_CLK_SRC_INT_RC
|
2019-01-25 11:10:53 -05:00
|
|
|
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"
|
2019-04-30 06:51:55 -04:00
|
|
|
depends on ESP32_RTC_CLK_SRC_EXT_CRYS
|
2019-01-25 11:10:53 -05:00
|
|
|
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
|
|
|
|
|
2019-04-30 06:51:55 -04:00
|
|
|
config ESP32_DISABLE_BASIC_ROM_CONSOLE
|
2019-01-25 11:10:53 -05:00
|
|
|
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.)
|
|
|
|
|
2019-04-30 06:51:55 -04:00
|
|
|
config ESP32_NO_BLOBS
|
2019-01-25 11:10:53 -05:00
|
|
|
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.
|
|
|
|
|
2019-04-30 06:51:55 -04:00
|
|
|
config ESP32_COMPATIBLE_PRE_V2_1_BOOTLOADERS
|
2019-01-25 11:10:53 -05:00
|
|
|
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.
|
|
|
|
|
2019-07-22 10:04:03 -04:00
|
|
|
config ESP32_APP_INIT_CLK
|
|
|
|
bool
|
|
|
|
default y if ESP32_COMPATIBLE_PRE_V2_1_BOOTLOADERS
|
|
|
|
default y if APP_BUILD_TYPE_ELF_RAM
|
|
|
|
|
2019-01-25 11:10:53 -05:00
|
|
|
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.
|
2018-03-22 09:39:19 -04:00
|
|
|
|
2019-03-25 10:45:57 -04:00
|
|
|
config ESP32_USE_FIXED_STATIC_RAM_SIZE
|
|
|
|
bool "Use fixed static RAM size"
|
|
|
|
default n
|
|
|
|
help
|
|
|
|
If this option is disabled, the DRAM part of the heap starts right after the .bss section,
|
|
|
|
within the dram0_0 region. As a result, adding or removing some static variables
|
|
|
|
will change the available heap size.
|
|
|
|
|
|
|
|
If this option is enabled, the DRAM part of the heap starts right after the dram0_0 region,
|
|
|
|
where its length is set with ESP32_FIXED_STATIC_RAM_SIZE
|
|
|
|
|
|
|
|
config ESP32_FIXED_STATIC_RAM_SIZE
|
|
|
|
hex "Fixed Static RAM size"
|
|
|
|
default 0x1E000
|
|
|
|
range 0 0x2c200
|
|
|
|
depends on ESP32_USE_FIXED_STATIC_RAM_SIZE
|
|
|
|
help
|
|
|
|
RAM size dedicated for static variables (.data & .bss sections).
|
|
|
|
Please note that the actual length will be reduced by BT_RESERVE_DRAM if Bluetooth
|
|
|
|
controller is enabled.
|
|
|
|
|
2019-06-25 07:23:10 -04:00
|
|
|
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.
|
|
|
|
|
2017-08-22 00:55:23 -04:00
|
|
|
endmenu # ESP32-Specific
|
2017-08-20 12:01:03 -04:00
|
|
|
|
2017-09-22 11:02:58 -04:00
|
|
|
menu "Power Management"
|
2019-06-16 23:50:37 -04:00
|
|
|
# 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
|
2017-09-22 11:02:58 -04:00
|
|
|
|
2019-01-25 11:10:53 -05:00
|
|
|
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.
|
2018-09-26 13:48:22 -04:00
|
|
|
|
2017-09-22 11:02:58 -04:00
|
|
|
|
2017-10-28 00:15:40 -04:00
|
|
|
endmenu # "Power Management"
|