Miscellaneous System APIs¶
Software reset¶
To perform software reset of the chip, esp_restart()
function is provided. When the function is called, execution of the program will stop, both CPUs will be reset, application will be loaded by the bootloader and started again.
Additionally, esp_register_shutdown_handler()
function is provided to register a routine which needs to be called prior to restart (when done by esp_restart()
). This is similar to the functionality of atexit
POSIX function.
Reset reason¶
ESP-IDF application can be started or restarted due to a variety of reasons. To get the last reset reason, call esp_reset_reason()
function. See description of esp_reset_reason_t
for the list of possible reset reasons.
Heap memory¶
Two heap memory related functions are provided:
esp_get_free_heap_size()
returns the current size of free heap memoryesp_get_minimum_free_heap_size()
returns the minimum size of free heap memory that was available during program execution.
Note that ESP-IDF supports multiple heaps with different capabilities. Functions mentioned in this section return the size of heap memory which can be allocated using malloc
family of functions. For further information about heap memory see Heap Memory Allocation.
Random number generation¶
ESP32 contains a hardware random number generator, values from it can be obtained using esp_random()
.
When Wi-Fi or Bluetooth are enabled, numbers returned by hardware random number generator (RNG) can be considered true random numbers. Without Wi-Fi or Bluetooth enabled, hardware RNG is a pseudo-random number generator. At startup, ESP-IDF bootloader seeds the hardware RNG with entropy, but care must be taken when reading random values between the start of app_main
and initialization of Wi-Fi or Bluetooth drivers.
MAC Address¶
These APIs allow querying and customizing MAC addresses used by Wi-Fi, Bluetooth, and Ethernet drivers.
ESP32 has up to 4 network interfaces: Wi-Fi station, Wi-Fi AP, Ethernet, and Bluetooth. Each of these interfaces needs to have a MAC address assigned to it. In ESP-IDF these addresses are calculated from Base MAC address. Base MAC address can be initialized with factory-programmed value from EFUSE, or with a user-defined value. In addition to setting the base MAC address, applications can specify the way in which MAC addresses are allocated to devices. See Number of universally administered MAC address section for more details.
Interface |
MAC address (4 universally administered) |
MAC address (2 universally administered) |
---|---|---|
Wi-Fi Station |
base_mac |
base_mac |
Wi-Fi SoftAP |
base_mac, +1 to the last octet |
base_mac, first octet randomized |
Bluetooth |
base_mac, +2 to the last octet |
base_mac, +1 to the last octet |
Ethernet |
base_mac, +3 to the last octet |
base_mac, +1 to the last octet, first octet randomized |
Base MAC address¶
Wi-Fi, Bluetooth, and Ethernet drivers use esp_read_mac()
function to get MAC address for a specific interface.
By default, this function will use MAC address factory programmed in BLK0 of EFUSE as the base MAC address. MAC addresses of each interface will be calculated according to the table above.
Applications which don’t use MAC address factory programmed into BLK0 of EFUSE can modify base MAC address used by esp_read_mac()
using a call to esp_base_mac_addr_set()
. Custom value of MAC address can come from application defined storage, such as Flash, NVS, etc. Note that the call to esp_base_mac_addr_set()
needs to happen before network protocol stacks are initialized, for example, early in app_main
.
Custom MAC address in BLK3 of EFUSE¶
To facilitate usage of custom MAC addresses, ESP-IDF provides esp_efuse_mac_get_custom()
function, which loads MAC address from BLK3 of EFUSE. This function assumes that custom MAC address is stored in BLK3 of EFUSE (EFUSE_BLK3_RDATA0, EFUSE_BLK3_RDATA1, EFUSE_BLK3_RDATA2, EFUSE_BLK3_RDATA3, EFUSE_BLK3_RDATA4, EFUSE_BLK3_RDATA5 registers) in the following format:
Field |
# of bits |
Range of bits |
Notes |
---|---|---|---|
Version |
8 |
191:184 |
0: invalid, others — valid |
Reserved |
128 |
183:56 |
|
MAC address |
48 |
55:8 |
|
MAC address CRC |
8 |
7:0 |
CRC-8-CCITT, polynomial 0x07 |
Once MAC address has been obtained using esp_efuse_mac_get_custom()
, call esp_base_mac_addr_set()
to set this MAC address as base MAC address.
Number of universally administered MAC address¶
Serveral MAC addresses (universally administered by IEEE) are uniquely assigned to the networking interfaces (Wi-Fi/BT/Ethernet). The final octet of each universally administered MAC address increases by one. Only the first one of them (which is called base MAC address) is stored in EFUSE or external storage, the others are generated from it. Here, ‘generate’ means adding 0, 1, 2 and 3 (respectively) to the final octet of the base MAC address.
If the universally administered MAC addresses are not enough for all of the networking interfaces, locally administered MAC addresses which are derived from universally administered MAC addresses are assigned to the rest of networking interfaces.
See this article for the definition of local and universally administered MAC addresses.
The number of universally administered MAC address can be configured using CONFIG_ESP32_UNIVERSAL_MAC_ADDRESSES.
If the number of universal MAC addresses is two, only two interfaces (Wi-Fi 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 (Wi-Fi SoftAP and Ethernet) receive local MAC addresses. These are derived from the universal Wi-Fi station and Bluetooth MAC addresses, respectively.
If the number of universal MAC addresses is four, all four interfaces (Wi-Fi Station, Wi-Fi 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.
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.)
Chip version¶
esp_chip_info()
function fills esp_chip_info_t
structure with information about the chip. This includes the chip revision, number of CPU cores, and a bit mask of features enabled in the chip.
SDK version¶
esp_get_idf_version()
returns a string describing the IDF version which was used to compile the application. This is the same value as the one available through IDF_VER
variable of the build system. The version string generally has the format of git describe
output.
To get the version at build time, additional version macros are provided. They can be used to enable or disable parts of the program depending on IDF version.
ESP_IDF_VERSION_MAJOR
,ESP_IDF_VERSION_MINOR
,ESP_IDF_VERSION_PATCH
are defined to integers representing major, minor, and patch version.ESP_IDF_VERSION_VAL
andESP_IDF_VERSION
can be used when implementing version checks:#include "esp_idf_version.h" #if ESP_IDF_VERSION >= ESP_IDF_VERSION_VAL(4, 0, 0) // enable functionality present in IDF v4.0 #endif
App version¶
Application version is stored in esp_app_desc_t
structure. It is located in DROM sector and has a fixed offset from the beginning of the binary file.
The structure is located after esp_image_header_t
and esp_image_segment_header_t
structures. The field version has string type and max length 32 chars.
To set version in your project manually you need to set PROJECT_VER
variable in your project CMakeLists.txt/Makefile:
In application CMakeLists.txt put
set(PROJECT_VER "0.1.0.1")
before includingproject.cmake
.
(For legacy GNU Make build system: in application Makefile put PROJECT_VER = "0.1.0.1"
before including project.mk
.)
If PROJECT_VER
variable is not set in the project then it will be retrieved from either $(PROJECT_PATH)/version.txt
file (if present) else using git command git describe
. If neither is available then PROJECT_VER
will be set to “1”. Application can make use of this by calling esp_ota_get_app_description()
or esp_ota_get_partition_description()
functions.
API Reference¶
Header File¶
Functions¶
-
esp_err_t
esp_register_shutdown_handler
(shutdown_handler_t handle)¶ Register shutdown handler.
This function allows you to register a handler that gets invoked before the application is restarted using esp_restart function.
- Return
ESP_OK on success
ESP_ERR_INVALID_STATE if the handler has already been registered
ESP_ERR_NO_MEM if no more shutdown handler slots are available
- Parameters
handle
: function to execute on restart
-
esp_err_t
esp_unregister_shutdown_handler
(shutdown_handler_t handle)¶ Unregister shutdown handler.
This function allows you to unregister a handler which was previously registered using esp_register_shutdown_handler function.
ESP_OK on success
ESP_ERR_INVALID_STATE if the given handler hasn’t been registered before
-
void
esp_restart
(void)¶ Restart PRO and APP CPUs.
This function can be called both from PRO and APP CPUs. After successful restart, CPU reset reason will be SW_CPU_RESET. Peripherals (except for WiFi, BT, UART0, SPI1, and legacy timers) are not reset. This function does not return.
-
esp_reset_reason_t
esp_reset_reason
(void)¶ Get reason of last reset.
- Return
See description of esp_reset_reason_t for explanation of each value.
-
uint32_t
esp_get_free_heap_size
(void)¶ Get the size of available heap.
Note that the returned value may be larger than the maximum contiguous block which can be allocated.
- Return
Available heap size, in bytes.
-
uint32_t
esp_get_minimum_free_heap_size
(void)¶ Get the minimum heap that has ever been available.
- Return
Minimum free heap ever available
-
uint32_t
esp_random
(void)¶ Get one random 32-bit word from hardware RNG.
The hardware RNG is fully functional whenever an RF subsystem is running (ie Bluetooth or WiFi is enabled). For random values, call this function after WiFi or Bluetooth are started.
If the RF subsystem is not used by the program, the function bootloader_random_enable() can be called to enable an entropy source. bootloader_random_disable() must be called before RF subsystem or I2S peripheral are used. See these functions’ documentation for more details.
Any time the app is running without an RF subsystem (or bootloader_random) enabled, RNG hardware should be considered a PRNG. A very small amount of entropy is available due to pre-seeding while the IDF bootloader is running, but this should not be relied upon for any use.
- Return
Random value between 0 and UINT32_MAX
-
void
esp_fill_random
(void *buf, size_t len)¶ Fill a buffer with random bytes from hardware RNG.
- Note
This function has the same restrictions regarding available entropy as esp_random()
- Parameters
buf
: Pointer to buffer to fill with random numbers.len
: Length of buffer in bytes
-
esp_err_t
esp_base_mac_addr_set
(const uint8_t *mac)¶ Set base MAC address with the MAC address which is stored in BLK3 of EFUSE or external storage e.g. flash and EEPROM.
Base MAC address is used to generate the MAC addresses used by the networking interfaces. If using base MAC address stored in BLK3 of EFUSE or external storage, call this API to set base MAC address with the MAC address which is stored in BLK3 of EFUSE or external storage before initializing WiFi/BT/Ethernet.
- Note
Base MAC must be a unicast MAC (least significant bit of first byte must be zero).
- Note
If not using a valid OUI, set the “locally administered” bit (bit value 0x02 in the first byte) to avoid collisions.
- Return
ESP_OK on success ESP_ERR_INVALID_ARG If mac is NULL or is not a unicast MAC
- Parameters
mac
: base MAC address, length: 6 bytes.
-
esp_err_t
esp_base_mac_addr_get
(uint8_t *mac)¶ Return base MAC address which is set using esp_base_mac_addr_set.
- Return
ESP_OK on success ESP_ERR_INVALID_MAC base MAC address has not been set
- Parameters
mac
: base MAC address, length: 6 bytes.
-
esp_err_t
esp_efuse_mac_get_custom
(uint8_t *mac)¶ Return base MAC address which was previously written to BLK3 of EFUSE.
Base MAC address is used to generate the MAC addresses used by the networking interfaces. This API returns the custom base MAC address which was previously written to BLK3 of EFUSE. Writing this EFUSE allows setting of a different (non-Espressif) base MAC address. It is also possible to store a custom base MAC address elsewhere, see esp_base_mac_addr_set() for details.
- Return
ESP_OK on success ESP_ERR_INVALID_VERSION An invalid MAC version field was read from BLK3 of EFUSE ESP_ERR_INVALID_CRC An invalid MAC CRC was read from BLK3 of EFUSE
- Parameters
mac
: base MAC address, length: 6 bytes.
-
esp_err_t
esp_efuse_mac_get_default
(uint8_t *mac)¶ Return base MAC address which is factory-programmed by Espressif in BLK0 of EFUSE.
- Return
ESP_OK on success
- Parameters
mac
: base MAC address, length: 6 bytes.
-
esp_err_t
esp_read_mac
(uint8_t *mac, esp_mac_type_t type)¶ Read base MAC address and set MAC address of the interface.
This function first get base MAC address using esp_base_mac_addr_get or reads base MAC address from BLK0 of EFUSE. Then set the MAC address of the interface including wifi station, wifi softap, bluetooth and ethernet.
- Return
ESP_OK on success
- Parameters
mac
: MAC address of the interface, length: 6 bytes.type
: type of MAC address, 0:wifi station, 1:wifi softap, 2:bluetooth, 3:ethernet.
-
esp_err_t
esp_derive_local_mac
(uint8_t *local_mac, const uint8_t *universal_mac)¶ Derive local MAC address from universal MAC address.
This function derives a local MAC address from an universal MAC address. A
definition of local vs universal MAC address can be found on Wikipedia <#Universal_vs._local>
. In ESP32, universal MAC address is generated from base MAC address in EFUSE or other external storage. Local MAC address is derived from the universal MAC address.- Return
ESP_OK on success
- Parameters
local_mac
: Derived local MAC address, length: 6 bytes.universal_mac
: Source universal MAC address, length: 6 bytes.
-
void
esp_chip_info
(esp_chip_info_t *out_info)¶ Fill an esp_chip_info_t structure with information about the chip.
- Parameters
[out] out_info
: structure to be filled
Structures¶
Macros¶
-
CHIP_FEATURE_EMB_FLASH
¶ Chip has embedded flash memory.
-
CHIP_FEATURE_WIFI_BGN
¶ Chip has 2.4GHz WiFi.
-
CHIP_FEATURE_BLE
¶ Chip has Bluetooth LE.
-
CHIP_FEATURE_BT
¶ Chip has Bluetooth Classic.
Enumerations¶
-
enum
esp_reset_reason_t
¶ Reset reasons.
Values:
-
ESP_RST_UNKNOWN
¶ Reset reason can not be determined.
-
ESP_RST_POWERON
¶ Reset due to power-on event.
-
ESP_RST_EXT
¶ Reset by external pin (not applicable for ESP32)
-
ESP_RST_SW
¶ Software reset via esp_restart.
-
ESP_RST_PANIC
¶ Software reset due to exception/panic.
-
ESP_RST_INT_WDT
¶ Reset (software or hardware) due to interrupt watchdog.
-
ESP_RST_TASK_WDT
¶ Reset due to task watchdog.
-
ESP_RST_WDT
¶ Reset due to other watchdogs.
-
ESP_RST_DEEPSLEEP
¶ Reset after exiting deep sleep mode.
-
ESP_RST_BROWNOUT
¶ Brownout reset (software or hardware)
-
ESP_RST_SDIO
¶ Reset over SDIO.
-
Header File¶
Functions¶
-
const char *
esp_get_idf_version
(void)¶ Return full IDF version string, same as ‘git describe’ output.
- Note
If you are printing the ESP-IDF version in a log file or other information, this function provides more information than using the numerical version macros. For example, numerical version macros don’t differentiate between development, pre-release and release versions, but the output of this function does.
- Return
constant string from IDF_VER
Macros¶
-
ESP_IDF_VERSION_MAJOR
¶ Major version number (X.x.x)
-
ESP_IDF_VERSION_MINOR
¶ Minor version number (x.X.x)
-
ESP_IDF_VERSION_PATCH
¶ Patch version number (x.x.X)
-
ESP_IDF_VERSION_VAL
(major, minor, patch)¶ Macro to convert IDF version number into an integer
To be used in comparisons, such as ESP_IDF_VERSION >= ESP_IDF_VERSION_VAL(4, 0, 0)
-
ESP_IDF_VERSION
¶ Current IDF version, as an integer
To be used in comparisons, such as ESP_IDF_VERSION >= ESP_IDF_VERSION_VAL(4, 0, 0)