Since cpu retention dma use rc fast as clk source, so rc_fast_digi
will be enabled when we config to pd cpu. And cpu retention does not
need rc fast keep on during light sleep. So, if we use rc_fast_digi
to determine whether rc fast can be powered down, then cpu and and
rc fast cannot pd at the same time.
1. Rename MACROs SYSTEM_WIFI_RST_EN register bit fields to be more recognizable
2. reset Bluetooth baseband and MAC bits to fix the issue of task watchdog triggered during controller initialization due to invalid hardware state
Idle tick hook that indicates completion of scheduler init must be launched
on other core than the one where main task runs. Earlier it was assumed that
main task shall always run on PRO cpu but that behavior can be changed with
ESP_MAIN_TASK_AFFINITY_CPU1 and hence this fix.
Closes https://github.com/espressif/esp-idf/issues/9247
Closes IDFGH-7705
The Xtensa FreeRTOS port does not save the threadptr register when
doing a voluntary yield. This can result in a crash when multiple
tasks used the threadptr register and call "taskYIELD()".
This commit adds the threadptr register to the solicited stack frame.
The change fixes thread-local-storage size by removing .srodata section
from it. It initially was included in TLS section by mistake.
The issue was found when stack size increased after building applications
with GCC-11.1 compiler. Stack size became bigger because some new data
appeared in .srodata. See more details here:
adce62f53d
1.Update wifi doc for espnow/LR/fix rate/disable 11b/multiple antennas
2.Optimization example of wifi station
3.Optimize the null pointer judgment of eb
4.Bugfix for close sniffer mode when wifi stop
5.Fix deep sleep can't reconnect to ap when pmf enable.
6.Fix some ap will ignore auth when rx deauth for a while.
7.Fixed espnow recv unencrypted packets issue
8.Fix not update phy according to country code.
9.Update regdomain max channel according to country info from nvs and or AP.
10.Channel 14 is allowed only 11b mode.
11.Remove csa when switch channel from/to 14 channel.
12.Update phy mode nvs when softap channel from 14 to other.
13.Fix the bug that check whether channel parameter is valid.
The following functions are only defined when CONFIG_PM_ENABLE is defined:
- wifi_apb80m_request()
- wifi_apb80m_release()
This commit makes their linker script mapping statements also dependent on CONFIG_PM_ENABLE
thus fixing some linker errors when CONFIG_PM_ENABLE is disabled.
This commit enables ULP FSM support for esp32s3 and updates ULP FSM code
flow for other chips.
It adds C Macro support for the ULP FSM instruction set on esp32s2 and
esp32s3.
The unit tests are also updated to test ULP FSM on ep32s2 and esp32s3.
The previously used splits between memory allocated for ROM code,
2nd stage bootloader and the app were somewhat safe and conservative.
This resulted in some space being unavailable for static allocation
in the app.
This commit increases the space available for static allocation to the
maximum possible amount.
1. Some of the ROM code static allocation is only used in UART/USB/SPI
download modes. This region ("shared buffers") has been placed at
the lower end of ROM memory area, to be reusable in flash boot
mode. The 2nd stage bootloader linker script is modified to "pack"
all sections exactly up to the end but with roughly 8K margin between
startup stacks.
2. Instead of calculating the sections placement and hardcoding the
addresses in the LD script again, rewrite it to calculate the
start address of each memory region automatically based on the
logic above.
3. Adjust the app memory layout (SRAM_IRAM_END) accordingly,
increasing the space available for static allocation.
Overall these changes increase the space available for static
allocation by about 78kB.
The downside of these changes is that the 2nd stage bootloader .data
segment is now directly adjacent to the startup stack on the PRO CPU.
Previously, there was effectively about 78kB of extra stack space for
the PRO CPU, before the stack would run into the data segment.
On riscv core, core cycle counter counts the clock cycles only when core is active (not sleeping).
In spi_slave/sender example, it uses ccount (core cycle counter) to do a simple debounce.
Therefore, when using spi_slave/sender and spi_slave/receiver, program will be stuck.
This commit fix this issue by using esp_timer
Defining CMake variables from the command-line or from another CMake project,
such as `-DCMAKE_C_FLAGS= -DCMAKE_CXX_FLAGS=`, caused a link failure as ESP
CMake was unable to set its proper compilation flags.
Additional CMake compiler flags can now be provided by another project.
* Closes https://github.com/espressif/esp-idf/issues/7507
add: private include header
add: macro encapsulation for assertion or error check
add: ESP_FAIL return code documentation in public headers
change: replaced all assertions by NVS_ASSERT_OR_RETURN macro
change: few internal function return values from void to esp_err_t
change: ESP_ERR_NVS_VALUE_TOO_LONG macro comment
This fixes the issue where multiline strings and strings with delimiters inside the nvs input csv file were incorrectly parsed, and adds back the ability to add comment lines anywhere in the CSV file.
The issue stems from the move away from the python built in csv module to manual parsing, which was made after moving away from using the csv module to parse mfg data.
This reverts back to using the csv module for parsing and writing csv data in both mfg_gen and nvs_partition_gen, fixes the original issue in mfg_gen and improves code quality which makes the code more readable and maintainable.
Closes https://github.com/espressif/esp-idf/issues/7175
Refactor examples to build with MBEDTLS_CERTIFICATE_BUNDLE disabled. Only examples
that can work with certificate bundle disabled have been modified here.
Use local python server to test client session tickets
Update example test to test the client session tickets
Check for minimum heap info in the example test.
mktime function uses tm_isdst member as an indicator whether the time
stamp is expected to be in daylight saving time (1) or not (0).
FAT filesystem uses local time as mtime, so no information about DST
is available from the filesystem.
According to mktime documentation, tm_isdst can be set to -1, in which
case the C library will try to determine if DST was or wasn't in
effect at that time, and will set UTC time accordingly.
Note that the conversion from UTC to local time and then back to UTC
(time_t -> localtime_r -> FAT timestamp -> mktime -> time_t) does not
always recover the same UTC time. In particular, the local time in the
hour before DST comes into effect can be interpreted as "before DST"
or "after DST", which would correspond to different UTC values. In
this case which option the C library chooses is undefined.
Closes https://github.com/espressif/esp-idf/issues/9039
Originally reported in https://github.com/espressif/arduino-esp32/issues/6786
`vTaskGetSnapshot` is being used in coredump module to collect diagnostic information.
It is possible that input arguments are invalid and `assert` in this situation is not
correct.
This commit modifies API signature to return pdTRUE in case of success, and pdFALSE
otherwise. Caller can verify return value and then take appropriate decision.
Previously linenoiseProbe would accept any 4 byte response, even one
that isn't expected. This adds a check that the first byte of the
response is ESC.
Suggested in https://github.com/espressif/esp-idf/issues/8839.
Replaces the previously used Docker Hub autobuild infrastructure.
This allows for more flexible configuration of the build process,
at the expense of some extra maintenance of CI workflow files
required.
These two arguments can be used to reduce the size of the Docker
image:
- Setting IDF_CLONE_SHALLOW enables shallow cloning.
- Setting IDF_INSTALL_TARGETS to the comma separated list of targets
results in toolchains being installed only for these targets.
Purpose:
This will allow for easily automating periodic updates to
"cacrt_all.pem" file.
Note:
For now newly created "cacrt_local.pem" contains single "DST Root CA X3"
which we are keeping to manage compatibility with endpoints like
"howsmyssl.com". Please note this Root CA is expired and is not part of
Mozilla’s NSS root certificate store.
This commit fixes the systimer_counter_value_t by adding a resreved field so that the
type fills 64-bits.
Without the reserved field, when compiling with -O0 optimization, the unoccupied high
bits would not be initalized by the compiler, leading to systimer_hal_get_counter_value()
returning a garbage value.
if COAP_CONSTRAINED_STACK is defined (is for esp-idf), the mutexes set up
to protect the critical sections were not working as expected and were just
dummy entries.
Use the pthread_ version of the mutex instead by defining HAVE_PTHREAD_H
and HAVE_PTHREAD_MUTEX_LOCK.
Since ulp wakeup signal are connected to ulp int raw(except esp32), we
need to clear ulp int raw before sleep when ulp wakeup enabled. Otherwise,
if the ulp int raw is already set, chip will not sleep properly.
Closes https://github.com/espressif/esp-idf/issues/6229
This fixes a potential race condition in select() if both a socket-fd
and non-socket fd trigger simultaneously to unblock this select.
In case of both fds, we use lwip's local thread semaphore, so we only
have to try return it (if it was taken/triggered more than once) when
we exit select().
Closes https://github.com/espressif/esp-idf/issues/8896
Bluetooth: disable PLL track function for ESP32-C3/ESP32-S3 as it introduced coexistence issues(bacport v4.4)
See merge request espressif/esp-idf!18139
Clang outputs performance warnings by default for atomic operations with
access size more then 4 bytes. So add "-Wno-atomic-alignment add" flag to
ESP-IDF cmake script.
'read' function should return 0 when encountering an end of file. When
newlib calls read and sees EOF returned, it assumes that this
condition is permanent and never calls 'read' for this file again
(unless the read pointer is moved using fseek).
The correct behavior in case no characters were received over UART is
to return -1. In this case newlib will retry reading from file on next
call to fread, fgetc or another function which calls __srefill_r.
introduced in e44ead5356
1. The int8M power domain config by default is PD. While LEDC is using
RTC8M as clock source, this power domain will be kept on.
But when 8MD256 is used as RTC clock source, the power domain should
also be kept on.
On ESP32, there was protection for it, but broken by commit
e44ead5356. Currently the power domain
will be forced on when LEDC is using RTC8M as clock source &&
!int8m_pd_en (user enable ESP_PDP_DOMAIN_RTC8M in lightsleep). Otherwise
the power domain will be powered off, regardless of RTC clock source.
In other words, int8M domain will be forced off (even when 8MD256
used as RTC clock source) if LEDC not using RTC8M as clock source, user
doesn't enable ESP_PDP_DOMAIN_RTC8M, or in deep sleep.
On later chips, there's no such protection, so 8MD256 could't be used as
RTC clock source in sleep modes.
This commit adds protection of 8MD256 clock to other chips. Fixes the
incorrect protection logic overriding on ESP32. Now the power domain
will be determiend by the logic below (order by priority):
1. When RTC clock source uses 8MD256, power up
2. When LEDC uses RTC8M clock source, power up
3. In deepsleep, power down
4. Otherwise determined by user config of ESP_PDP_DOMAIN_RTC8M,
power down by default. (This is preferred to have highest
priority, but it's kept as is because of current code structure.)
2. Before, after the macro `RTC_SLEEP_CONFIG_DEFAULT` decides dbias, the
protection above may force the int8m PU. This may cause the inconsistent
of dbias and the int8m PU status.
This commit lifts the logic of pd int8m/xtal fpu logic to upper layer
(sleep_modes.c).
Related: https://github.com/espressif/esp-idf/issues/8007, https://github.com/espressif/esp-idf/pull/8089
temp
fix(server): Fix websocket server not support handle multiple connections when client send CLOSE frame (backport v4.4)
See merge request espressif/esp-idf!18018
ESP-IDF v4.4 supports Python 3.6 or newer. F-strings are available there
but idf_tools.py can fail if run with older Pythons because the Python
version check is done later.
Closes https://github.com/espressif/esp-idf/issues/8890
Prior to this change "esp_wifi_clear_default_wifi_driver_and_handlers"
will not remove netif pointer from table when both AP and STA interfaces were
created and destroying default wifi interfaces is done in unfortunate
order. As a result there is dangling pointer left and it may cause crash in
later code (i.e. when esp_wifi_stop() is called).
ESP32-S2 and ESP32-S3
supports up to 1 GB of external flash and RAM
add support for
- 32MB
- 64MB
- 128MB ( example NOR spiFLASH 1G-BIT W25Q01JVZEIQ Winbond 0xEF 0x40 0x21 )
Merges https://github.com/espressif/esp-idf/pull/7688
Signed-off-by: Ivan Grokhotkov <ivan@espressif.com>
The compiler was not informed that the assembly block should be
treated as a memory barrier and could optimize out the initialization
of local arrays which could be used as semihosting arguments.
This resulted in garbage values being passed as semihosting call
arguments.
Additionally this commit changes the approach for placing values into
specific register. Instead of clobbers, local register variables are
used. This results in simpler generated code, since the compiler is
able to place values directly into the registers used for semihosting
arguments, avoiding additional moves.
LVGL porting examples are temporarily left in test folder.
Now we can remove it, as we have lvgl examples in esp-idf.
And lvgl v7 is legacy, we recommend to use lvgl v8
* Move filesystem mounting code into a separate file to simplify the
main source file.
* Clean up SDMMC and SDSPI related code. Move pin configuration into
Kconfig.
* Use same base_path ('/data') for either SPIFFS or SD. Remove the
check in file_server.c about the base path.
* Update README according to the changes above.
- Added a config option to set the minimum Certificate Verification
mode to Optional
- When this option is enabled, the peer (the client) certificate
is checked by the server, however the handshake continues even if
verification failed.
- By default, the peer certificate is not checked and ignored by the server.
Closes https://github.com/espressif/esp-idf/issues/8664
* Cherry-pick important fixes to 2.1.2-esp
- CVE-2020-22283: Attacker could craft a packet that would disclose 8 bytes of some heap memory:
- icmp6: Don't copy too much data
- icmp6: Fix copying of chained pbuf in reply
- icmp6: keep to the RFC and send as much as possible with icmp6 error messages
- CVE-2020-22284: ZEP - ZigBee Encapsulation Protocol/6LoWPAN is not supported in IDF,
the netif module (zepif.c) is not included in the build, but users can still inject
the file into compilation process, implement IO interface and use this.
- zepif: Copy possibly chained output pbuf properly
- Add #define for minimum IPv6 MTU length
- pbuf: Add pbuf_copy_partial_pbuf library function
* PPPoS: Fix null-deref when processing double break packet
- pppos: fix in_tail null (espressif/esp-lwip@537c69d5)
- PPP: Add test exhibiting empty packet null-deref (espressif/esp-lwip@202a07da)
* NAPT: Fix PBUF_REF type to clone the pbuf before forwarding
- IP-FORWARD: If packet-type is PBUF_REF clone it before forwarding
- Add NAPT unit test to exercise NAT feature for both RAM and REF pbuf types
* version: Update version numbers to match 2.1.2-esp
* Update submodule: 2749568fe1...76303df238
- test/napt: Add unit test for IP forward with PBUF_REF (espressif/esp-lwip@76303df2)
- napt: Fix PBUF_REF type to clone the pbuf before forwarding (espressif/esp-lwip@39068263)
- version: Update version numbers to match 2.1.2-esp (espressif/esp-lwip@2b922919)
- pppos: fix in_tail null (espressif/esp-lwip@537c69d5)
- PPP: Add test exhibiting empty packet null-deref (espressif/esp-lwip@202a07da)
- pbuf: Add pbuf_copy_partial_pbuf library function (espressif/esp-lwip@1c9cd9c1)
- Add #define for minimum IPv6 MTU length (espressif/esp-lwip@d2dc577b)
- zepif: Copy possibly chained output pbuf properly (espressif/esp-lwip@64ab7f2a)
- icmp6: Don't copy too much data (espressif/esp-lwip@4a64731b)
- icmp6: Fix copying of chained pbuf in reply (espressif/esp-lwip@7c822ff4)
- icmp6: keep to the RFC and send as much as possible with icmp6 error messages (espressif/esp-lwip@29100ab6)
- dns: Add API to clear dns cache (espressif/esp-lwip@ee59f77d)
- CI: Fixed adding gitlab key (espressif/esp-lwip@5a2bdba7)
- test case: modify test case test_tcp_new_max_num_remove_FIN_WAIT_1 (espressif/esp-lwip@6b090f7d)
Closes https://github.com/espressif/esp-idf/issues/8300
Closes https://github.com/espressif/esp-idf/issues/8451
mask_get_id and gpio_hal_iomux_func_sel were called while cache
is disabled, but were not inlined as expected at -0O.
Force these functions to always be inlined.
These were called from IRAM context where the caller expect them to be inlined
and accessible when cache is disabled. This was not the case when compiled with -O0.
Closes https://github.com/espressif/esp-idf/issues/8301
While using esp_wifi_set_config, flag pmf_capable defaults to 0.
Users may not bother to enable it, which prevents connection to a
WPA3 AP. Or the AP may reset into WPA3 mode failing the re-connection.
To ensure better security, deprecate the pmf_capable flag and set it to
true internally.
This commit updates the USB Host Library as follows:
- usb_helpers.h
- Removed dependency on USB Host Library API
- Added function to print string descriptors
- usbh
- Fixed bug where an interface/endpoint could be claimed/allocated multiple times
- Removed redundant device ref_count change
- Added unit test for USB Host Library API usage
This commit updates the Hub Driver and USBH as follows:
- Updated communication mechanism between Hub Driver and USBH
- USBH notifies the Hub Driver via Hub request callback (usbh_hub_req_cb_t)
- Hub Driver notifies the USBH via usbh_hub_pass_event()
- Hub Driver now defers all event handling to hub_process.
- Hub Driver and USBH will now automatically recover the port after a disconnected
device has been closed.
- Fixed incorrect assert in usbh_dev_close()
Hub Driver is refactored as follows:
This commit update and refactors the Hub Driver as follows:
- Refactored enumeration state machine and stage functions
- Enumeration stage is now incremented
- Combined transfer stages of enumeration into common functions
- Comments updated
- Fixed usbh_hal_disable_debounce_lock() that would cause root_port_handle_events()
to fail the HCD_PORT_CMD_RESET call because the previous port connection interrupt
was not cleared.
The following features were added to the Hub Driver
- Enumeration config descriptor is now fetched in two separate stages
- Header is fetched first to determine the wTotalLength of the descriptor
- Fetching the full descriptor will request exactly wTotalLength bytes
- This works around some non-compliant devices that will babble/return zero
when requesting a length > wTotalLength
- Closes https://github.com/espressif/esp-idf/issues/7799
- Enumeration now stores string descriptors
- The Manufacturer, Product, and Serial Number string descriptors are
now read and stored during enumeration
- String descriptors are now part of usb_device_info_t
- Added unit test to test enumeration
This commit updates the USB Host stack to use the USB PHY driver. The
USB PHY and the OTG Controller should now both be setup/deleted using
usb_new_phy() and usb_del_phy() respectively.
- The hcd_install() now expects the USB PHY and OTG Contorller to be
already setup before it is called
- usb_host_install() now has an option to skip calling usb_del_phy() if
the user wants to setup their own USB PHY (e.g., in the case of using
and external PHY).
- CDC-ACM and MSC examples/test updated to use internal PHY
Closes https://github.com/espressif/esp-idf/issues/8061
This commit fixes the following bugs in the HCD
- HCD control pipes fill incorrect transfer size
_buffer_fill_ctrl() would fill the transfer descriptors length with
wLength instead of transfer->num_bytes. Therefore, the remaining length
would be incorrect when a control transfer requests more bytes than are
available.
- Fix USB_TRANSFER_FLAG_ZERO_PACK behavior
The previous behavior of USB_TRANSFER_FLAG_ZERO_PACK was incorrect, and did not
support interrupt pipes. A zero length packet can now be added to Bulk/Interrupt
OUT transfers where the length is a multiple of the endpoint's MPS.
- Fixed HCD port suspend and resume test case
Halting a control pipe mid control transfer can lead some test devices to get stuck
Avoid adding one extra fade cycle when performing a one-time duty update.
Add some notes to ledc_get_duty and ledc_update_duty APIs, so that users
are aware of when the new duty will be effective.
Closes https://github.com/espressif/esp-idf/issues/7288
(cherry picked from commit e175086226)
Closes https://github.com/espressif/esp-idf/issues/5571
Fix the bug that if the API was called from one core to free the interrupt source on the other core, it would trigger interrupt watchdog.
(cherry picked from commit 0e8286c57b)
As ESP32C3 does not have support for REF_TICK source clock, it is now not
possible to select it anymore.
Auto cfg clock has been improved for all boards.
Add following bugfixes
1. Station not able to connect when WPS pin is pressed first on AP.
2. PBC overlap getting detected for selected registrar PIN APs.
3. Station not considering authorised MACs for PIN method.
4. For PIN methodm If no AP is found, station will loop through
APs in its vicinity and try to do WPS with them one by one till
WPS timeout occurs. This is for some APs which do not set
selected registrar correctly.
Initial version of freemodbus master port files have been added to ESP-IDF based on https://github.com/armink/FreeModbus_Slave-Master-RTT-STM32.
The overall repository license, at the time of adding these files, has been BSD 3-clause. However at that time, several port files carried LGPL license headers. As the author of these files confirmed in https://github.com/armink/FreeModbus_Slave-Master-RTT-STM32/issues/61#issuecomment-977828450, this wasn't intentional. ESP-IDF version of modbus master port has been rewritten to target FreeRTOS instead of RT-Thread, but the license headers remained from the original version. This commit corrects this, replacing the license of these files with BSD 3-clause.
Calling "open" in CHECK_AND_CALL sets a perfectly correct errno.
There is no need to overwrite that with a value of ENOENT, since doing
so hides lower level errors like EIO.
Closes https://github.com/espressif/esp-idf/pull/8036
...and all their callers.
With the upcoming switch from sizeof(time_t)==4 to sizeof(time_t)==8,
sizeof(struct stat) is also increasing.
A few newlib functions present in ROM allocate 'struct stat' on the
stack and call _fstat_r on this structure. The implementation of
fstat is provided in ESP-IDF. This implementation will often do
memset(st, 0, sizeof(*st)), where st is 'struct stat*', before setting
some fields of this structure. If IDF is built with sizeof(st)
different from sizeof(st) which ROM was built with, this will lead
to an out-of-bounds write and a stack corruption.
This commit removes problematic ROM functions from the linker script.
Here are the functions which allocate 'struct stat':
* _isatty_r (in ROM)
* __swhatbuf_r, called by __smakebuf_r, called by __swsetup_r and
__srefill_r (in ROM)
* _fseeko_r (not in ROM)
* glob2 (not in ROM)
* _gettemp (not in ROM)
As a result, these functions are used from libc.a, and use correct
size of 'stat' structure.
Closes https://github.com/espressif/esp-idf/issues/7980
- Fixed logs expecting different format specifier
- Updated ignore list for check_public_header test
- Updated functions ported from mbedTLS
- Fix for make-system build errors
- Removed code regarding MBEDTLS_DYNAMIC_FREE_PEER_CERT
(config was kept for backward compatibility)
- Combined mbedTLS v2.28.x related options under a separate Kconfig menu
- For the wifi_prov_mgr example in release mode (with NDEBUG defined -
assertions disabled), the task to stop provisioning is never started
as it is voided by the assert function it is called in.
Closes https://github.com/espressif/esp-idf/issues/8309
fix: re-enabled fatfs r/w test on sdspi
fix: copyright notice
add: pin definitions for esp32c3
fix: Changed fixed spi dma channel to a macro definition
docs: Update incorrect pins for S3 documentation, set a default value for future targets, and remove line breaks inside paragraphs (backport v4.4)
See merge request espressif/esp-idf!16367
export PYTHONPATH="$IDF_PATH/tools:$IDF_PATH/tools/ci/python_packages"
python -m pip install -r $IDF_PATH/tools/ci/python_packages/ttfw_idf/requirements.txt
It helps to fix the ModuleNotFoundError issue with ttfw_idf and tiny_test_fw modules.
Closes https://github.com/espressif/esp-idf/issues/7815
- Check if pip is installed for sys.executable before attempting to
create the virtual environment, bail out with an error if not.
- Don't pass --seeder argument to virtualenv if its version is
too old. For example, on Ubuntu 18.04, virtualenv 15.1.0 doesn't
support this argument.
- Pass --python argument to virtualenv to request specific interpreter
to be used.
Closes https://github.com/espressif/esp-idf/issues/8045
Some tests check if certain files are rebuilt when source files are
'touch'ed. With ccache, 'touch'ing source files doesn't cause a
rebuild, hence the test fails. In case IDF_CCACHE_ENABLE was set in
the environment, unset it before starting the tests.
This commit refactors the FreeRTOS documentation as follows:
- Rewrite FreeRTOS SMP changes document (ESP-IDF FreeRTOS SMP)
- Reorganized sections in kernel behavior changes
- Rewrote descriptions of each kernel behavior changes
- Added notes about using ESP-IDF FreeRTOS for single core targets
- Moved TLSP callback section to FreeRTOS Additions document
- Moved FreeRTOS configuration section to FreeRTOS API document
- Added notes about FreeRTOS applications in ESP-IDF
- add missing Wi-Fi header MD5 checks for esp32c3, esp32s3
- check PHY libraries for references to ets_printf, in addition to
checking Wi-Fi libraries. This used to happen until libphy.a was
moved into a separate submodule.
Reported in https://github.com/espressif/esp-phy-lib/issues/3
time we can't find old device to be replaced,then this can cause crash. So we need
to change the way to malloc the new device or replace the old in the list.
Reason:
For example, if an url is lack of leading 'http:' by mistake, it causes to http_parser_parse_url() cannot parse http host item,
and then pass the null host pointer to _get_host_header(), crash happens.
Fix:
http added null pointer check now.
Closes https://jira.espressif.com:8443/browse/ESPAT-953
xPortStartScheduler calls vPortSetupTimer -> _frxt_tick_timer_init,
which enables tick timer interrupt and sets up the first timeout.
From that point on, the interrupt can fire. If the interrupt happens
while _frxt_dispatch is running, the scheduler will enter an infinite
loop. This is because _frxt_dispatch isn't supposed to be preemptable,
and the tick interrupt will overwrite some of the registers used by
_frxt_dispatch.
Note that this situation doesn't practically occur on the real
hardware, where the execution of vPortSetupTimer and _frxt_dispatch
happens quickly enough. However it can be reproduced on an emulator
if the tick period is set to 1ms.
Add an explicit call to portDISABLE_INTERRUPTS in xPortStartScheduler
to guarantee that _frxt_dispatch doesn't run with interrupts enabled.
This is similar to the esprv_intc_int_set_threshold(1); call in
RISC-V version of port.c.
Current issue: output reports sent by Windows not received.
The report characteristic declaration should also support write without
response as specified by HIDS profile:
See https://www.bluetooth.com/specifications/GATT/ (page 14)
This bugfix contains 3 fixes:
1. .rtc_dummy section is removed (not needed for C3)
2. .rtc_text section is padded with 16B for possible CPU prefetch
3. .rtc_text section is aligned to 4B boundary to comply with PMS Memprot requirements
[Coexistence]: fixed BLE scannable extended adv performance issue in case of Wi-Fi coexistence(backport v4.4)
See merge request espressif/esp-idf!16476
Fix a bug that could return a chunk of memory smaller than requested,
easily leading to a memory corruption, when the required memory alignment
passed to the allocator is 4.
This commit adds missing INCLUDE_ configurations to FreeRTOSConfig.h for
the following functions:
- xTaskAbortDelay()
- xTaskGetHandle()
Unit tests for these functions were also added.
Closes https://github.com/espressif/esp-idf/issues/7902
* Adds implementations of __{atomic,sync}_nand_fetch_n. These builtins
were implemented for other operations but were not defined for NAND.
* Adds implementation of __atomic_OP_fetch_n for all OPs.
* Adds implementation of __sync_OP_and_fetch_n for all OPs.
Reported in https://github.com/espressif/arduino-esp32/issues/5948
1. fix(pp): fix fragment plt loss when 2td pn compare with 1th pn
2. pmf allow keyindex in big endian format to workaround faulty APs
3. docs: update miswritten and abbreviated words and syntax errors for initialize WiFi section in esp_wifi.h header file
4. allow for minimal scope of wifi_init_config_t
ADC calibration scheme and algorithm are not changed. Only the eFuse bit BLOCK1_VERSION is changed. This MR updated the logic to recognize the adc efuse version
"can set sleep wake stub from stack in RTC RAM" would randomly fail on S3 due to stack overflow.
Fixed wrong usage of stack size and slightly increased it.
1. Fix FTM failures after repeated operations
2. Update Mexico channel refer to FCC
3. Mesh: fix the issue that layer2 node connect to lower-layer node when FIXED-ROOT root disappeared
4. Decouple softap and 8684 support
lw-ip: Update LWIP_DHCP_OPTIONS_LEN default value when LWIP_DHCP_DISABLE_VENDOR_CLASS_ID disabled(backport v4.4)
See merge request espressif/esp-idf!16253
In commit de22f3a4e5, combination of
hardware and software MPI (bignum) related approach was used to
work around chip (e.g. ESP32-C3) limitation of max 3072 bits support.
This was done using linker "--wrap" flag but since the relevant API is
being used in same translation (compilation unit), hardware mode was not
getting used in some cases (e.g., RSA key generation).
This commit modified internal mbedTLS API and makes software+hardware
combination deterministic.
The release of the semaphore indicating the item was successfully sent must be the last semaphore released. The receiver may be in another task and may delete the Ringbuffer (such as with a return code across tasks design pattern) if they are through with the Ringbuffer.
The function xRingbufferSendAcquire followed by xRingbufferSendComplete had the semaphores released in the proper order and that same pattern should have been used in xRingbufferSend and xRingbufferSendFromISR. This commit fixes this order.
Issue (IDFGH-6030) #7716 describes the problem in more detail.
Closes IDFGH-6030, https://github.com/espressif/esp-idf/issues/7716
Closes IDFGH-6036, https://github.com/espressif/esp-idf/pull/7721
ringbuf: Fix bug where comparision between a signed and unsigned operand resulted in incorrect free size for no-split/allow-split buffers (v4.4)
See merge request espressif/esp-idf!15881
This function resets the spinlock given as a parameter after taking it
(when entering the critical section). This then results in a panic once
it tries to exit the same critical section.
* Closes https://github.com/espressif/esp-idf/issues/7725
When building with BOOTLOADER_LOG_LEVEL lesser then VERBOSE, an error
code variable was being set but not consumed, resulting in a compiler
warning.
Signed-off-by: Gustavo Henrique Nihei <gustavo.nihei@espressif.com>
Builds for every chip other than ESP32 resulted in a compiler warning
due to "drom_load_addr_aligned" and "irom_load_addr_aligned" not being
used, besides being possible to actually reuse them.
Furthermore, extended the logic for the other similar variables.
Signed-off-by: Gustavo Henrique Nihei <gustavo.nihei@espressif.com>
This issue was earlier fixed in commit 79e74e5d5f
but during migration to newer FreeRTOS release, it got introduced again.
This commit fixes thread safety issues with configASSERT() calls
regarding the value of uxSchedulerSuspended. A false negative
occurs if a context switch to the opposite core occurs in between
the getting the core ID and the assesment.
Relevant https://github.com/espressif/esp-idf/issues/4230
Closes https://github.com/espressif/esp-idf/issues/7726
Closes IDFGH-6041
When the build runner has a local git mirror configured via
LOCAL_GIT_MIRROR variable, use that mirror when cloning IDF insider
the docker build job. Follows similar logic for
LOCAL_GITLAB_HTTPS_HOST, which is used for geo nodes.
The body of the bootloader_debug_buffer function was conditioned to
macros that were never defined, resulting in deactivated code.
Signed-off-by: Gustavo Henrique Nihei <gustavo.nihei@espressif.com>
For the CID10564,10384,10280,10098,10038,The memory was released in other place.
For the CID10365,it release the memory in the function when sent successfully.
For the CID10268,10011, we need not change the code.
Add TRY_ENTRY_CRITICAL() API to all for timeouts when entering critical sections.
The following port API were added:
- portTRY_ENTER_CRITICAL()
- portTRY_ENTER_CRITICAL_ISR()
- portTRY_ENTER_CRITICAL_SAFE()
Deprecated legacy spinlock API in favor of spinlock.h. The following API were deprecated:
- vPortCPUInitializeMutex()
- vPortCPUAcquireMutex()
- vPortCPUAcquireMutexTimeout()
- vPortCPUReleaseMutex()
Other Changes:
- Added portMUX_INITIALIZE() to replace vPortCPUInitializeMutex()
- The assembly of the critical section functions ends up being about 50 instructions longer,
thus the spinlock test pass threshold had to be increased to account for the extra runtime.
Closes https://github.com/espressif/esp-idf/issues/5301
During the early start, the virtual eFuse mode can call erase operations when OS is not yet running.
Possible workaround: CONFIG_SPI_FLASH_YIELD_DURING_ERASE=n
Fixed for the legacy flash driver as well.
This prevents the compiler error for the implicit declaration of
function "esp_rom_printf".
Signed-off-by: Gustavo Henrique Nihei <gustavo.nihei@espressif.com>
With strict debugging, i.e. `Set-PSDebug -strict`, execution of export.ps1 will
report the following error:
```
The variable '$envars_array' cannot be retrieved because it has not been set.
At C:\path\to\export.ps1:15 char:1
+ $envars_array # will be filled like:
+ ~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (envars_array:String) [], RuntimeException
+ FullyQualifiedErrorId : VariableIsUndefined
```
Closes https://github.com/espressif/esp-idf/pull/7819
This commit updates the USB Host Library API in the following wasy:
- usb_host_client_handle_t and usb_device_handle_t made into struct pointers
to generate compiler warnings about conflicting handle types
- usb_host_client_config_t changed to future proof API for Synchronous Clients
- Added usb_host_lib_unblock()
- Added usb_host_device_addr_list_fill()
- Return of usb_host_device_free_all() updated to indicate whether there
are still devices yet to be freed.
- Blockg APIs are now marked explicitly
- Fixed a bug in usb_host_transfer_submit_control() when checking the bEndpointAddress
of a control transfer.
Tests are also refactored to move some common macros into shared headers
Closes https://github.com/espressif/esp-idf/issues/7786
This commit fixes how the USBH handling of a sudden device disconnection,
more specifically handling of device gone.
- Previously the USBH would only halt, flush, and dequeue the device's
default EP, then send a device gone event to the Host Library layer.
- Now the USBH will also halt and flush all non-default EPs, allowing
all of the URBs to be dequeud.
- Some internal object members are now protected by a mutex instead of
a spinlock.
Closes https://github.com/espressif/esp-idf/issues/7505
This commit fixes how the USB Host HCD handles sudden disconnections.
Bugs:
- HW channels remain active when the port suddenly disconnects, and
previously the channel would be disabled by setting the disabled bit,
then waiting for a disabled interrupt. However, ISOC channels do not
generate the disabled interrupt when the port is invalid, thus leading
to tasks getting indefinitely blocked in hcd_pipe_command().
Fix:
On a sudden disconnection, forcibly treat all channels as halted even
if their HCCHAR.ChEna bit is still set. We do a soft reset after a port
error anyways, so the channels will eventually be reset.
Closes https://github.com/espressif/esp-idf/issues/7505
This commit addes the 8/16 bit register field access workarounds to
the DWC_OTG peripheral. This workaround was applied to all other
peripherals in commit 874a720286.
The previous SMP freertos round robin would skip over tasks when
time slicing. This commit implements a Best Effort Round Robin
where selected tasks are put to the back of the list, thus
makes the time slicing more fair.
- Documentation has been updated accordingly.
- Tidy up vTaskSwitchContext() to match v10.4.3 more
- Increased esp_ipc task stack size to avoid overflow
Closes https://github.com/espressif/esp-idf/issues/7256
This commit removes the following critical nested macros as follows:
- portENTER_CRITICAL_NESTED()
- portEXIT_CRITICAL_NESTED()
They are replaced with portSET_INTERRUPT_MASK_FROM_ISR() and
portCLEAR_INTERRUPT_MASK_FROM_ISR() which are the proper FreeRTOS interfaces.
Created a portmacro_deprecated.h for each port to contain deprecated API
that were originally from portmacro.h
This commit fixes a bug in no-split and allow-split ring buffers free buffer size calculation.
When the free size available in the buffers less than the size of one item header,
the function prvGetCurMaxSizeNoSplit/AllowSplit() incorrectly returned the maxItemSize instead of 0.
This is due to the comparision between a negative and a positive value
where both operands are treated as unsigned during the comparision operation,
thereby treating the negative operand as a large integer.
Also added new unit tests to test buffer-full and almost-full conditions
where this scenario is likely to be hit.
Closes https://github.com/espressif/esp-idf/issues/7344
Closes https://github.com/espressif/esp-idf/pull/7371
FATFS provides a disk status and disk initialize callback which were not
implemented. Implementation has very low impact on SD/MMC speed and
fixes issues, when trying to open file when SD card was removed from
slot and not deinited.
If disk_status returns STA_NOINIT, it will always continue with
disk_initialize. If that returns 0, it will continue like everything is
working normally. So there has to be the same check as in disk_status.
Return of disk_initialize is always checked like this for STA_NOINIT or
STA_PROTECT so if command fails, we return the STA_NOINIT.
stat = disk_initialize(pdrv);
if (stat & STA_NOINIT) return FR_NOT_READY;
if (stat & STA_PROTECT) return FR_WRITE_PROTECTED;
Closes IDF-4125
This commit fixes issue where empty (unprogrammed) digest slot out of
multiple supported (e.g. 3 for ESP32-C3) could cause issue in
workflow enablement process.
Notes:
1. This issue was applicable for chips supporting "secure-boot-v2"
scheme with multiple digests slots
2. This issue was affecting only manual workflow, where digest of
public was pre-flashed in efuse
3. Change in "flash_encrypt.c" is only for additional safety purpose
Increase reset assertion time from 100µs (as specified minimum in the datasheet) to 150µs.
Some specimen of the LAN8720 need the reset signal asserted longer than 100µs to initialise properly. Otherwise they are in a zombie state where they are establishing and loosing an Ethernet link once in a seconds interval.
Tokenizing data by '\n' will effectively replace all LF characters by '\0' so checking for phantom lines has to be adjusted:
* minimal empty line is CR only (strlen = 1)
* checking for lines containing CR only
This commit adds the following hook functions to obtain memory
for the IDLE and Timer Daemon tasks when configSUPPORT_STATIC_ALLOCATION
is enabled:
- vApplicationGetIdleTaskMemory()
- vApplicationGetTimerTaskMemory()
Currently, both functions simply allocate from the same memory as
regular tasks (i.e., internal memory for both the stack and TCB)
Closes https://github.com/espressif/esp-idf/issues/7511
esp_restart()/panic_restart() never resets the Digital system (so far required only by the Memprot feature) as there's a typo in the corresponding #define:
it checks CONFIG_ESP_SYSTEM_CONFIG_MEMPROT_FEATURE instead of CONFIG_ESP_SYSTEM_MEMPROT_FEATURE.
Issue fixed.
IDF-4094
The issue is related to the non-sequential way of description when
such fields going together sequential.
Related to esp32h2 chip for eFuses: MAC_FACTORY and MAC_EXT.
The issue is in wrong indexes of MAC_EXT.
MAC_EXT got indexes like it is joined to MAC_FACTORY.
const esp_efuse_desc_t* ESP_EFUSE_MAC_FACTORY[] = {
&MAC_FACTORY[0],
&MAC_FACTORY[1],
&MAC_FACTORY[2],
&MAC_FACTORY[3],
&MAC_FACTORY[4],
&MAC_FACTORY[5],
NULL
};
const esp_efuse_desc_t* ESP_EFUSE_MAC_EXT[] = {
&MAC_EXT[6],
&MAC_EXT[7],
NULL
};
This commit fixed it to:
const esp_efuse_desc_t* ESP_EFUSE_MAC_EXT[] = {
&MAC_EXT[0],
&MAC_EXT[1],
NULL
};
esp_http_client: Fix HEAD request will affect the all next HTTP requests unless we close the HTTP request(backport v4.4)
See merge request espressif/esp-idf!15715
In 4972605, high-level interrupt handler hook was renamed from
ld_include_highint_hdl to ld_include_panic_highint_hdl. However the
change wasn't applied in GNU Make based build system. As a result,
the default interrupt handler was linked and features which depended
on the high-level interrupt didn't work.
Closes https://github.com/espressif/esp-idf/issues/7759
Closes https://github.com/espressif/esp-idf/issues/7447
Switching back from data (PPP) mode to command mode must be done is the following sequence:
* No characters entered for T1 time (1 second)
* "+++" characters entered with no characters in between (1 second)
* No characters entered for T1 timer (1 second)
(per specification of SIM800 SIM800_Series_AT_Command_Manual_V1.09.pdf)
Related https://github.com/espressif/esp-idf/issues/7608
Regression from e68afcb45036901ebc9174b2c8f3804f7921410c causing
non-clean builds for standard asio-ssl example (warning was
suppressed in the CI build only)
In esp_dte_handle_line(), it tokenize the data to call handlers separately
for each *line*. So it needs to post the tokenized data when report unknown
line instead of the first token (which could be a '\r' in my test).
Fixes: 336de29413 ("Examples/pppos_client: Fix manual parsing to accept unexpected lines")
Signed-off-by: Axel Lin <axel.lin@gmail.com>
2021-10-18 10:14:31 +08:00
14089 changed files with 1170308 additions and 1543952 deletions
description:Before submitting a new issue, please follow the checklist and try to find the answer.
options:
- label:I have read the documentation [ESP-IDF Programming Guide](https://docs.espressif.com/projects/esp-idf/en/latest/) and the issue is not addressed there.
required:true
- label:I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
required:true
- label:I have searched the issue tracker for a similar issue and not found a similar issue.
required:true
- type:input
id:idf_version
attributes:
label:IDF version.
description:Onwhich IDF version does this issue occur on? Run `git describe --tags` to find it.
placeholder:ex. v3.2-dev-1148-g96cd3b75c
validations:
required:true
- type:dropdown
id:operating_system
attributes:
label:Operating System used.
multiple:false
options:
- Windows
- Linux
- macOS
validations:
required:true
- type:dropdown
id:build
attributes:
label:How did you build your project?
multiple:false
options:
- Command line with Make
- Command line with CMake
- Command line with idf.py
- Eclipse IDE
- CLion IDE
- VS Code IDE
- Other (please specify in More Information)
validations:
required:true
- type:dropdown
id:windows_comand_line
attributes:
label:If you are using Windows, please specify command line type.
multiple:false
options:
- PowerShell
- CMD
validations:
required:false
- type:textarea
id:expected
attributes:
label:What is the expected behavior?
description:Please provide a clear and concise description of the expected behavior.
placeholder:I expected it to...
validations:
required:true
- type:textarea
id:actual
attributes:
label:What is the actual behavior?
description:Please describe actual behavior.
placeholder:Instead it...
validations:
required:true
- type:textarea
id:steps
attributes:
label:Steps to reproduce.
description:'How do you trigger this bug? Please walk us through it step by step. If this is build bug, please attach sdkconfig file (from your project folder). Please attach your code here.'
value:|
1. Step
2. Step
3. Step
...
validations:
required:true
- type:textarea
id:debug_logs
attributes:
label:Build or installation Logs.
description:Build or installation log goes here, should contain the backtrace, as well as the reset source if it is a crash.
placeholder:Your log goes here.
render:plain
validations:
required:false
- type:textarea
id:more-info
attributes:
label:More Information.
description:Do you have any other information from investigating this?
placeholder:ex. I tried on my friend's Windows 10 PC and the command works there.
description:Before submitting a new issue, please follow the checklist and try to find the answer.
options:
- label:I have read the documentation [ESP-IDF Programming Guide](https://docs.espressif.com/projects/esp-idf/en/latest/) and the issue is not addressed there.
required:true
- label:I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
required:true
- label:I have searched the issue tracker for a similar issue and not found a similar issue.
required:true
- type:input
id:idf_version
attributes:
label:IDF version.
description:Onwhich IDF version does this issue occur on? Run `git describe --tags` to find it.
placeholder:ex. v3.2-dev-1148-g96cd3b75c
validations:
required:true
- type:input
id:chip_revision
attributes:
label:Espressif SoC revision.
description:Onwhich Espressif SoC revision does your application run on? Run `esptool chip_id` to find it.
placeholder:ex. ESP32-C3 (QFN32) (revision v0.3)
validations:
required:true
- type:dropdown
id:operating_system
attributes:
label:Operating System used.
multiple:false
options:
- Windows
- Linux
- macOS
validations:
required:true
- type:dropdown
id:build
attributes:
label:How did you build your project?
multiple:false
options:
- Command line with Make
- Command line with CMake
- Command line with idf.py
- Eclipse IDE
- CLion IDE
- VS Code IDE
- Other (please specify in More Information)
validations:
required:true
- type:dropdown
id:windows_comand_line
attributes:
label:If you are using Windows, please specify command line type.
multiple:false
options:
- PowerShell
- CMD
validations:
required:false
- type:input
id:devkit
attributes:
label:Development Kit.
description:Onwhich Development Kit does this issue occur on?
* We welcome any ideas or feature requests! It’s helpful if you can explain exactly why the feature would be useful.
* There are usually some outstanding feature requests in the [existing issues list](https://github.com/espressif/esp-idf/labels/Type%3A%20Feature%20Request), feel free to add comments to them.
* If you would like to contribute, please read the [contributions guide](https://docs.espressif.com/projects/esp-idf/en/stable/esp32/contribute/index.html).
- type:textarea
id:problem-related
attributes:
label:Is your feature request related to a problem?
description:Please provide a clear and concise description of what the problem is.
placeholder:ex. I'm always frustrated when ...
- type:textarea
id:solution
attributes:
label:Describe the solution you'd like.
description:Please provide a clear and concise description of what you want to happen.
placeholder:ex. When connecting to an Espressif chip ...
- type:textarea
id:alternatives
attributes:
label:Describe alternatives you've considered.
description:Please provide a clear and concise description of any alternative solutions or features you've considered.
placeholder:ex. Choosing other approach wouldn't work, because ...
- type:textarea
id:context
attributes:
label:Additional context.
description:Please add any other context or screenshots about the feature request here.
description:Before submitting a new issue, please follow the checklist and try to find the answer.
options:
- label:I have read the documentation [ESP-IDF Programming Guide](https://docs.espressif.com/projects/esp-idf/en/latest/) and the issue is not addressed there.
required:true
- label:I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
required:true
- label:I have searched the issue tracker for a similar issue and not found a similar issue.
**Reminder: If your issue is a general question, starts similar to "How do I..", or is related to 3rd party development kits/libs, please discuss this on our community forum at https://esp32.com instead.**
INSTRUCTIONS
============
Before submitting a new issue, please follow the checklist and try to find the answer.
- [ ] I have read the documentation [ESP-IDF Programming Guide](https://docs.espressif.com/projects/esp-idf/en/latest/) and the issue is not addressed there.
- [ ] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
- [ ] I have searched the issue tracker for a similar issue and not found a similar issue.
If the issue cannot be solved after the steps before, please follow these instructions so we can get the needed information to help you in a quick and effective fashion.
1. Fill in all the fields under **Environment** marked with [ ] by picking the correct option for you in each case and deleting the others.
2. Describe your problem.
3. Include [debug logs from the "monitor" tool](https://docs.espressif.com/projects/esp-idf/en/latest/api-guides/tools/idf-monitor.html), or [coredumps](https://docs.espressif.com/projects/esp-idf/en/latest/api-guides/core_dump.html).
4. Providing as much information as possible under **Other items if possible** will help us locate and fix the problem.
5. Use [Markdown](https://guides.github.com/features/mastering-markdown/) (see formatting buttons above) and the Preview tab to check what the issue will look like.
6. Delete these instructions from the above to the below marker lines before submitting this issue.
**IMPORTANT: If you do not follow these instructions and provide the necessary details, your issue may not be resolved.**
The main development is done in Espressif Gitlab project.
Espressif [GitHub project espressif/esp-idf](https://github.com/espressif/esp-idf) is only a public mirror.
Therefore, all changes and updates to DangerJS files (`.github/dangerjs`) must be made via MR in the **Gitlab** repository by Espressif engineer.
When adding a new Danger rule or updating existing one, might be a good idea to test it on the developer's fork of GitHub project. This way, the new feature can be tested using a GitHub action without concern of damaging Espressif's GitHub repository.
Danger for Espressif GitHub is implemented in TypeScript. This makes the code more readable and robust than plain JavaScript.
Compilation to JavaScript code (using `tsc`) is not necessary; Danger handles TypeScript natively.
A good practice is to store each Danger rule in a separate module, and then import these modules into the main Danger file `.github/dangerjs/dangerfile.ts` (see how this is done for currently present modules when adding a new one).
If the Danger module (new check/rule) uses an external NPM module (e.g. `axios`), be sure to add this dependency to `.github/dangerjs/package.json` and also update `.github/dangerjs/package-lock.json`.
In the GitHub action, `danger` is not installed globally (nor are its dependencies) and the `npx` call is used to start the `danger` checks in CI.
## Adding new Danger rule
For local development you can use following strategy
#### Install dependencies
```sh
cd .github/dangerjs
npm install
```
(If the IDE still shows compiler/typing errors, reload the IDE window.)
#### Add new code as needed or make updates
#### Test locally
Danger rules can be tested locally (without running the GitHub action pipeline).
To do this, you have to first export the ENV variables used by Danger in the local terminal:
👋 **Hi ${authorLogin}**, thank you for your another contribution to \`espressif/esp-idf\` project!
If the change is approved and passes the tests in our internal git repository, it will appear in this public Github repository on the next sync.
***
`;
constmessageFirstContributor: string=`
***
👋 **Welcome ${authorLogin}**, thank you for your first contribution to \`espressif/esp-idf\` project!
📘 Please check [Contributions Guide](https://docs.espressif.com/projects/esp-idf/en/latest/esp32/contribute/index.html#contributions-guide) for the contribution checklist, information regarding code and documentation style, testing and other topics.
🖊️ Please also make sure you have **read and signed** the [Contributor License Agreement for espressif/esp-idf project](https://cla-assistant.io/espressif/esp-idf).
#### Pull request review and merge process you can expect
Espressif develops the ESP-IDF project in an internal repository (Gitlab). We do welcome contributions in the form of bug reports, feature requests and pull requests via this public GitHub repository.
1. An internal issue has been created for the PR, we assign it to the relevant engineer
2. They review the PR and either approve it or ask you for changes or clarifications
3. Once the Github PR is approved, we synchronize it into our internal git repository
4. In the internal git repository we do the final review, collect approvals from core owners and make sure all the automated tests are passing
- At this point we may do some adjustments to the proposed change, or extend it by adding tests or documentation.
5. If the change is approved and passes the tests it is merged into the \`master\` branch
6. On next sync from the internal git repository merged change will appear in this public Github repository
***
`;
/**
* Check whether the author of the pull request is known or a first-time contributor, and add a message to the PR with information about the review and merge process.
- [Manifest File to Control the Build/Test apps](#manifest-file-to-control-the-buildtest-apps)
- [Grammar](#grammar)
- [Special Rules](#special-rules)
- [Upload/Download Artifacts to Internal Minio Server](#uploaddownload-artifacts-to-internal-minio-server)
- [Users Without Access to Minio](#users-without-access-to-minio)
- [Users With Access to Minio](#users-with-access-to-minio)
- [Env Vars for Minio](#env-vars-for-minio)
- [Artifacts Types and File Patterns](#artifacts-types-and-file-patterns)
- [Upload](#upload)
- [Download](#download)
## General Workflow
@@ -55,7 +45,6 @@
-`custom_test[_esp32/esp32s2/...]`
-`docker`
-`docs`
-`docs_full`, triggers a full docs build, regardless of files changed
-`example_test[_esp32/esp32s2/...]`
-`fuzzer_test`
-`host_test`
@@ -65,11 +54,13 @@
-`macos_test`
-`nvs_coverage`
-`submodule`
-`unit_test[_esp32/esp32s2/...]`
-`weekend_test`
-`windows`
There are two general labels (not recommended since these two labels will trigger a lot of jobs)
-`target_test`: includes all target for `example_test`, `custom_test`, `component_ut`, `integration_test`
-`target_test`: includes all target for `example_test`, `custom_test`, `component_ut`,`unit_test`,`integration_test`
-`all_test`: includes all test labels
### How to trigger a `detached` pipeline without pushing new commits?
@@ -117,7 +108,7 @@ curl -X POST --header "PRIVATE-TOKEN: [YOUR PERSONAL ACCESS TOKEN]" [GITLAB_SERV
```yaml
check_docs_lang_sync:
extends:
- .pre_check_template
- .pre_check_job_template
- .rules:build:docs
script:
- cd docs
@@ -145,11 +136,10 @@ check if there's a suitable `.if-<if-anchor-you-need>` anchor
1. if there is, create a rule following [`rules` Template Naming Rules](#rules-template-naming-rules).For detail information, please refer to [GitLab Documentation `rules-if`](https://docs.gitlab.com/ee/ci/yaml/README.html#rulesif). Here's an example.
```yaml
.rules:patterns:python-files:
.rules:dev:
rules:
- <<: *if-protected
- <<: *if-trigger
- <<: *if-dev-push
changes: *patterns-python-files
```
2. if there isn't
@@ -198,7 +188,7 @@ if a name has multi phrases, use `-` to concatenate them.
-`target_test`
a combination of `example_test`, `custom_test`, `component_ut`, `integration_test` and all targets
a combination of `example_test`, `custom_test`,`unit_test`,`component_ut`, `integration_test` and all targets
#### `rules` Template Naming Rules
@@ -233,93 +223,3 @@ To run these commands in shell script locally, place `source tools/ci/utils.sh`
-`info`: log in green color
-`run_cmd`: run the command with duration seconds info
-`retry_failed`: run the command with duration seconds info, retry when failed
## Manifest File to Control the Build/Test apps
`.build-test-rules.yml` file is a manifest file to control if the CI is running the build and test job or not. The Supported Targets table in `README.md` for apps would be auto-generated by `pre-commit` from the app's `.build-test-rules.yml`.
### Grammar
We're using the latest version of [idf-build-apps][idf-build-apps]. Please refer to their [documentation][manifest-doc]
- git diff --exit-code -- ${IDF_TARGET}/esp_efuse_table.c || { echo 'Differences found for ${IDF_TARGET} target. Please run idf.py efuse-common-table and commit the changes.'; exit 1; }
- git diff --exit-code -- ${IDF_TARGET}/esp_efuse_table.c || { echo 'Differences found for ${IDF_TARGET} target. Please run make efuse_common_table or idf.py efuse-common-table and commit the changes.'; exit 1; }
return`You are a helpful assistant that creates suggestions for single git commit message, that user can use to describe all the changes in their merge request.
Use git diff: {mrDiff} and users current commit messages: {mrCommitMessages} to get the changes made in the commit.
Output should be git commit message following the conventional commit format.
Output only git commit message in desired format, without comments and other text.
Do not include the closing statements ("Closes https://....") in the output.
Here are the strict rules you must follow:
- Avoid mentioning any JIRA tickets (e.g., "Closes JIRA-123").
- Be specific. Don't use vague terms (e.g., "some checks", "add new ones", "few changes").
- The commit message structure should be: <type><(scope/component)>: <summary>
- Types allowed: ${allowedTypes.join(", ")}
- If 'scope/component' is used, it must start with a lowercase letter.
- The 'summary' must NOT end with a period.
- The 'summary' must be between ${minimumSummaryChars} and ${maximumSummaryChars} characters long.
If a 'body' of commit message is used:
- Each line must be no longer than ${maximumBodyLineChars} characters.
- It must be separated from the 'summary' by a blank line.
`- correct format of commit message should be: \`<type/action>(<scope/component>): <summary>\`, for example \`fix(esp32): Fixed startup timeout issue\``,
`- allowed types are: \`${allowedTypes}\``,
`- sufficiently descriptive message summary should be between ${minimumSummaryChars} to ${maximumSummaryChars} characters and start with upper case letter`,
`- avoid Jira references in commit messages (unavailable/irrelevant for our customers)`,
`- follow this [commit messages guide](${process.env.DANGER_GITLAB_HOST}/espressif/esp-idf/-/wikis/dev-proc/Commit-messages)`,
];
letdangerMessage=`\n**Some issues found for the commit messages in this MR:**\n${issuesAllCommitMessages.join(
"\n"
)}
\n***
\n**Please consider updating these commit messages** - here are some basic tips:\n${basicTips.join(
"\n"
)}
\n\`TIP:\` You can install commit-msg pre-commit hook (\`pre-commit install -t pre-commit -t commit-msg\`) to run this check when committing.
\n***
`;
if(generateAISuggestion){
// Create AI generated suggestion for git commit message based of gitDiff and current commit messages
`- closing ticket \`${ticket.record}\` seems to be in the wrong format (or inaccessible to Jira DangerBot).. The correct format is for example \`- Closes JIRA-123\`.`
);
}
// Get closing GitHub issue links from JIRA tickets
`- the GitHub issue [\`${ticket.closingGithubLink}\`](${ticket.closingGithubLink}) does not seem to exist on GitHub (referenced from JIRA ticket [\`${ticket.ticketName}\`](${ticket.jiraUIUrl}) )`
);
continue;// skip the following checks
}
// Search in commit message if there are all GitHub closing links (from Related section) for still open GH issues
:"";// if the Jira ticket has an unfilled Description, the ".description" property is missing in API response - in that case set "jiraDescription" to an empty string
constdescriptionChunk=mrDescription.match(/^([^#]*)/)[1].trim();// Extract all text before the first section header (i.e., the text before the "## Release notes")
constshortMrDescriptionThreshold=50;// Description is considered too short below this number of characters
returnwarn(`The \`Release Notes\` section seems to be missing. Please check if the section header in MR description is present and in the correct markdown format ("## Release Notes").\n\nSee [Release Notes Format Rules](${wiki_link}).`);
error_output.push('`No release notes` comment shows up when there is valid entry. Remove bullets before comments in release notes section.');
}
}else{
if(!valid_entries_found){
error_output.push('The `Release Notes` section seems to have no valid entries. Add bullets before valid entries, or add `No release notes` comment to suppress this error if you mean to have no release notes.');
}
}
if(error_output.length>0){
// Paragraphs joined by double `\n`s.
error_output=[...error_output,`See [Release Notes Format Guide](${wiki_link}).`].join('\n\n');
recordRuleExitStatus(ruleName,"Failed");
returnwarn(error_output);
}
// At this point, the rule has passed
recordRuleExitStatus(ruleName,'Passed');
};
functioncheck_entry(entry){
constentry_str=`- \`${entry}\``;
constindent=" ";
if(entry.match(/no\s+release\s+note/i)){
return[entry_str,`${indent}- \`No release notes\` comment shouldn't start with bullet.`].join('\n');
}
// Remove a leading escaping backslash of the special characters, https://www.markdownguide.org/basic-syntax/#characters-you-can-escape
return[entry_str,`${indent}- Please specify the [area] to which the change belongs (see guide). If this line is just a comment, remove the bullet.`].join('\n');
}
// area is in match[2]
constdescription=match[3].trim();
letviolations=[];
if(match[1]){
violations.push(`${indent}- Release note entry should start from the beginning of line. (Nested release note not allowed.)`);
}
if(!/^[A-Z0-9]/.test(description)){
violations.push(`${indent}- Release note statement should start with a capital letter or digit.`);
constdocsFilesMR=parseMrDocsFiles(allMrFiles);// Create single object of all doc files in MR with names, paths and groups
// Both versions (EN and CN) of document found changed in this MR
for(constfileofdocsFilesMR.bothFilesInMr){
file.contentEn=awaitgetContentFileInMR(file.fileEnPath);// Get content of English file
file.linesEn=file.contentEn.split("\n").length;// Get number of lines of English file
file.contentCn=awaitgetContentFileInMR(file.fileCnPath);// Get content of Chinese file
file.linesCn=file.contentCn.split("\n").length;// Get number of lines of English file
// Compare number of lines in both versions
if(file.linesEn!==file.linesCn){
// Check if CN file is only link to EN file
if(!regexIncludeLink.test(file.contentCn)){
// if not just a link ...
partMessages.push(
`- please synchronize the EN and CN version of \`${file.fileName}\`. [\`${file.fileEnPath}\`](${file.fileUrlRepoEN}) has ${file.linesEn} lines; [\`${file.fileCnPath}\`](${file.fileUrlRepoCN}) has ${file.linesCn} lines.`
);
}
}
}
// Only Chinese version of document found changed in this MR
for(constfileofdocsFilesMR.onlyCnFilesInMr){
partMessages.push(
`- file \`${file.fileEnPath}\` doesn't exist in this MR or in the GitLab repo. Please add \`${file.fileEnPath}\` into this MR.`
);
}
// Only English version of document found in this MR
for(constfileofdocsFilesMR.onlyEnFilesInMr){
consttargetBranch=danger.gitlab.mr.target_branch;
file.contentCn=awaitgetContentFileInGitlab(
file.fileCnPath,
targetBranch
);// Try to fetch CN file from target branch of Gitlab repository and store content
if(file.contentCn){
// File found on target branch in Gitlab repository
if(!regexIncludeLink.test(file.contentCn)){
// File on Gitlab master is NOT just an ..include:: link to ENG version
`- file \`${file.fileCnPath}\` was not updated in this MR, but found unchanged full document (not just link to EN) in target branch of Gitlab repository [\`${file.fileCnPath}\`](${file.fileUrlRepoMasterCN}). Please update \`${file.fileCnPath}\` into this MR.`
);
}
}else{
// File failed to fetch, probably does not exist in the target branch
partMessages.push(
`- file \`${file.fileCnPath}\` probably doesn't exist in this MR or in the GitLab repo. Please add \`${file.fileCnPath}\` into this MR.`
);
}
}
// Create a report with found issues with documents in MR
createReport();
// At this point, the rule has passed
recordRuleExitStatus(ruleName,'Passed');
/**
* Generates an object that represents the relationships between files in two different languages found in this MR.
*
* @param {string[]} docsFilesEN - An array of file paths for documents in English.
* @param {string[]} docsFilesCN - An array of file paths for documents in Chinese.
* @returns {Object} An object with the following properties:
* - bothFilesInMr: An array of objects that represent files that found in MR in both languages. Each object has the following properties:
* - fileName: The name of the file.
* - fileEnPath: The path to the file in English.
* - fileCnPath: The path to the file in Chinese.
* - fileUrlRepoEN: The URL link to MR branch path to the file in English.
* - fileUrlRepoCN: The URL link to MR branch path to the file in Chinese.
* - onlyCnFilesInMr: An array of objects that represent files that only found in MR in English. Each object has the following properties:
* - fileName: The name of the file.
* - fileEnPath: The path to the file in English.
* - fileCnPath: The FUTURE path to the file in Chinese.
* - fileUrlRepoEN: The URL link to MR branch path to the file in English.
* - fileUrlRepoCN: The URL link to MR branch path to the file in Chinese.
* - onlyEnFilesInMr: An array of objects that represent files that only found in MR in Chinese. Each object has the following properties:
* - fileName: The name of the file.
* - fileEnPath: The FUTURE path to the file in English.
* - fileCnPath: The path to the file in Chinese.
* - fileUrlRepoEN: The URL link to MR branch path to the file in English.
* - fileUrlRepoCN: The URL link to MR branch path to the file in Chinese.
constfileContentAfter=content.after.trim();// Trim trailing new lines
returnfileContentAfter;
}catch(error){
console.error(`Error while getting file content MR: ${error}`);
returnnull;
}
}
/**
* Creates a compiled report for found documentation issues in the current MR and alerts the Documentation team if there are any "needs translation" labels present.
*
* Report if documentation labels have been added by mistake.
*/
functioncreateReport(){
constmrLabels=danger.gitlab.mr.labels;// Get MR labels
`Please remove the \`needs translation: XX\` labels. For documents that need to translate from scratch, Doc team will translate them in the future. For the current stage, we only focus on updating exiting EN and CN translation to make them in sync.`
);
}
// Docs issues found in this MR
partMessages.sort();
letdangerMessage=`Some of the documentation files in this MR seem to have translations issues:\n${partMessages.join(
"\n"
)}\n`;
if(partMessages.length){
if(!translationLabelsPresent){
dangerMessage+=`
\nWhen synchronizing the EN and CN versions, please follow the [Documentation Code](https://docs.espressif.com/projects/esp-idf/zh_CN/latest/esp32/contribute/documenting-code.html#standardize-document-format). The total number of lines of EN and CN should be same.\n
\nIf you have difficulty in providing translation, you can contact Documentation team by adding <kbd>needs translation: CN</kbd> or <kbd>needs translation: EN</kbd> labels into this MR and retrying Danger CI job. The documentation team will be automatically notified and will help you with the translations before the merge.\n`;
recordRuleExitStatus(ruleName,"Failed");
returnwarn(dangerMessage);// no "needs translation: XX" labels in MR; report issues as warn
}else{
dangerMessage+=`\nTranslation labels <kbd>needs translation: CN</kbd> or <kbd>needs translation: EN</kbd> were added - this will automatically notify the Documentation team to help you with translation issues.`;
`The source branch name \`${sourceBranch}\` contains more than one slash. This can cause troubles with git sync. Please rename the branch.`
);
}
// Check if the source branch name contains any uppercase letters
if(sourceBranch!==sourceBranch.toLowerCase()){
recordRuleExitStatus(ruleName,"Failed");
returnwarn(
`The source branch name \`${sourceBranch}\` contains uppercase letters. This can cause troubles on case-insensitive file systems (macOS). Please use only lowercase letters.`
# Compatibility Between ESP-IDF Releases and Revisions of Espressif SoCs
* [中文版](./COMPATIBILITY_CN.md)
Espressif keeps improving the performance of its SoCs by providing new chip revisions. However, some of the improvements require special software support. Some of the software supports are even mandatory for the chip revisions to run normally.
This document describes the compatibility between ESP-IDF releases and Espressif SoC revisions.
NOTE: This document on release branches may be out-of-date. Check the [Compatibility file on master](https://github.com/espressif/esp-idf/blob/master/COMPATIBILITY.md) for the most accurate information.
See [Compatibility Advisory for Chip Revision Numbering Scheme](https://www.espressif.com.cn/sites/default/files/advisory_downloads/AR2022-005%20Compatibility%20Advisory%20for%20Chip%20Revision%20Numbering%20%20Scheme.pdf) on the versioning of Espressif SoC revisions.
You can run `esptool chip_id` to detect the series and revision of an SoC. See [SoC Errata](https://www.espressif.com.cn/en/support/documents/technical-documents?keys=errata) for more on how to distinguish between chip revisions, and the improvements provided by chip revisions. And run `idf.py --version` to know the version of current ESP-IDF.
## ESP-IDF Support for Different Chip Revisions
The sections below show the requirements to ESP-IDF version of chip revisions. Each chip revision corresponds to specific `Recommended` and `Required` versions of ESP-IDF:
-`Recommended`: shows from which version of ESP-IDF you can make use of all the improvements of the chip revision. Running binary compiled with ESP-IDF below the `Recommended` version of a chip revision, software may not benefit from the bugfix/features provided by the chip revision. The chip will have almost the same behavior as its previous revision.
-`Required`: shows the minimum version required to run the chip revision normally. Running binary compiled below the `Required` version, the binary may have unpredictable behavior.
Though the software can make use of all the features of a chip revision, if its version is higher than the `Recommended` version of the chip, it is still recommended to use the latest bugfix version of the release branch. The latest bugfix version fixes a number of issues and helps improve product stability.
For example, if we have a chip, whose `Required`/`Recommended` version of `release/v5.1` branch is `v5.1.2`/`v5.1.4`, and the latest release on that branch is `v5.1.6`. Then the chip will not boot up with ESP-IDF `v5.1`-`v5.1.1` or will have unpredictable behavior, and application may not make use of all benefits of the chip, when running with ESP-IDF `v5.1.2` or `v5.1.3`. Though `v5.1.4` well supports the chip revision, it is still recommended to upgrade ESP-IDF to `v5.1.6`.
## What If the ESP-IDF Version Is Lower than the `Required` Version?
Latest ESP-IDF versions can prevent from downloading to, or even execute binaries on unsupported chips. ESP-IDF of versions v4.4.5+, v5.0.1+, v5.1 and above have both esptool download check and bootloader loading check against the chip revision. While ESP-IDF v4.3.5 has only esptool downloading check.
For earlier ESP-IDF versions without such checking, which is incompatible with the given chip revision, the chips running such versions will have unpredictable behavior.
Contributions to esp-idf - fixing bugs, adding features, adding documentation - are welcome. We accept contributions via `Github Pull Requests <https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests>`_.
Before Contributing
-------------------
Before sending us a Pull Request, please consider this list of points:
* Is the contribution entirely your own work, or already licensed under an Apache License 2.0 compatible Open Source License? If not then we unfortunately cannot accept it.
* Does any new code conform to the esp-idf :doc:`Style Guide <style-guide>`?
* Have you installed the :doc:`pre-commit hook <install-pre-commit-hook>` for esp-idf project?
* Does the code documentation follow requirements in :doc:`documenting-code`?
* Is the code adequately commented for people to understand how it is structured?
* Is there documentation or examples that go with code contributions? There are additional suggestions for writing good examples in :idf:`examples` readme.
* Are comments and documentation written in clear English, with no spelling or grammar errors?
* Example contributions are also welcome. Please check the :doc:`creating-examples` guide for these.
* If the contribution contains multiple commits, are they grouped together into logical changes (one major change per pull request)? Are any commits with names like "fixed typo" `squashed into previous commits <https://eli.thegreenplace.net/2014/02/19/squashing-github-pull-requests-into-a-single-commit/>`_?
* If you're unsure about any of these points, please open the Pull Request anyhow and then ask us for feedback.
Pull Request Process
--------------------
After you open the Pull Request, there will probably be some discussion in the comments field of the request itself.
Once the Pull Request is ready to merge, it will first be merged into our internal git system for in-house automated testing.
If this process passes, it will be merged onto the public github repository.
Legal Part
----------
Before a contribution can be accepted, you will need to sign our :doc:`contributor-agreement`. You will be prompted for this automatically as part of the Pull Request process.
- Please read [the support policy](SUPPORT_POLICY.md) and [the documentation](https://docs.espressif.com/projects/esp-idf/en/latest/esp32/versions.html) for more information about ESP-IDF versions.
- Please see the [End-of-Life Advisories](https://www.espressif.com/en/support/documents/advisories?keys=&field_type_of_advisory_tid%5B%5D=817) for information about ESP-IDF releases with discontinued support.
# ESP-IDF Release and SoC Compatibility
The following table shows ESP-IDF support of Espressif SoCs where ![alt text][preview] and ![alt text][supported] denote preview status and support, respectively. The preview support is usually limited in time and intended for beta versions of chips. Please use an ESP-IDF release where the desired SoC is already supported.
The following table shows ESP-IDF support of Espressif SoCs where ![alt text][preview] and ![alt text][supported] denote preview status and support, respectively. In preview status the build is not yet enabled and some crucial parts could be missing (like documentation, datasheet). Please use an ESP-IDF release where the desired SoC is already supported.
There are variants of revisions for a series of chips. See [Compatibility Between ESP-IDF Releases and Revisions of Espressif SoCs](https://github.com/espressif/esp-idf/blob/master/COMPATIBILITY.md) for the details of the compatibility between ESP-IDF and chip revisions.
Espressif SoCs released before 2016 (ESP8266 and ESP8285) are supported by [RTOS SDK](https://github.com/espressif/ESP8266_RTOS_SDK) instead.
# Developing With ESP-IDF
@@ -43,9 +31,11 @@ See https://idf.espressif.com/ for links to detailed instructions on how to set
### Non-GitHub forks
ESP-IDF uses relative locations as its submodules URLs ([.gitmodules](.gitmodules)). So they link to GitHub. If ESP-IDF is forked to a Git repository which is not on GitHub, you will need to run the script [tools/set-submodules-to-github.sh](tools/set-submodules-to-github.sh) after git clone.
The script sets absolute URLs for all submodules, allowing `git submodule update --init --recursive` to complete. If cloning ESP-IDF from GitHub, this step is not needed.
ESP-IDF uses relative locations as its submodules URLs ([.gitmodules](.gitmodules)). So they link to GitHub.
If ESP-IDF is forked to a Git repository which is not on GitHub, you will need to run the script
[tools/set-submodules-to-github.sh](tools/set-submodules-to-github.sh) after git clone.
The script sets absolute URLs for all submodules, allowing `git submodule update --init --recursive` to complete.
If cloning ESP-IDF from GitHub, this step is not needed.
## Finding a Project
@@ -92,7 +82,7 @@ You don't need to run `idf.py build` before running `idf.py flash`, `idf.py flas
## Viewing Serial Output
The `idf.py monitor` target uses the [esp-idf-monitor tool](https://github.com/espressif/esp-idf-monitor) to display serial output from Espressif SoCs. esp-idf-monitor also has a range of features to decode crash output and interact with the device. [Check the documentation page for details](https://docs.espressif.com/projects/esp-idf/en/latest/get-started/idf-monitor.html).
The `idf.py monitor` target uses the [idf_monitor tool](https://docs.espressif.com/projects/esp-idf/en/latest/get-started/idf-monitor.html) to display serial output from Espressif SoCs. idf_monitor also has a range of features to decode crash output and interact with the device. [Check the documentation page for details](https://docs.espressif.com/projects/esp-idf/en/latest/get-started/idf-monitor.html).
Exit the monitor by typing Ctrl-].
@@ -121,8 +111,6 @@ This can be combined with other targets, ie `idf.py -p PORT erase-flash flash` w
* Documentation for the latest version: https://docs.espressif.com/projects/esp-idf/. This documentation is built from the [docs directory](docs) of this repository.
* [Beginner's Guide to Key Concepts and Resources of ESP-IDF](https://youtu.be/J8zc8mMNKtc?feature=shared)
* The [esp32.com forum](https://esp32.com/) is a place to ask questions and find community resources.
* [Check the Issues section on github](https://github.com/espressif/esp-idf/issues) if you find a bug or have a feature request. Please check existing Issues before opening a new one.
Please refer to https://docs.espressif.com/projects/esp-idf/en/latest/esp32/versions.html#support-periods for more details on ESP-IDF supported versions and support period policy.
## Reporting a Vulnerability
Please refer to [Espressif Security Incident Response Process](https://www.espressif.com/sites/default/files/Espressif%20Security%20Incident%20Response%20Process%20v1.0_EN.pdf) on the guidelines to report a security vulnerability. Please do **NOT** create a public GitHub issue.
Each ESP-IDF major and minor release (V4.1, V4.2, etc) is supported for 30 months after the initial stable release date.
Each ESP-IDF major and minor release (V4.1, V4.2, etc) is supported for
30 months after the initial stable release date.
Supported means that the ESP-IDF team will continue to apply bug fixes, security fixes, etc to the release branch on GitHub, and periodically make new bugfix releases as needed.
Supported means that the ESP-IDF team will continue to apply bug fixes,
security fixes, etc to the release branch on GitHub, and periodically
make new bugfix releases as needed.
Support period is divided into "Service" and "Maintenance" period:
@@ -16,36 +19,58 @@ Support period is divided into "Service" and "Maintenance" period:
| Service | 12 months | Yes |
| Maintenance | 18 months | No |
During the Service period, bugfixes releases are more frequent. In some cases, support for new features may be added during the Service period (this is reserved for features which are needed to meet particular regulatory requirements or standards for new products, and which carry a very low risk of introducing regressions.)
During the Service period, bugfixes releases are more frequent. In some cases,
support for new features may be added during the Service period (this is
reserved for features which are needed to meet particular regulatory
requirements or standards for new products, and which carry a very low risk of
introducing regressions.)
During the Maintenance period, the version is still supported but only bugfixes for high severity issues or security issues will be applied.
During the Maintenance period, the version is still supported but only bugfixes
for high severity issues or security issues will be applied.
Using an “In Service” version is recommended when starting a new project.
Users are encouraged to upgrade all projects to a newer ESP-IDF release before the support period finishes and the release becomes End of Life (EOL). It is our policy to not continue fixing bugs in End of Life releases.
Users are encouraged to upgrade all projects to a newer ESP-IDF release before
the support period finishes and the release becomes End of Life (EOL). It is our
policy to not continue fixing bugs in End of Life releases.
Pre-release versions (betas, previews, `-rc` and `-dev` versions, etc) are not covered by any support period. Sometimes a particular feature is marked as "Preview" in a release, which means it is also not covered by the support period.
Pre-release versions (betas, previews, `-rc` and `-dev` versions, etc)
are not covered by any support period. Sometimes a particular feature is
marked as "Preview" in a release, which means it is also not covered
by the support period.
ESP-IDF should be used in an up-to-date software environment. The operating system and other third-party tools should be supported by their maintainers. ESP-IDF cannot keep compatibility with unsupported third-party tools.
ESP-IDF should be used in an up-to-date software environment. The operating system
and other third-party tools should be supported by their maintainers.
ESP-IDF cannot keep compatibility with unsupported third-party tools.
The ESP-IDF Programming Guide has information about the [different versions of ESP-IDF](https://docs.espressif.com/projects/esp-idf/en/latest/versions.html) (major, minor, bugfix, etc).
The ESP-IDF Programming Guide has information about the
[different versions of ESP-IDF](https://docs.espressif.com/projects/esp-idf/en/latest/versions.html)
(major, minor, bugfix, etc).
Example
-------
ESP-IDF V3.3 was released in September 2019. It was supported for 30 months until February 2022.
ESP-IDF V3.3 was released in September 2019. It will be supported for 30 months
until February 2022.
- The first V3.3 release was `v3.3` in September 2019.
- The ESP-IDF team continues to backport bug fixes, security fixes, etc to the release branch `release/v3.3`.
- Periodically stable bugfix releases are created from the release branch. For example `v3.3.1`, `v3.3.2`, etc. Users are encouraged to always update to the latest bugfix release.
-V3.3 bugfix releases continue until February 2022, when all V3.3.x releases become End of Life.
- The ESP-IDF team continues to backport bug fixes, security fixes,
etc to the release branch `release/v3.3`.
-Periodically stable bugfix releases are created from the release
branch. For example `v3.3.1`, `v3.3.2`, etc. Users are encouraged to
always update to the latest bugfix release.
- V3.3 bugfix releases continue until February 2022, when all V3.3.x
releases become End of Life.
Existing Releases
-----------------
ESP-IDF release V4.1 and all newer releases will follow this support period policy. The support period for each release will be announced when the release is made.
ESP-IDF release V4.1 and all newer releases will follow this support period
policy. The support period for each release will be announced when the release
is made.
For releases made before the current support period policy was announced, the original support periods apply:
For releases made before the current support period policy was announced, the
original support periods apply:
* ESP-IDF V4.0.x will be supported until October 2021
* ESP-IDF V3.3.x will be supported until February 2022
@@ -54,5 +79,8 @@ For releases made before the current support period policy was announced, the or
Policy History
--------------
* September 2019. This policy splits ESP-IDF releases into Standard and Long Term Support.
* July 2020. All releases from now will have the same support period, which is equal to the previous Long Term Support period. Added “In Service” period, during which versions will receive more updates.
* September 2019. This policy split ESP-IDF releases into Standard and Long Term
Support.
* July 2020. All releases from now will have the same support period, which is
equal to the previous Long Term Support period. Added “In Service” period,
@@ -8,9 +8,16 @@ This document contains details about what the core components are, what they con
The core components are organized into two groups.
The first group (referred to as `G0`) includes `hal`, `arch` (where `arch` is either `riscv` or `xtensa` depending on the chip), `esp_rom`, `esp_common`, and `soc`. This group contains information about and provides low-level access to the underlying hardware. In the case of `esp_common`, it contains hardware-agnostic code and utilities. These components may have dependencies on each other within the group, but outside dependencies should be minimized. The reason for this approach is that these components are fundamental, and many other components may require them. Ideally, the dependency relationship only goes one way, making it easier for this group to be usable in other projects.
The first group (referred to as `G0` from now on) contains `hal`, `xtensa` and `riscv` (referred to as `arch` components from now on), `esp_rom`, `esp_common`, and `soc`. This
group contain information about and low-level access to underlying hardware; or in the case of `esp_common`, hardware-agnostic code and utilities.
These components can depend on each other, but as much as possible have no dependencies outside the group. The reason for this is that, due to the
nature of what these components contain, the likelihood is high that a lot of other components will require these. Ideally, then, the dependency
relationship only goes one way. This makes it easier for these components, as a group, to be usable in another project. One can conceivably implement
a competing SDK to ESP-IDF on top of these components.
The second group (referred to as `G1`) operates at a higher level than the first group. `G1` includes the components `esp_hw_support`, `esp_system`, `newlib`, `spi_flash`,`freertos`, `log`, and `heap`. Like the first group, circular dependencies within this group are allowed, and these components can have dependencies on the first group. G1 components represent essential software mechanisms for building other components.
The second group (referred to as `G1` from now on) sits at a higher level than the first group. This group contains the components `esp_hw_support`, `esp_system`, `newlib`, `spi_flash`,
`freertos`, `log`, and `heap`. Like the first group, circular dependencies within the group are allowed; and being at a higher level, dependency on the first group
is allowed. These components represent software mechanisms essential to building other components.
## Descriptions
@@ -25,7 +32,7 @@ into routines that achieve a meaningful action or state of the peripheral.
Example:
-`spi_flash_ll_set_address` is a low-level function part of the hardware abstraction `spi_flash_hal_read_block`
-`spi_flash_ll_set_address` is a low-level function part of the hardware abstraction `spi_flash_hal_read_block`
#### `arch`
@@ -34,9 +41,9 @@ This can also contain files provided by the architecture vendor.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
