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.
Bluetooth: disable PLL track function for ESP32-C3/ESP32-S3 as it introduced coexistence issues(bacport v4.3)
See merge request espressif/esp-idf!18140
fix(server): Fix websocket server not support handle multiple connections when client send CLOSE frame (backport v4.3)
See merge request espressif/esp-idf!18019
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).
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.
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.
Update wifi lib with below fixes -
1. In FTM Responder, add session timer for cleanup, also remove
unnecessary mutex locks
2. In FTM Responder, fix incorrect print in case of failure
while setting up the SofTAP
2. In FTM Initiator, increase FTM Request response timeout to
avoid failures in noisy environments
3. In FTM Initiator, abort for high start delta time, also fix
timeout issue in ASAP mode
* 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
* Minor fixes listed below: Fix client receive KOD, NAPT fixes, restore
dhcp_cb, sntp docs, vendor class id (disabled)
* Update submodule: 2195f7416f...76303df238
Detailed description of the changes:
- 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)
- add function for deinit lwip timers (espressif/esp-lwip@2749568f)
- dhcp: Fix build issue that set ESP_DHCP_DISABLE_VENDOR_CLASS_IDENTIFIER to true will build fail (espressif/esp-lwip@d827dbf7)
- Document that sntp_setservername doesn't copy the string (espressif/esp-lwip@54acdb59) #6786
- lwip/dhcp: add 60 option for vendor class identify (espressif/esp-lwip@ae7edc2a) espressif/esp-lwip#32
- dhcp: Restore dhcp_cb on restart after dhcp_release_and_stop() (espressif/esp-lwip@55ea9d9c) #7217
- napt: Fix disbale IPv6 and enable NAPT will build error (espressif/esp-lwip@74cf7f9f)
- napt: fix checksum of UDP (espressif/esp-lwip@bb63eed1)
- sntp: Fix client receive KOD packet that make pool MEMP_SYS_TIMEOUT not be freed (espressif/esp-lwip@1c1642fe)
- test case: add tcp state and reset test cases. (espressif/esp-lwip@67deb805)
Closes https://github.com/espressif/esp-idf/issues/8300
Closes https://github.com/espressif/esp-idf/issues/8451
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
5.compute packet length use lldesc length instead rx_ctl sig_len for sniffer
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
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)
- 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
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)
...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
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
- 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 RISCV, backtrace generation on device is not possible without
including and parsing DWARF sections. We extract the crash task stack
and let the host generate the backtrace
- 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
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
CMake sorts result of file(GLOB) command since version 3.6.0:
https://gitlab.kitware.com/cmake/cmake/-/commit/edcccde7d
Since ESP-IDF sets cmake_minimum_required version to 3.5, and version
3.5.1 is used in CI, sort file lists obtained from file(GLOB)
manually.
This helps obtain reproducible order of libraries passed to the linker
and to ldgen.
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
Updated MQTT submodule: git log --oneline f10321a53b53a146ee299cfecc320b89c0cf6611...89894bd0c611b1392967fe90bb49682eba858383
* Fix build issue if cert bundle disabled
* Fix build issue if ws transport disabled
* Add config to set retransmission interval
Detailed description of the changes (f10321a53b...89894bd0c6):
* Added config option to configure custom retransmission interval
- See merge request espressif/esp-mqtt!110
- esp_mqtt commit 1b009c840b
- Related https://github.com/espressif/esp-mqtt/pull/199
* Configuration conflicts were verified, logged but not reported to the user.
- See merge request espressif/esp-mqtt!102
- esp_mqtt commit 88f4b8ed50
* Fixed build issue if cert bundle disabled
- See merge request espressif/esp-mqtt!109
- esp_mqtt commit 4a89bff610
- esp_mqtt commit 1b71980575
- esp_mqtt commit 5b3c81ee48
- Related https://github.com/espressif/esp-mqtt/pull/198
- Related https://github.com/espressif/esp-idf/issues/7535
* Removes unnecessary outbox_cleanup
- This function were used on old version to handle QoS 2 messages. It's no longer necessary in current implementation.
- See merge request espressif/esp-mqtt!108
- esp_mqtt commit ebef896b00
* Fixed return an error when fail to enqueue
- The functions that enqueue messages didn't had a return for the handler, with this the error was only logged instead of returned whichmay cause the user to have an ID for a message that was not published.
- See merge request espressif/esp-mqtt!103
- esp_mqtt commit 7471177fe7
* CI: Use qemu image based on esp-env:v4.4-1
- Replaced the temporary qemu image with the official qemu:v4.4-1-20210517 derived from the esp-env:v4.4-1 test environment
- See merge request espressif/esp-mqtt!107
- esp_mqtt commit 231b274962
Closes https://github.com/espressif/esp-idf/issues/7535
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.
ringbuf: Fix bug where comparision between a signed and unsigned operand resulted in incorrect free size for no-split/allow-split buffers (v4.3)
See merge request espressif/esp-idf!15882
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 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
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 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
[Coexistence]: fixed BLE scannable extended adv performance issue in case of Wi-Fi coexistence(backport v4.3)
See merge request espressif/esp-idf!16477
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
1. Add conditions based on Kconfig options for functions which are
compiled based on those options.
2. Static allocation is always enabled, move corresponding functions
into the common list.
Since these functions receive the pointer to reent structure, they
should set errno in it rather than using thread-local errno.
This didn't cause practical issues because console functions in IDF
are only called from threads, and in that case 'r' is a pointer to
the thread-local structure, so &errno is the same thing as
&__errno_r(r). Still, fixing this for consistency.
When CONFIG_VFS_SUPPORT_IO is disabled, _read_r and _write_r
implementations in syscalls.c are used to provide console I/O via
esp_rom_uart_tx_one_char/esp_rom_uart_rx_one_char.
When newlib opens a (FILE*) stream, it calls fstat to check if the
underlying file is character-oriented. In this case, it configures the
stream to use line buffering. Otherwise (or if fstat fails) the stream
is opened as block buffered.
Since fstat wasn't provided, stdin/stdout/stderr streams got opened in
block buffered mode. For console, we need line buffered output so that
the stream buffer is flushed each time a complete line (ending with
'\n') is sent to stdout or stderr.
Fix by implementing _fstat_r stub, setting st->st_mdoe=S_IFCHR.
* 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
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.
build ble_mesh_console example on c3 as well
add test dir examples/bluetooth/esp_ble_mesh/ble_mesh_console
add test dir examples/bluetooth/hci/controller_hci_uart_esp32
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
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 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>
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.
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
Furthermore, RX_EOF_EN should only be set when SPI Slave is configured
for segment transfer mode and the "ms_data_bitlen" field is configured
to control the "IN_SUC_EOF" interrupt. Since "ms_data_bitlen" is not
set anymore for S2, C3 and S3, "RX_EOF_EN" should be cleared.
The maximum input length for the SPI Slave should be applied to the read
buffer configuration, not for the write buffer. Similarly, the output
configuration should also target the write buffer.
MOSI and MISO enablement were conditioned to the existence of TX
and RX buffers, respectively. This is valid for the SPI Master,
but for the SPI Slave the opposite is expected.
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.
mesh: fix the issue that layer2 node connect to lower-layer node when FIXED-ROOT root disappeared(backport_v4.3)
See merge request espressif/esp-idf!15660
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
Fix for packets containing unexpected domains, such as openthread.thread.home.arpa.
If we find this packet we set the name entry as invalid, but continue with parsing as the packet might contain related queries for us.
Closes https://github.com/espressif/esp-idf/issues/7694
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.
the state again and run the "ble_master_soft_rst()" if neesed.
2.fix HCI_Read_Clock error
3.fix HCI_Create_Connection_Cancel error
4.fix ASSERT_WARN during epr
esp_http_client: Fix HEAD request will affect the all next HTTP requests unless we close the HTTP request(backport v4.3)
See merge request espressif/esp-idf!15714
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
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.
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.
The psram cache bug fix was also being applied to the bootloader binary (for cmake),
which doesnt do any psram access.
Applying this fix would increase the binary size, as much as 300 bytes in worst case scenarios
* CI errors led me to believe these were needed, but as it turns out the
load/store intrinsics are required even when idf is built by gcc when
linking to a clang based project.
* remove ... postfix inside `SYNC_LOCK_TEST_AND_SET` expansion
Provide emulated atomic load & store libcalls for u8, u16 & u32 integer
types. This is required when building with Clang as llvm does not lower
these operations to native load / stores, where as gcc does.
Provide `sync_lock_test_and_set` atomic implementations for all
supported integer types.
Closes https://github.com/espressif/esp-idf/issues/7591.
Closes https://github.com/espressif/esp-idf/issues/7592.
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
};
The code checked CONFIG_ETH_USE_SPI_ETHERNET (which is usually set),
but CONFIG_EXAMPLE_ETH_SPI_xxx_GPIO options are only defined if
CONFIG_EXAMPLE_USE_SPI_ETHERNET is set. Fix the ifdef accordingly.
Regression from aea901f0.
It was when in the partition table there is a partition with type="data" and suptype=""(empty),
in this case type=1, suptype=0. It is similar to otadata partition.
This commit fixes it, now it will handle it as type=1, suptype=6 (ESP_PARTITION_SUBTYPE_DATA_UNDEFINED).
There was race condition where interrupt entries set by APP cpu core
could have been cleared during PRO cpu startup.
This was causing "cache access error" not being detected for ESP32 APP
CPU core.
This fix allows to NOT modify or clear any entries set by other core
(APP or PRO) and thus avoiding any race conditions during startup code.
spi_flash(bootloader): adjust unlock patch from rom patch into bootloader, and add support for GD chips (backport v4.3)
See merge request espressif/esp-idf!14605
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
When the application is being debugged it should check the call result (esp_cpu_in_ocd_debug_mode())
is not given volt.glitch attack - so the result is triple-checked by ESP_FAULT_ASSERT macro. In case
the check fails, the system is reset immediately
IDF-4014
ROM code doesn't allow loader stub to be executed in case secure boot in
enabled. Providing --no-stub flag to esptool allows user to flash new
firmware, given download mode hasn't been disabled
* Disable Tx interrupts to fix race condition of missing Rx interrupt
* Check if GPIO interrupt is asserted periodically if the ISR event missed
Closes https://github.com/espressif/esp-idf/issues/6414
Default 30s timeout is too low for a case when SD card formatting is triggered,
which could lead to tests failure. Timeout of tests is now set to 60s.
JIRA IDFCI-742
1. Added config options to chose from protocom security.
It can be chosen 0/1 or custom.
Possible to set POP as well
2. Added support in `esp_local_ctrl.py` test script for sec_ver selection
Signed-off-by: Vikram Dattu <vikram.dattu@espressif.com>
For https connection `ESP_TLS_ERR_SSL_WANT_READ` of esp_transport_read was getting treated as error.
Treated this as a timeout to fix connection abort issue!
Also handled http connection EAGAIN with `errno == EAGAIN` check.
Signed-off-by: Vikram Dattu <vikram.dattu@espressif.com>
A race condition is occuring while creating task on ESP32C3. Task is
getting created, but the function returns with a delay. Since task was
created, events start getting posted, but existing application
initializes certain threads / callbacks after stack initialization.
The same application works in different ways for bluedroid and nimble.
Hence modified the order during initialization accordingly.
When not compiling bootloader, a spinlock will be used for reading or writing
I2C internal devices/registers.
When compiling for bootloader, no need to use any lock.
* Description of unregistering was incorrect
* Made clear that event loop arg mustn't be NULL
* Added parameter check in create function
Closes https://github.com/espressif/esp-idf/issues/6761
Closes IDFGH-4969
We found conflict in "sizeof(time_t)" due to inclusion of this
header over toolchain specific "newlib.h".
Moreover, there are no users for this header and implementation
for API is also not available in ROM. Hence removing it.
Driver was using the channel ID from tx when reseting rx.
But since rx and tx is not necessarily from the same pair this could lead
to the driver reseting the wrong DMA channel.
Large SD cards (16GB+) require significant amount of time for FS formatting.
Added FS mount checkpoint in example test python, timeout set to 60 sec
Closes IDFCI-706
Allow user to select specific ESP_TARGET while setting up ESD_IDF.
Only necessary tools for given target will be downloaded and installed.
Closes https://github.com/espressif/esp-idf/issues/5113
1. Update wifi lib with fix for dropping bcast PMF deauths/disassocs
with certain reason codes
2. Fix FTM not working in connected state and some other FTM bugs
Before newlib 3.3.0, <dirent.h> bundled in newlib did not include any
function declarations. Instead, the file included the platform-
specific <sys/dirent.h>. This inclusion was inside a C++ guard block.
ESP-IDF provided sys/dirent.h inside newlib component, and this file
contained all the necessary function and structure declarations.
Since da418955f5,
common function declarations have been added to <dirent.h> in newlib.
However, the inclusion of sys/dirent.h has been moved out of the C++
guard block. However we didn't notice this change and did not update
sys/dirent.h in ESP-IDF newlib component to and the now-required
C++ guards there.
This commit adds the missing C++ guards to the platform-specific
sys/dirent.h.
The declarations of common dirent.h functions are now present both in
<dirent.h> (provided by newlib) and in sys/dirent.h (provided by IDF).
We keep the declarations in sys/dirent.h for compatibility, since some
ESP-IDF files and applications may include <sys/dirent.h> directly,
rather than <dirent.h>.
Closes https://github.com/espressif/esp-idf/issues/7204
Check Memprot lock bit(s) during the system startup, abort/reset on any Memprot parts found locked during this phase.
There is no legal reason to disallow the Memprot configuration by the system, so it's either a critical bug in the
application or an malicious attempt to bypass the system security.
Error message is printed before digital system reset.
Closes IDF-2700
Bugfix: Set LANG to en code to avoid RuntimeError during autocompletion activation & Replaced broken link to shell autocompletion (v4.3)
See merge request espressif/esp-idf!14122
- there was a small race in `uart_pattern_link_free`:
`rx_pattern_pos.data` was accessed for reading outside spinlock
- `uart_flush_input` enabled
`UART_INTR_RXFIFO_FULL|UART_INTR_RXFIFO_TOUT` intr mask on exit even
if these flags weren't set when function was called
Closes https://github.com/espressif/esp-idf/pull/7023
IRAM section didn't contain sufficient padding for possible CPU instruction prefetch,
ie instruction fetch could happen in DRAM section which is prohibited by the Memprot module.
This is fixed by adding 16B to the end of IRAM section in LD script (C3 CPU prefetch buffer depth is 4 words)
Closes IDF-3554
- Add `wifi_prov_scheme_ble_set_mfg_data` API to set custom manufacturer data
in BLE advertisements.
- Run format.sh script on modified files.
- Fix few typos in `protocomm_nimble.c`.
- Incorporate suggestion to remove extra check on protocomm_ble_mfg_data_len
- Remove few unnecessary comments.
MbedTLS: Add config option for key elements and key element extension for SSL connection
See merge request espressif/esp-idf!12898
(cherry picked from commit 76bd33e9a4)
38d67725 mbedtls: Add config option key element and key element ext
Fix the issue mentioned when using two or more encoders. Modify PCNT_CTRL_GND_IO
to avoid the affect of USB JTAG(origin pin 19 is used for USB D-). Update esp32c3.
peripherals.ld and docs for esp32s3.
Closes https://github.com/espressif/esp-idf/issues/6889
This is mostly important on ESP32 ECO3 with the
ESP32_ECO3_CACHE_LOCK_FIX, because when we stall the other CPU core
before we disable the TG1 WDT then the first CPU can get stuck
in WDT ISR handle_livelock_int routine waiting for the other CPU.
data cache is unicode. while we use bytes in RegEx expect. The index of
matched pattern is calculated with bytes, could be different from
unicode. Now we fix this issue by using unicode in expect.
1. RRM capability addition for open AP
2. Crash during scan flush
3. Station not able to connect if disassoc timer is present in BTM request
4. Memory leaks during wifi init/deinit.
Update wifi lib with below features -
1. ASAP mode for both Initiator and Responder
2. Offchannel FTM while connected to AP (ASAP only)
3. Support up to 3 Initiators simultaneously
4. Session termination, failure support etc
5. Mem-zero AP scan buffer in get_records API
After we have the performance dashboard, we have more data and no longer depend on the threshold to ensure performance.
Set looser performance thresholds to avoid CI failure.
1. Fix aes_unwrap functionality when hardware acceleration is disabled
2. Fix compilation errors when mbedTLS is disabled.
3. Disable WPA3 when mbedTLS is disabled.
This commit add following crypto changes
1. Update current crypto code with upstream supplicant code
2. Add a proper porting layer to use mbedtls APIs for all the crypto
operations used by supplicant.
Internal crypto will be used when USE_MBEDLTS flag is disabled
in supplicant's menuconfig.
This commit also removes the clutter in crypto files due to partial
porting of some APIs to mbedtls, all the code from those files have
been removed and rewritten in a generic way, this is inspired from
current upstream code.
This also reduces the lib size significantly, supplicant's lib
size reduces around ~567kb after this change(NB: lib size doesn't
indicate reduction in final bin size).
Adds ESP32-C3 support
Updates ESP32-S3 overlay
GDB 9.2 for ESP32-C3 with core dump support
Linker supports eh-frame-hdr for ESP32-C3
Newlib 3.3.0 includes fixes for <cmath> funcs, for overflow when TZ calculating, for malloc checks
Binutils 2.35.1
Closes https://github.com/espressif/esp-idf/issues/6795
WPS strict disables workarounds with different APs and may cause
IOT issues. Remove this as default and introduce as a config option.
Also add changes to declare esp device as single band mobile device since
WFA sniffer was not able to identify it in the certification setup.
* This function has been accidentally removed.
It is necessary to provide the emergency
exception memory pool size for C++ code.
Since our libstdc++ always has exceptions
enabled, this function must exist here even if
-fno-exception is set for user code.
This commit updates the documentation and register struct
of the TWAI driver for the ESP32-C3. Note that the register
fields for ESP32-S3 have also been updated.
Core dump integrity check can now be parametrized through menuconfig.
It can be performed on boot or ignored. When core dump is activated
in the menuconfig, the user can still check the core dump at any time
with the function `esp_core_dump_image_check()`.
Fix a bug where `esp_core_dump_image_get()` was not accessible
when core dump was disabled.
Closes https://github.com/espressif/esp-idf/issues/6620
This commit brings two esp-lwip fixes to IDF:
1) Add configuration to disable DHCP client identification
2195f7416f
This config could be used to disable option 61 in DHCP packets, so that
clients will be identified by their chaddr only.
(This is the lwip upstream original behaviour)
2) Fix server_idx increasing to DNS_MAX_SERVERS and trigger the LWIP_ASSERT
5a567d52f7
When lwip doesn't have DNS server and resolve a domain address, the server_idx
will increase to DNS_MAX_SERVERS, which will trigger the LWIP_ASSERT and make device crash.
Closes https://github.com/espressif/esp-idf/issues/6878
Increase the interrupt reassert level timing so the chances of missing
two consecutive events are minimal.
Enable only SIR_RECV interrupt event, so the SEND events are not used
for GPIO signal.
If the GPIO interrupt is re-asserted too quickly it could be missed. If this happens the driver goes silent and never receives any data. Recover by periodic checks of the IO signal level
The issue typically happens for link-down during Tx. Added two retry levels, one before checking the sanity of the w5500 phy register and another for the Tx done itself (if the device is in the sane state)
Closes https://github.com/espressif/esp-idf/issues/6233
Reading SPI data may come in 4-byte units and thus result in unwanted
overwrites if smaller size registers read, especially if multiple placed
one after another. Fixed by using direct reads to `trans` structure for
sizes smaller or equal to 4.
Closes https://github.com/espressif/esp-idf/issues/6579
And it fixed another case for bootloader_common_get_sha256_of_partition() when CHECK_SIGNATURE is on
- If RSA signature check is on in Kconfig then sha256 was 0xFFFFF...
because image_load gave image_len which pointed to the end of sign blocks.
And image_digest was filled from a wrong position.
Closes https://github.com/espressif/esp-idf/issues/6873
Theory is that on the runner, in rare cases, gdb may need more than
1 second to load and start responding to commands.
However it's possible these timeouts are due to some other problem
(like gdb failing)
The previous location was the return from the first ets_printf call
that prints ROM sign-on message. Since the main function was patched
in ECO3, the new address no longer works — there is no instruction at
0x40007901 in ECO3 ROM. This could be solved by setting two
breakpoints (one would work for ECO <=2, the other for ECO3), but we
would need to remove the unused breakpoint later.
Fix this by setting the breakpoint at ets_printf. This means that when
debugging a loadable ELF the ROM sign-on message will no longer be
shown, but this doesn't seem to be an issue.
Partially reverted 08f1bbe0c7.
The host should have this flexibility, which is consistent to the cs_hold argument.
However, the user should know as less as possible about the host.
So the wrapper layer (esp_flash_spi_init.c) should cover this, helping to set cs_setup to 1, to meet the common requirements.
* Move nvs flash README to common doc directory
* correct markup of functions and types in text
from old README
* Better comment of nvs_get_used_entry_count()
* Mention C++ example in API reference
* Used target instead of hard code ESP32
* Note that strings can only span one page
* Reflect that item types have been moved
* Some clarification about nvs_commit()
* Improved reference to the ESP Partition API
* fixed little mistake in documenting-code.rst
* Change of nvs_open_from_part() to
nvs_open_from_partition() reflected in docs
* Corrected documentation of
NVSHandle::get_string(), NVSHandle::get_blob()
and NVSHandle::get_item_size().
* Closes DOC-165
* Closes IDF-1563
* Closes IDF-859
* Closes https://github.com/espressif/esp-idf/issues/6123
ROM will erase the region a partition is in as soon as it receives the
first bit of the data that is in the partition. For large partitions it
takes more than 5 seconds to erase which is a hard-coded limit in
dfu-utils.
This splits large binaries and adds them by chunks which should avoid
timing-out during flashing.
Closes https://github.com/espressif/esp-idf/issues/6999
Possible for a joined task to be deleted at the moment it is logging,
meaning it might hold the stdout lock. In that case the lock isn't
released and the next task to try and take it (i.e. call printf)
will block indefinitely.
Additionally, always enable the partition MD5 check if flash encryption is on in
Release mode. This ensures the partition table ciphertext has not been modified
(CVE-2021-27926).
The exception is pre-V3.1 ESP-IDF bootloaders and partition tables, which
don't have support for the MD5 entry.
Add support to tasks stacks in RTC DRAM. Before this fix, any stack
in RTC DRAM would have been considered as corrupted, whichi is not
the case.
Fix a bug related to wrong parameters passed to esp_core_dump_get_stack.
Fix a bug reading fake stack memory, triggering a memory violation.
* Closes https://github.com/espressif/esp-idf/issues/6751
* Merges https://github.com/espressif/esp-idf/pull/6750
Building mbedtls with CMake would warn that:
"A private source from a directory other than that of target "mbedcrypto
has a relative path"
This happened due to some of the CMake variables listing sources could be empty.
Changed to only use target_sources in the code-path where we set the sources,
so we only call target_sources will non-empty variables.
Closes https://github.com/espressif/esp-idf/issues/6767
NimBLE: Add NimBLE host support to reattempt GAP connection and address MITM vulnerability (CVE-2020-26558) (release/v4.3)
See merge request espressif/esp-idf!13549
Reraising the exception before exiting was intended to help troubleshoot,
but turned out to be more confusing than helpful as it might look like the script was failing
* Patched longjmp to be context-switch safe
longjmp modifies the windowbase and windowstart
registers, which isn't safe if a context switch
occurs during the modification. After a context
switch, windowstart and windowbase will be
different, leading to a wrongly set windowstart
bit due to longjmp writing it based on the
windowbase before the context switch. This
corrupts the registers at the next window
overflow reaching that wrongly set bit.
The solution is to disable interrupts during
this code. It is only 6 instructions long,
the impact shouldn't be significant.
The fix is implemented as a wrapper which
replaces the original first instructions of
longjmp which are buggy. Then, it jumps back
to execute the rest of the original longjmp
function.
Added a comparably reliable test to the
test apps.
Since dd849ffc, _rodata_start label has been moved to a different
linker output section from where the TLS templates (.tdata, .tbss)
are located. Since link-time addresses of thread-local variables are
calculated relative to the section start address, this resulted in
incorrect calculation of THREADPTR/$tp registers.
Fix by introducing new linker label, _flash_rodata_start, which points
to the .flash.rodata output section where TLS variables are located,
and use it when calculating THREADPTR/$tp.
Also remove the hardcoded rodata section alignment for Xtensa targets.
Alignment of rodata can be affected by the user application, which is
the issue dd849ffc was fixing. To accommodate any possible alignment,
save it in a linker label (_flash_rodata_align) and then use when
calculating THREADPTR. Note that this is not required on RISC-V, since
this target doesn't use TPOFF.
It is now possible to have any alignment restriction on rodata in the user
applicaiton. It will not affect the first section which must be aligned
on a 16-byte bound.
Closes https://github.com/espressif/esp-idf/issues/6719
rodata dummy section has now the same alignment as flash text section,
and at least the same size. For these reasons, the cache will map
correctly the following rodata section.
Theory is that the large alignments in this test component are triggering linker
bug (to be fixed in next toolchain update). This component is already tested
in a dedicated config, so it doesn't need to be included in this config.
1. Fix mesh deinit blocking issue
2. Fix root has no eb for deauth frames during the networking
3. Add esp_mesh_send_block_time to set blocking time of esp_mesh_send
4. Forward Mgmt frames with skipping CCMP headers to fix parsing issues in Application for ESP32C3
1. Removed the interrupt lock operation during controller enable/disable/reset, to avoid trigger interrupt watchdog time-out due to use of mutex/semaphore in coex_st_set
2: Update libbtbb.a for ESP32-C3 to fix the Rx performance issue for CODED PHY, especially in coexistence scenario
When user forgot to add git.exe or python to the PATH, there was a not
very helpful error message.
This improves the error with which tool is misssing and shows a link to
the espressif installer tool.
disconnect event. This issue is caused by modem sleep.The sleep interrupt
will come the second time before the CLKN interrupt. If we disable the sleep
interrupt when it comes in the first time, the CLKN will never come.
Noted as a problem with thread local storage returning a different task's
pointers, but some other were APIs also accessing current task unsafely.
Regression in FreeRTOS 10 update a3c90bf59a
Currently Max GATT services count cannot be configured externally and
hence user needs to modify code ,everytime the count is to be
modified.
Added an option in menuconfig to provide a way to user to set the count.
Fixes: https://jira.espressif.com:8443/browse/BT-1508
Causes test added in parent commit to pass.
This race happens if the deleted task is running on the other CPU,
and is already spinning in a critical section waiting for xTaskQueueMutex
because it's about to be blocked for a resource.
The "deleted" task would end up blocked, possibly indefinitely, and
never actually deleted or its resources cleaned up by the idle tasks.
Details:
vTaskDelete() adds the target task to the xTasksWaitingTermination list,
expecting it to be yielded off CPU and then cleaned up later. However as soon as
vTaskDelete() releases xTaskQueueMutex, the target task runs and moves itself to the
xDelayedTaskList1. Because interrupts are already disabled on that CPU,
the "yield" to the other CPU sent by the vTaskDelete() comes afterward so
doesn't help.
mdns resolver didn't correctly resolved queries when host name wasn't
assigned. Fixed by allowing processing also if some answer present
(non-strict mode)
Closes https://github.com/espressif/esp-idf/issues/6598
The resolver was able to respond correctly, but would also resolve its
own queries and cause issues with BCT 1.5.2, specifically
* MULTIPLE QUESTIONS - DUPLICATE SUPPRESSION
* MULTIPLE QUESTIONS - DISTRIBUTED DUPLICATE SUPPRESSION
tests failed.
Strict mode was hardcoded in private header file, but it's useful for
users to enable/disable it depending on the mdns library they are using.
e.g. Avahi might not resolve the non-strict answers.
When `DIS_USB_JTAG` eFuse is NOT burned (`False`), it is not possible
to set pins 18 and 19 as GPIOs. This commit solves this by manually
disabling USB JTAG when using pins 18 or 19.
The functions shall use `gpio_hal_iomux_func_sel` instead of
`PIN_FUNC_SELELECT`.
Newer versions of doxygen will give warnings for comments in
INPUT lists
Delete all comment lines to fix these warnings, our folder structure
stil gives an OK overview of what we are including
VDD_SDIO power domain can now be configured for light sleep
by the application. It is now possible to keep the power domain
ON during light sleep, keeping the GPIOs connected to it powered.
The power domain will, by default be:
- Kept ON if CONFIG_ESP_SYSTEM_PD_FLASH is not set
- Turned OFF if not set
The application can still force it to be ON by calling
`esp_sleep_pd_config(ESP_PD_DOMAIN_VDDSDIO, ESP_PD_OPTION_ON);`
Fixes issue with DPORT init task, this task uses minimum stack size and may not be
enough if stack smashing detection is set to Overall mode.
Also reworks the way we calculate minimum stack to allow for adding multiple
contributing factors.
Closes https://github.com/espressif/esp-idf/issues/6403
Current code stopped inquiry if major class is not Phone. Modified the
condition to consider for both Phone and Audio to cover majority of real
world devices.
Closes https://github.com/espressif/esp-idf/issues/6548
Unless the option for "assert and keep running" is enabled.
This means that silent asserts now work for FreeRTOS, and disabling asserts
now also disables them in FreeRTOS without needing a separate config change.
Related to https://github.com/espressif/esp-idf/issues/6306
If silent assert configuration is enabled, LWIP asserts are now 'silent' also.
Also updates KConfig to note that LWIP asserts are also disabled when asserts
are disabled globally (this was already the behaviour, but the config item
suggested otherwise.)
Progress towards https://github.com/espressif/esp-idf/issues/5873
The CPU might prefetch instructions, which means it in some cases
will try to fetch instruction located after the last instruction in
flash.text.
Add dummy bytes to ensure fetching these wont result in an error,
e.g. MMU exceptions
1. deepsleep poweron reset bug in high temperature before ECO3;
2. brownout reset bug before ECO2;
3. bbpll voltage low bug before ECO3;
4. need xpd iph for xtal before ECO3;
As this mode uses the public keys attached to the existing app's signatures to
verify the next app, checking that a signature block is found on boot prevents
the possibility of deploying a non-updatable device from the factory.
The dirent.h shipped with the risc-v compiler lacks `extern "C"`
declartion and causes linkage declartion conflict when included in C++
files. Use the dirent.h from newlib only to avoid this issue.
(cherry picked from commit b14830c5c0)
This commit includes the refactoring of the core dump feature. Thanks to
this refactoring, it is easier to integrate the support of RISC-V
architecture for this feature.
Fixes ESP-1758
NOP instructions have been added in order to prevent the code
from executing code it shouldn't execute. This is due to a delay
between the moment an interrupt is requested and the moment it
is fired. It only happens on RISC-V SoC.
Removed the old dynamically allocated GDMA channel approach.
It proved too unreliable as we couldn't not ensure consumers of the mbedtls
would properly free the channels after use.
Replaced by a single shared GDMA channel for AES and SHA, which won't be
released unless user specifically calls API for releasing it.
1. Fix the issue that the parameters obtained from RAM cannot be saved to NVS
2. Modify not to store the default value in NVS
3. Fixed issue with hidden AP scans after connecting AP.
4. Fix watchdog issue when receiving action frame.
5. Fixed issue of reason code change from 15 to 204 when provide wrong password
6. Fix set config return value error
7. Fix ampdu age timer memory leak
On S2 the brown out detector would occasionally trigger erroneously during deep sleep.
Disable it before sleeping to circumvent this issue.
Closes https://github.com/espressif/esp-idf/issues/6179
Enable shared stack watchpoint for overflow detection
Enable unit tests:
* "test printf using shared buffer stack" for C3
* "Test vTaskDelayUntil" for S2
* "UART can do poll()" for C3
On C3 the cache is programmatically split between Icache and dcache and with the default setup we dont leave a lot pages
available for additional mmaps into instruction space. Disabling this test for now since any hypothetical use case for this
is no longer supported "out of the box"
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/get-started/idf-monitor.html#automatically-decoding-addresses), 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
1. Push to a remote branch
2. Create an MR, choose related labels (not required)
3. A `detached` pipeline will be created.
4. if you push a new commit, a new pipeline will be created automatically.
## What if Expected Jobs ARE NOT Created?
1. check the file patterns
If you found a job that is not running as expected with some file changes, a git commit to improve the `pattern` will be appreciated.
2. please add MR labels to run additional tests, currently we have to do this only for `target-test` jobs, please use it as few as possible. Our final goal is to remove all the labels and let the file changes decide everything!
## MR labels for additional jobs
### Supported MR Labels
-`build`
-`build_docs`
-`component_ut[_esp32/esp32s2/...]`
-`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`
-`integration_test`
-`iperf_stress_test`
-`macos`
-`macos_test`
-`nvs_coverage`
-`submodule`
-`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`
-`all_test`: includes all test labels
### How to trigger a `detached` pipeline without pushing new commits?
Go to MR web page -> `Pipelines` tab -> click `Run pipeline` button.
In very rare case, this tab will not show up because no merge_request pipeline is created before. Please use web API then.
```shell
curl -X POST --header "PRIVATE-TOKEN: [YOUR PERSONAL ACCESS TOKEN]"[GITLAB_SERVER]/api/v4/projects/103/merge_requests/[MERGE_REQUEST_IID]/pipelines
```
## How to Develop With `rules.yml`?
### General Concepts
-`pattern`: Defined in an array. A GitLab job will be created if the changed files in this MR matched one of the patterns. For example:
```yaml
.patterns-python-files: &patterns-python-files
- "**/*.py"
```
- `label`: Defined in an if clause, similar as the previous bot command. A GitLab job will be created if the pipeline variables contains variables in `BOT_LABEL_xxx` format (DEPRECATED) or included in the MR labels. For example:
- `rule`: A combination of various patterns, and labels. It will be used by GitLab YAML `extends` keyword to tell GitLab in what conditions will this job be created. For example:
```yaml
.rules:build:docs:
rules:
- <<: *if-protected
- <<: *if-label-build_docs
- <<: *if-label-docs
- <<: *if-dev-push
changes: *patterns-docs
```
An example for GitLab job on how to use extends:
```yaml
check_docs_lang_sync:
extends:
- .pre_check_template
- .rules:build:docs
script:
- cd docs
- ./check_lang_folder_sync.sh
```
### How to Add a New `Job`?
check if there's a suitable `.rules:<rules-you-need>` template
1. if there is, put this in the job `extends`. All done, now you can close this window. (`extends` could be array or string)
2. if there isn't
1. check [How to Add a New `Rules` Template?](#how-to-add-a-new-rules-template), create a suitable one
2. follow step 1
### How to Add a New `Rules` Template?
check if this rule is related to `labels`, `patterns`
1. if it is, please refer to [dependencies/README.md](./dependencies/README.md) and add new rules by auto-generating
2. if it isn't, please continue reading
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:
- <<: *if-protected
- <<: *if-dev-push
changes: *patterns-python-files
```
2. if there isn't
1. check [How to Add a New `if` Anchor?](#how-to-add-a-new-if-anchor), create a suitable one
2. follow step 1
### How to Add a New `if` Anchor?
Create an `if` anchor following [`if` Anchors Naming Rules](#if-anchors-naming-rules). For detailed information about how to write the condition clause, please refer to [GitLab Documentation `only/except (advanced)](https://docs.gitlab.com/ee/ci/yaml/README.html#onlyexcept-advanced). Here's an example.
```yaml
.if-schedule:&if-schedule:
if:'$CI_PIPELINE_SOURCE == "schedule"'
```
### Naming Rules
#### Common Naming Rules
if a phrase has multi words, use `_` to concatenate them.
> e.g. `regular_test`
if a name has multi phrases, use `-` to concatenate them.
> e.g. `regular_test-example_test`
#### `if` Anchors Naming Rules
- if it's a label: `.if-label-<label_name>`
- if it's a ref: `.if-ref-<ref_name>`
- if it's a branch: `.if-branch-<branch_name>`
- if it's a tag: `.if-tag-<tag_name>`
- if it's multi-type combination: `.if-ref-<release_name>-branch-<branch_name>`
a combination of `example_test`, `custom_test`, `component_ut`, `integration_test` and all targets
#### `rules` Template Naming Rules
- if it's tag related: `.rules:tag:<tag_1>-<tag_2>`
- if it's label related: `.rules:labels:<label_1>-<label_2>`
- if it's test related: `.rules:test:<test_type>`
- if it's build related: `.rules:build:<build_type>`
- if it's pattern related: `.rules:patterns:<patterns>`
## Reusable Shell Script `tools/ci/utils.sh`
It is used to put all the reusable shell scripts as small functions. If you want to set `before_script: []` for you job, now you can set `extends: .before_script_slim` instead. it will only run `source tools/ci/utils.sh`
If you're developing CI shell scripts, you can use these functions without `source` them. They're already included in all `before_script`
To run these commands in shell script locally, place `source tools/ci/utils.sh` at the very beginning.
### Functions
#### CI Job Related
-`add_gitlab_ssh_keys`
-`add_github_ssh_keys`
-`add_doc_server_ssh_keys`
-`fetch_submodules`
-`get_all_submodules`
#### Shell Script Related
-`error`: log in red color
-`warning`: log in orange color
-`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]
- if [ -n "$LOCAL_GITLAB_HTTPS_HOST" ]; then export LOCAL_CI_REPOSITORY_URL="https://gitlab-ci-token:${CI_JOB_TOKEN}@${LOCAL_GITLAB_HTTPS_HOST}/${CI_PROJECT_PATH}"; fi
- if [ -n "$LOCAL_GIT_MIRROR" ]; then export LOCAL_CI_REPOSITORY_URL="${LOCAL_GIT_MIRROR}/${CI_PROJECT_PATH}"; fi
- echo "Using repository at $LOCAL_CI_REPOSITORY_URL"
1. Auto-generate some labels/rules we need and update them in `rules.yml`
2. Generate a dependency tree graph
## Schema
This file only used basic YAML grammar and has nothing to do with the GitLab version YAML file.
It has five custom keywords:
-`matrix`: An array of sub-arrays, used to replicate rules by formatting strings. You can use the format string everywhere, it will be formatted recursively
-`labels`: An array of `labels`.
-`patterns`: An array of `patterns`. Patterns that not included
-`included_in`: An array of other `rule` names. It indicates the `labels` and `patterns` will be included in all specified `rules` as well
-`deploy`: An array of strings, used to replicate rules by adding postfix `-<item in deploy array>`. It indicates the extra `label` used in `rules`, which will explain later.
## How to use this file to generate `rules.yml`
Let's take a complicated example to help understand the process
```yaml
"test-{0}-{1}":
matrix:
- [a, b]
- [c, d]
labels:
- "{0}-{1}"
patterns:
- "{0}"
- pattern-not-exist
included_in:
- build-{0}
```
1. expand the mapping dicts defined by `matrix`
After this step, it will turn into 4 dicts:
| key | labels | patterns | included_in |
| -------- | ------ | -------- | ----------- |
| test-a-c | a-c | a | build-a |
| test-a-d | a-d | a | build-a |
| test-b-c | b-c | b | build-b |
| test-b-d | b-d | b | build-b |
**Advanced Usage: You can overwrite a mapping by declaring it again later**, For example:
If we concatenate this part to the previous example,
```yaml
# ... The same as the previous example
test-a-c:
labels:
- overwrite
```
`rule` `test-a-c` will be turned into:
| key | labels |
| -------- | --------- |
| test-a-c | overwrite |
**Mappings with the keyword `deploy` will also replicate by adding a postfix `-<item in deploy array>` to the mapping key**
2. create rules by `included_in`
After this step, it will turn into 6 mapping dicts:
| key | labels | patterns |
| -------- | -------- | -------- |
| test-a-c | a-c | a |
| test-a-d | a-d | a |
| test-b-c | b-c | b |
| test-b-d | b-d | b |
| build-a | a-c, a-d | a |
| build-b | b-c, b-d | b |
3. replace the auto-generated region in `rules.yml` with `labels`, and `rules`. Each mapping will generate a `rule` and all the required labels. `patterns` are pre-defined in `rules.yml` and could not be generated automatically. If a mapping is using a `pattern` undefined, the `pattern` will be ignored.
- If a mapping key has postfix `-preview`, no `if-protected-xxx` clause will be added
- else if a mapping key has postfix `-production`, an `if-protected-no_label` clause will be added
- else, an `if-protected` clause will be added
## Graph
All `label` nodes are in green, `pattern` nodes are in cyan, `rule` nodes are in blue
### Requirements
There are a few extra dependencies while generating the dependency tree graph, please refer to [pygraphviz](https://github.com/pygraphviz/pygraphviz/blob/master/INSTALL.txt) documentation to install both `graphviz` and `pygraphviz`
- 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; }
- cd ${IDF_PATH}/components/efuse/test_efuse_host
- ./efuse_tests.py
test_efuse_table_on_host_esp32:
extends:.test_efuse_table_on_host_template
test_efuse_table_on_host_esp32s2:
extends:.test_efuse_table_on_host_template
variables:
IDF_TARGET:esp32s2
test_efuse_table_on_host_esp32s3:
extends:.test_efuse_table_on_host_template
variables:
IDF_TARGET:esp32s3
test_efuse_table_on_host_esp32c3:
extends:.test_efuse_table_on_host_template
variables:
IDF_TARGET:esp32c3
test_efuse_table_on_host_esp32h2:
extends:.test_efuse_table_on_host_template
variables:
IDF_TARGET:esp32h2
test_efuse_table_on_host_esp32c6:
extends:.test_efuse_table_on_host_template
variables:
IDF_TARGET:esp32c6
test_logtrace_proc:
extends:.host_test_template
artifacts:
when:on_failure
paths:
- tools/esp_app_trace/test/logtrace/output
- tools/esp_app_trace/test/logtrace/.coverage
expire_in:1week
script:
- cd ${IDF_PATH}/tools/esp_app_trace/test/logtrace
- ./test.sh
test_sysviewtrace_proc:
extends:.host_test_template
artifacts:
when:on_failure
paths:
- tools/esp_app_trace/test/sysview/output
- tools/esp_app_trace/test/sysview/.coverage
expire_in:1week
script:
- cd ${IDF_PATH}/tools/esp_app_trace/test/sysview
- ./test.sh
test_mkdfu:
extends:.host_test_template
variables:
LC_ALL:C.UTF-8
script:
- cd ${IDF_PATH}/tools/test_mkdfu
- ./test_mkdfu.py
test_autocomplete:
extends:
- .host_test_template
artifacts:
when:on_failure
paths:
- ${IDF_PATH}/*.out
expire_in:1week
script:
- ${IDF_PATH}/tools/ci/test_autocomplete.py
test_detect_python:
extends:
- .host_test_template
script:
- cd ${IDF_PATH}
- shellcheck -s sh tools/detect_python.sh
- shellcheck -s bash tools/detect_python.sh
- shellcheck -s dash tools/detect_python.sh
- "bash -c '. tools/detect_python.sh && echo Our Python: ${ESP_PYTHON?Python is not set}'"
- "dash -c '. tools/detect_python.sh && echo Our Python: ${ESP_PYTHON?Python is not set}'"
- "zsh -c '. tools/detect_python.sh && echo Our Python: ${ESP_PYTHON?Python is not set}'"
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.
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.
ESP-IDF is the development framework for Espressif SoCs (released after 2016<sup>[1](#fn1)</sup>) provided for Windows, Linux and macOS.
# Developing With ESP-IDF
@@ -43,9 +14,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 +65,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-].
@@ -113,18 +86,21 @@ After the initial flash, you may just want to build and flash just your app, not
## Erasing Flash
The `idf.py flash` target does not erase the entire flash contents. However it is sometimes useful to set the device back to a totally erased state, particularly when making partition table changes or OTA app updates. To erase the entire flash, run `idf.py erase-flash`.
The `idf.py flash` target does not erase the entire flash contents. However it is sometimes useful to set the device back to a totally erased state, particularly when making partition table changes or OTA app updates. To erase the entire flash, run `idf.py erase_flash`.
This can be combined with other targets, ie `idf.py -p PORT erase-flash flash` will erase everything and then re-flash the new app, bootloader and partition table.
This can be combined with other targets, ie `idf.py -p PORT erase_flash flash` will erase everything and then re-flash the new app, bootloader and partition table.
# Resources
* 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.
* If you're interested in contributing to ESP-IDF, please check the [Contributions Guide](https://docs.espressif.com/projects/esp-idf/en/latest/contribute/index.html).
________
<a name="fn1">1</a>: ESP8266 and ESP8285 are not supported in ESP-IDF. See [RTOS SDK](https://github.com/espressif/ESP8266_RTOS_SDK) instead.
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,43 +19,65 @@ 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.
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
* ESP-IDF versions before V3.3 are already End of Life.
* ESP-IDF V3.1.x and V3.2.x will both be supported until October 2020.
* ESP-IDF versions before V3.1 are already End of Life.
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,
This document contains details about what the core components are, what they contain, and how they are organized.
## Organization
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 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.
## Descriptions
The following is a short description of the components mentioned above.
### `G0` Components
#### `hal`
Contains the hardware abstraction layer and low-level operation implementations for the various peripherals. The low-level functions assign meaningful names to register-level manipulations; the hardware abstraction provide operations one level above this, grouping these low-level functions
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`
#### `arch`
Contains low-level architecture operations and definitions, including those for customizations (can be thought of on the same level as the low-level functions of `hal`).
This can also contain files provided by the architecture vendor.
Example:
-`xt_set_exception_handler`
-`rv_utils_intr_enable`
-`ERI_PERFMON_MAX`
#### `esp_common`
Contains hardware-agnostic definitions, constants, macros, utilities, 'pure' and/or algorithmic functions that is useable by all other components (that is, barring there being a more appropriate component to put them in).
Example:
-`BIT(nr)` and other bit manipulation utilities in the future
-`IDF_DEPRECATED(REASON)`
-`ESP_IDF_VERSION_MAJOR`
#### `soc`
Contains description of the underlying hardware: register structure, addresses, pins, capabilities, etc.
Example:
-`DR_REG_DPORT_BASE`
-`SOC_MCPWM_SUPPORTED`
-`uart_dev_s`
#### `esp_rom`
Contains headers, linker scripts, abstraction layer, patches, and other related files to ROM functions.
Example:
-`esp32.rom.eco3.ld`
-`rom/aes.h`
### `G1` Components
#### `spi_flash`
SPI flash device access implementation.
#### `freertos`
FreeRTOS port to targets supported by ESP-IDF.
#### `log`
Logging library.
#### `heap`
Heap implementation.
#### `newlib`
Some functions n the standard library are implemented here, especially those needing other `G1` components.
Example:
-`malloc` is implemented in terms of the component `heap`'s functions
-`gettimeofday` is implemented in terms of system time in `esp_system`
#### `esp_mm`
Memory management. Currently, this encompasses:
- Memory mapping for MMU supported memories
- Memory synchronisation via Cache
- Utils such as APIs to convert between virtual address and physical address
#### `esp_psram`
Contains implementation of PSRAM services
#### `esp_system`
Contains implementation of system services and controls system behavior. The implementations
here may take hardware resources and/or decide on a hardware state needed for support of a system service/feature/mechanism.
Currently, this encompasses the following, but not limited to:
- Startup and initialization
- Panic and debug
- Reset and reset reason
- Task and interrupt watchdogs
#### `esp_hw_support`
Contains implementations that provide hardware operations, arbitration, or resource sharing, especially those that
is used in the system. Unlike `esp_system`, implementations here do not decide on a hardware state or takes hardware resource, acting
merely as facilitator to hardware access. Currently, this encompasses the following, but not limited to:
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.
