1. Fix airkiss and esptouch find channel crash issue
2. Fix softAP crash by adding NULL pointer check for handling public action frame
3. Ignore dirtyBuf check when buffer size is larger than 4092
4. Fix rf signal test without 9M rate issue
5. Fix issue with hidden AP scans after connecting AP
6. Fix the watchdog issue when receiving action frame
7. Clear hotspot bss when auth timeout happens
8. Fix the bug for esptouch find hidden AP fail
9. Fixed issue of reason code change from 15 to 204 when provide wrong password
10. Fix set config return value error
11. Fix ampdu age timer memory leak
12. Fix PMK not saved in NVS for SoftAP for PSK mode
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.
ringbuf: Fix bug where comparision between a signed and unsigned operand resulted in incorrect free size for no-split/allow-split buffers (v3.3)
See merge request espressif/esp-idf!15893
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
1. fix the issue that layer2 node connect to lower-layer node when FIXED-ROOT root disappeared
2. add esp_mesh_send_block_time to set blocking time of esp_mesh_send
Implementation of `esp_tls_conn_new_sync` now uses timeout_ms value to
give up retries.
Specified this value to be 10 sec. (10 * 1000 ms).
Signed-off-by: Vikram Dattu <vikram.dattu@espressif.com>
Previously if starting/stopping BLE advertising when BLE Mesh
is enabled, the corresponding events will be notified through
the callback registered by esp_ble_mesh_register_prov_callback().
With this commit, the func esp_ble_mesh_register_ble_callback()
needs to be invoked for resgitering the callback used for BLE
coexistence related functionalities (i.e. ADV/SCAN).
* 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
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
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. Support for 16Mbit PSRAM
2. Support for esp32-pico-v3-02
3. Use package identifier to look up SPI flash/PSRAM WP Pin, unless overridden
Closes https://github.com/espressif/esp-idf/issues/7189
Currently IDF_VERSION_* variables are not available to the component
CMakeLists.txt files at the requirements expansion stage. This makes
it harder to write component CMakeLists files compatible with
different IDF versions.
Include version.cmake from the requirements expansion script, add a
build system test.
1. fix TypeError when running with python3
2. fix throughput chart x/y axis label error
3. make test case compatibile with iperf bin on earlier release branches
On Xtensa, backtrace can not recover the two most significant bits of
the address, as the window call size is encoded in these bits.
Because of this, __builtin_return_address modifies these MSBs to
match those of the callee, "fixing" the address. An unfortunate side
effect is that the zero return address, which usually terminates the
backtrace, gets converted to 0x40000000. While there is a valid
instruction at this address, its occurrence in the backtrace is
highly unlikely: this is the first instruction of WindowOverflow4
vector, and IDF apps switch VECBASE to an IRAM location very early at
startup.
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.
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.
On ESP32, due to fifo reset issue, UART2 will work incorrectly if reset the fifo of UART1(TX fifo and RX fifo). The software can workaround the RX fifo reset issue,
while the TX fifo reset issue can not. When UART2 is used and UART1 is used as the log output port, a software reset can reproduce this issue. So we should reset the UART memory
before the software reset to solve this problem.
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
esp_http_server: Add flag in sock_db to identify httpd_sess_close is called from httpd_session_close_lru (v3.3)
See merge request espressif/esp-idf!12115
This commit refactors backtracing within the panic handler so that a common
function esp_backtrace_get_next_frame() is used iteratively to traverse a
callstack.
A esp_backtrace_print() function has also be added that allows the printing
of a backtrace at runtime. The esp_backtrace_print() function allows unity to
print the backtrace of failed test cases and jump back to the main test menu
without the need reset the chip. esp_backtrace_print() can also be used as a
debugging function by users.
Added BD_ADDR comparison in l2cu_lcp_allocate and removed check from
security connection request handler as it's handled in l2cu_lcp_allocate
for both connection request and create connection.
There was no need for this function as there is already a way present to
fetch own mac address. Own mac addr can be fetched by calling
controller_get_interface().
- line was truncated because 64 characters were not sufficient
- length passed to snprintf should be full buffer length, not -1
- make the width of lock name field fixed
- fix alignment of lock type column
1. Add check CSA state before CSA timer process
2. Change wifi scan duration from 120ms to 100ms
3. Using deport reg instead of ahb
4. Check TID in ieee80211_recv_bar()
5. Revert to report specific reason code when receiving deauth during 4-way-handshark
6. Fix the bug that tx ampdu parameter is not from peer device
7. Refactor wifi_interface_t
8. Faster WiFi station connect improvement, avoid 100ms passive scan
9. Add FCS failed packets filter
10.Update esp32 phy lib to v4660
11.Fix csa timer issue
12.Fix country code last byte to space instead of NULL
13.Fix softap cannot forward A-MSDU
14.Fix max tx power to 20dBm
15.Fix the issue that the esp_wifi_sta_get_ap_info can't get country
This commit fixes 'Impersonation in Passkey entry protocol'
(CVE-2020-26558) and suggests fixes for other vulnerabilites like
'Impersonation in the Pin Pairing Protocol' (CVE-2020-26555) and
'Authentication of the LE Legacy Pairing Protocol'
CVE-2020-26558 can be easily implemented if the peer device can
impersonate our public key. This commit adds a check by comparing our
and received public key and returns failed pairing if keys are same.
This commit also adds comments suggesting to use secure connection when
supported by all devices.
WPS can send multiple AP credentials, while existing implementation
will only use the first credentials which could be for the 5G band.
Fix this by passing these credentials to the App and attempting
to connect using each of those. Older Apps will remain compatible
without breaking WPS, but the issue will remain.
esp_http_client: Skip check for redirection counter if status code is success, fix issue with digest auth, configurable user agent string. (v3.3)
See merge request espressif/esp-idf!11600
Rewrite ble dynamic prio to fix ble disconn in conn_param_update/channel_map_update
Rewrite ble dynamic prio in connection establishment
Fix ble dynamic prio with latency
Fix status bit set error when conn fail
Remove description of unusable API esp_wifi_restart()
Update esp_now_fetch_peer discription
Update table format prblm for esp_wifi_set_max_tx_power()
Update description for ssid and password
This commit adds the feature where the CAN ISR will continue to
run even if the cache is disabled. Whilst cache is disabled, any
received messages will go into the RX queue, and any pending TX
messages in the TX queue will be transmitted. This feature should
be enabled using the CONFIG_CAN_ISR_IN_IRAM option.
This commit removes any function calls within
the CAN driver that result in a call to ESP_LOG
whilst inside a critical section.
These function calls are either moved outside
critical sections (e.g., intr_alloc and gpio
functions), or substituted (e.g., assert()).
The issue is caused by:
1. The disable_qio_mode inside read_id may have side effects.
2. read_id twice may have side effects.
Fix this issue by moving disable_qio_mode out of read_id and only do it
once before read_id. And retry read_id only when the first one is
failed.
Issue introduced in 3ecbb59c15.
1. Fix FIX-ROOT does not reconnect to router when disconnect reason is too many
2. Add API esp_mesh_print_scan_result
3. Modify not to reset mesh_xonseq of self and children when flush_upstream_packets
4. Fix not switch to a parent candidate which has the same layer and assoc as current parent
5. Fix not arm parent monitor when a parent candidate is cleared without sending an event to mesh layer
6. Fix the new voted root does not reconnect to router if rssi is weak
Exclude paths that were specified with slash as a path separator were compared
as strings. This would fail on Windows which uses backslash as a path separator.
1. Optimize some debug logs for probe response
2. Optimize phy and soc files
3. Fix the bug that no event for connect
4. Fix the bug that set_channel doesn't work for softAP
5. Drop receiving packets from myself
* Fix the issue that deinit node with "erase_flash"
set to true, but info is not erased from nvs
* Reuse bt_mesh_cfg_reset() when deinit node
* Optimize Provisioner related erase operations
* No store pending timeout will be used when Node
is not provisioned OR Provisioner is disabled
and erase operation is performed
* Change the default timeout for settings operation
to 0, and rpl store rate to 0
When reset the rx info of transport layer, the
rpl list will always cleared, and rpl stored
in the nvs will only be erased when erase flag
is true and BLE_MESH_SETTINGS is enabled.
Compared with the previous solution, it should
be more clear.
Builds on previous commit.
Note: Getting the project version still pases --tags so still works with plain
tags, to keep compatibility for existing projects
For getting secure_version field in anti rollback case, bootloader tries
to map whole firmware partition but fails for cases where partition size
is beyond available MMU free pages capacity.
Fix here ensures to map only required length upto application descriptor
size in firmware partition.
Closes https://github.com/espressif/esp-idf/issues/5911
Since we have provided separate functions for deleting node
information with node's unicast address, device uuid, etc.
So we update the behavior of this function, which will only
be used to delete device information which is not provisioned
or just under provisioning.
Provisioner should always uses the latest IV Index for provisioning.
For example, if the current IV Index is 0x00000001, but prov->iv_index
is still initialized with 0x00000000, and if Provisioner uses prov->
iv_index for provisioning, this will cause the Provisioner failing to
control the node.
So here bt_mesh.iv_index is used instead of prov->iv_index.
- Previously when a model is initialized or deinitialized, in the
access layer, we need to check the model id with the ids in the
table in order to find the proper model operation function.
- Currently all the operation functions of each model will be set
during the mesh initialization. When the model is found, we can
directly use the corresponding callback for different operations.
- Currently only init/deinit operations are registered, later we
will add more operations.
1. add sta connect again ap sent disconnect event
2. add set/get inactive time api
3. fix connect hidden AP doesn't update information
4. add rf test long short support
Currently only keep func pointer for the followings:
- Invalid parameter (mesh btc & mesh stack)
- Out of memory (mesh btc & mesh stack)
- Unknown act (mesh btc)
- Invalid model user data (mesh stack)
- BT_DBG("%s", __func__) (mesh btc & mesh stack)
- A few other specific situations (buf ref debug, send status check)
Different bluetooth host has different behaviors, so it's better
to maintain a scan check mechanism of BLE Mesh itself.
Fixes an issue when only PB-GATT is enabled for node, which will
output a scan error log when the device is provisioned.
Didn't backport the new URL scheme when we updated the toolchain version.
Have put a link on the server so in this case the "osx" toolchain URL remains
valid.
Closes https://github.com/espressif/esp-idf/issues/5720
1. Fix TX DMA buffer issue
2. API esp_wifi_get_config add acquisition sta.listen_interval
3. Configure bandwidth and phy mode to store NVS
4. If AP's tsf has been restarted, STA will disconnect from AP.
5. Do not reset softAP's tsf except it restart
6. Fix the wifi regdomain update bug
7. Fix the bug for airkiss find hidden AP fail
8. Fix addba and first ampdu send bar
9. Fix WiFi fragment issue
10. Fix WiFi fragment issue
This commit fixes a bug as well as changes a behaviour.
Bugfix: During softap/httpd based provisioning, if a session was closed
midway and a new one started, it would never proceed if the http server
assigns same socket number to the new session (which happens almost always).
Now, if a session is closed, using the http callbacks, the older session
data is cleared so that a new one can be created.
Behavioural change: If a client (mobile app particularly) does not use
persistent http session i.e. all provisioning communication on the same
socket, the provisioning may fail. Earlier, since the session context was
not getting cleared, even if the client closed a session and continued
on a new one, it would go through if the socket number assigned was same
(which happens almost always).
Ideally, from a security perspective, all communication related
to secure provisioning must happen on the same socket, and so, this
change is required.
SD cards don't support CMD7 (select_card) in SPI mode. Highspeed probe
of sdspi will fail in this step and stop working in highspeed mode.
Remove the CMD7 in enable_hs_mode_and_check to fix this issue.
Please note that, on ESP32, you have to use the IOMUX pins to use sdspi
in 40MHz, otherwise the initialization process will report reading issue
and fail.
1. If the root is specified (FIXED-ROOT) by set type or set parent, change ie.mesh_type to MESH_ROOT before connect to router.
2. Release esp_mesh_recv_toDS when the root becomes non-root.
3. esp_mesh_set_type now supports MESH_IDLE and MESH_STA.
4. Fix ie.rc_rssi is not updated during scan and vote.
5. Fix ie.mesh_type do not match ie.layer caused by parent switch.
6. Fix during root switch, the original root doesn't disconnect from the router after it receives the switch request from the new voted root. (root switch happens by invoking esp_mesh_waive_root).
7. Fix the routing announce timer is not stopped immediately in a new root if the new root is transformed from non-root.
8. Choose the candidate with less ie.assoc when doing parent switch.
Update send_ttl mainly for server models. When a server model
receives a message, and the status is required to be replied
by the application, we need to set send_ttl to the msg context.
If send_ttl is not updated in btc, and the applcation does not
set the TTL either, then the status will be replied with TTL=0,
which may cause the client side (e.g. the phone App) failed to
receive the status.
Closes https://github.com/espressif/esp-idf/issues/5300
Also remove some redundant CONFIG_BLE_MESH_PROXY checks, because
when the following options are satisfied, the CONFIG_BLE_MESH_PROXY
option will be selected mandatorily.
- Before updating the "beacon_sent" of a subnet, we need to check
if the subnet still exists, especially for a Provisioner.
- Fix a bug which will cause Provisioner failed to send Secure
Network Beacon if no device is provisioned
ctx values to cb_params for the mesh stack.
recv_rssi was not copied.
This means the rssi could not be read when receiving generic server messages using ble_mesh.
Prevent a remote device from doing a Bluetooth Impersonation Attack
(BIAS) by:
- Preventing remote device to downgrade secure connection
feature mask. Secure connection feature mask should remain same or
increase to enabled in link key generation and authentication.
- Doing a mutual authentication during Legacy Authentication.
Move the TAG definition of each example to the corresponding
source file (previously it is defined in the common example
intialization header file), which can avoid the redefinition
of TAG in some situations.
- This issue was introduced in the commit: a788e7cd3d
which updated the bt_hex() function incorrectly.
- And in bt_hex(), we use 2 for the two-dimensional array, because currently
at most two bt_hex() will be used at the same time. Also this will save
some DRAM compared with using 4.
When using DPort to read fifo, fifo_cnt is not credible, we need to calculate the real cnt based on the fifo read and write pointer. When using AHB to read FIFO, we can use fifo_cnt to indicate the data length in fifo.
Some AP's keep NULL-padding at the end of some variable length WPS
Attributes. This is not as par the WPS2.0 specs, but to avoid interop
issues, ignore the padding by reducing the attribute length by 1.
Previously the model recv operation is a littl fuzzy.
With the changes, the model recv operation is splitted into:
- find op
- check app_idx
- check dst
- check length
- update info & handle message
The transport segmented TX nack and seg_pending fields must be at least
6 bits to avoid overflow for 32 segment messages. This change rearranges
the seg_tx fields to gather all state flag fields in one byte, while
making the counter fields whole bytes.
Ensures that friend messages are enqueued, even if the packet is
received with an appkey is unknown to the friend. Previously, sdu_recv
would return EINVAL if the appkey was unknown, which would prevent the
lower transport layer from adding the packet to the friend queue. This
is irrelevant for the logic in lower transport, and should not be
returned as an error.
Previous implementation violated the RFC by having both the actual opcode and WS_FIN flag set for all fragments of a message.
Fixed by setting the opcode only for the first fragment and WS_FIN for the last one
Closes IDFGH-2938
Closes https://github.com/espressif/esp-idf/issues/4974
Since the scripts of CI will bypass components when trying
to get EXAMPLE_PATHS, and these BLE Mesh components will
only be used by other mesh examples, i.e. no need to be
compiled as a single example, so we rename the folder
to componnets.
Device name will be reset when deinit mesh stack. If not
initializing device name during the next mesh stack init,
it will fail to set the device name when using bluedroid.
Since bt_mesh_friend_init() will only be invoked when
a device is provisioned or Provisioner is enabled, so
we add a flag to indicate if the friend functionality
is initialized in case deinit before initialization.
1. fix the bug for softAP update second channel wrong
2. change wifi_scan_time_t from union to struct
3. query country code wrong when policy change from manual to auto
4. fix the crash issue when fetch peer after delete the cur_peer
5. fix the timeout issue of EAPOL four-way handshake
Old version of BLE Mesh has no device role storage, because
previously we only support storing mesh node info.
If the binary of the node is upgraded from old version to a
new version (support storing provisioner info), the mesh info
of the node will not be restored because mesh role does not
exist in the flash.
- Remove the extra #include "bt_common.h" in mesh_timer.c
- Compared with the latest idf, idf3.3 defines BIT(nr) in
the "soc/soc.h" without the pre-condition "#ifndef BIT",
which will cause compile warning when using mesh. So we
include the header file "soc/soc.h" in "mesh_util.h",
which can bypass the definition of "BIT" in "mesh_util.h"
when compiling.
When using fast provisioning, the Provisioner functionality
will be enabled. Unicast addresses within the pre-allocated
range will be used for provisioning nodes. And during the
address assignment, the allocated unicast address will be
checked that if it's duplicated with other nodes addresses
and the Provisioner's own addresses.
So before starting using fast provisioning, we need to update
the Provisioner address.
Since the behavior of sending segmented messages has been
changed properly, the calculation of timeout value which
will be used when sending an acknowledged message by a
client model also needs to be updated.
Add mutex to protect some variables of the mesh segmented
messages.
Currently the timeout handler of mesh will be executed in
the btc task, while the received mesh messages will be
handled in the btu task. In case some variables are set to
NULL when handled in the btu task, meanwhile these variables
are also accessed in the timeout handler, so we add mutex to
protect these variables and related operations.
The publication context is checked for NULL in bt_mesh_model_publish()
however it was dereferenced before that. Move the assignment to
ctx.send_rel to the same place where other ctx members are set.
Split mesh_util.h into mesh_byteorder.h, mesh_compiler.h,
mesh_ffs.h and mesh_util.h based on the classification of
Zephyr, which will make further porting more clear.
The Friend queue uses the message SeqAuth to determine whether the
message is already in the queue. To facilitate this, the SeqAuth is
passed around as a pointer throughout the transport modules. In the
bt_mesh_ctl_send functions, this parameter is also exposed in the API,
but the internal usage is inconsistent and buggy. Also, no one actually
uses this parameter.
- Removes seq_auth param from bt_mesh_ctl_send, instead passing NULL
directly to the friend module, to enforce its addition to the queue.
- Makes the seq_auth pointer const throughout the friend module.
Changes the behavior of the message cache to optimize for cache
capacity. Previously, the message cache's primary function was to avoid
decrypting messages multiple times, although the cache's main function
in the spec is to avoid message rebroadcasting. Optimizing for minimal
decryption causes us to fill the network cache faster, which in turn
causes more cache misses, potentially outweighing the advantage.
Now stores src + seq in message cache instead of field hash value. This
cuts cache size in two, while including more of the sequence number than
before.
Adds messages to the cache only after the packet is successfully
decrypted. This reduces noise in the cache, and ensures that no
invalid deobfuscations are added.
Additionally, this fixes a bug where multiple calls to net_decrypt with
the same packet failed, as the message cache found its own entry from
the previous call.
Implements several changes to the transport layer segmented tx to
improve group message performance:
- Moves retransmit counter to tx context instead of per packet. As every
unacked packet is sent every retransmit, the retransmit counters would
be the same in each segment. This makes it easier to control progress.
- Delays the scheduling of the retransmit until the completion of the
last segment by adding a seg_pending counter. This is essentially the
same as the old behavior, except that the old behavior might retrigger
the sending before all segments are finished if the advertising is
slow.
- Allows the group transmits to stop as soon as all retransmits have
been exhausted, instead of timing out waiting for acks that won't
come. This allows group tx to finish without error.
- Fixes a bug where a failed TX would block IV update.
- Cancels any pending transmissions of acked segments.
- Reduces log level for several common group tx scenarios that aren't
erronous.
Backport of https://github.com/apache/mynewt-nimble/pull/724
Mesh spec 1.0.1 changes proxy disabling behavior to only affect the
relaying from proxy nodes. Previously, disabling proxy would shut down
all proxy and node activity.
Tweaks from the original commit:
- Removed redundant call to bt_mesh_adv_update() in gatt_proxy_set()
- Removed invalid ref to 4.2.11.1 in node_identity_set()
---
According to Mesh Profile Spec 1.0.1, Section 4.2.11:
"If the Proxy feature is disabled, a GATT client device can connect
over GATT to that node for configuration and control. Messages from
the GATT bearer are not relayed to the advertising bearer."
Moreover some notes have been removed from the spec compared to
version 1.0:
Mesh Profile Spec 1.0, Section 4.2.11:
"Upon transition from GATT Proxy state 0x01 to GATT Proxy state 0x00
the GATT Bearer Server shall disconnect all GATT Bearer Clients."
"The Configuration Client should turn off the Proxy state as the last
step in the configuration process."
Mesh Profile Spec 1.0, Section 4.2.11.1:
"When the GATT Proxy state is set to 0x00, the Node Identity state
for all subnets shall be set to 0x00 and shall not be changed."
Until now the choice of reliable sending (segmented messages with
acks) was implicitly dependent on the size of the payload. Add a new
member to the bt_mesh_model_pub to force using segment acks even when
the payload would fit a single unsegmented message.
When PB-GATT support has been enabled the provisioning code "borrows"
the buffer from the proxy code. However, the way that initialization
was happening the proxy buffers were initialized only after
provisioning initialization, resulting in a corrupted buffer with
buf->data pointing to NULL. Reorder the initialization calls so that
proxy is done first and provisioning only after it.
Allow models to skip a periodic publish interval by returning an error
from the publish update callback.
Previously, an error return from publish update would cancel periodic
publishing. This can't be recovered from, and as such, no valid model
implementation could return an error from this callback, and there was
no way to skip a periodic publish.
The function bt_mesh_ctl_send() used to support maximum length of
11 bytes. The segmentation complies with the BLE Mesh Standard.
The ack is disabled in case of non unicast address.
When fast provisioning is enabled, Provisioner shall not
ignore messages from the nodes whose addresses are not in
the provisioning database. Because other nodes which are
not provisioned by the Primary Provisioner will send node
address messages to the Primary Provisioner.
This MR imposes some determinism in the mapping rule order in the output
file. For each section, the archives are arranged alphabetically
(ascending), and the mapping rules in each archive are arranged by
increasing specificity then alphabetically (ascending). The default
rules remain the very first rule for each section.
Previously only mesh node info is supported to be stored
in flash. So when trying to reset the node, we only need
to judge if the BLE_MESH_VALID flag is set.
Currently we support storing both node & Provisioner info
in flash, when trying to erase the node info from flash,
the BLE_MESH_NODE flag will be checked. So we need to set
bt_mesh.flags to 0 when all the erase operations are done.
It was observed that after sending credentials, if the first
Wi-Fi conection attempt fails, the Wi-Fi provisioning managager
ignores subsequent Wi-Fi events. So, even if the device eventually
connects to the AP, the provisioning stays on indefinitely.
Changing a check so that subsequent events are also captured and
provisioning finishes successfully.
esp_mqtt_abort_connection: Fixed an issue which could result in a race condition and subsequent crash
esp_mqtt: Change an error print to use ESP_LOGE instead of ESP_LOGI
Move Sending MQTT connect message log from Info to Debug level
docs: Makes clear that publish API could block
Change the message printed after MQTT connection failure
During BLE Mesh Provisioner initialization, the stack will restore
the nodes information if settings storage is enabled.
Previously when a failure happens (e.g. found the same uuid) during
the restore procedure, the information of the following nodes will
not be restored and error will be directly returned.
But this will introduce some problem with user experience, because
some newly provisioned nodes information will not be restored and
Provisioner will not be able to control those nodes.
So we change the operation here, when a failure happens during the
restore procedure, Provisioner will only ignore the information of
the current node and continue restoring other nodes information.
With this change, if a Provisioner has provisioned the maximum
number of nodes, it can still report the unprovisioned device
beacon from other nodes to the application layer. And this will
be more reasonable compared with the previous implementation.
Previously when the node array of Provisioner is full, no beacon
from unprovisioned devices will be reported, only some warning
logs will be given.
Previously only check the node address when it is assigned by the
application layer. Here we also check the address when the address
is allocated internally. And this will be useful when some mesh
internal tests are performed.
Previously the BLE_MESH_MAX_STORED_NODES option is added for
internal mesh test, which will be a little confusing for the
users to understand.
Here we remove this option, instead the BLE_MESH_MAX_PROV_NODES
will be used for all the cases. For mesh internal test, when
the test function is called to add some nodes info, the info
will be stored in the array of provisioned nodes directly.
The replay protection list of Provisioner should be at least equal
to the number of nodes with the precondition that each node contains
only one element.
The help information of replay protection list is updated, and the
maximum number of nodes for Provisioner is adjusted based on the
replay protection list size.
Fixes an issue with Python 3 in MSYS where it fails while trying to join
paths where one part is Unicode (default string on Python3) and the
second part are bytes (returned by the subprocess call).
Closes https://github.com/espressif/esp-idf/issues/5189
Using the ble mesh white list test functions, a node can choose to
only receive mesh messages from a specific node and relay the
messages for it. Messages from other nodes will be ignored.
Commit fc03161f updated esp_ota_get_app_elf_sha256 to store and return
X number of bytes of the hash, but the test case still expected 64 bytes.
Updated test case to use CONFIG value for expected length.
1. add enable PSRAM 2T mode function
2. abort when himem and 2T mode are enabled meanwhile
3. set SPIRAM_2T_MODE as "n" by default, enable it when needed
transport_ws can now be read multiple times in a row to read frames larger than the buffer.
Added reporting of total payload length and offset to the user in websocket_client.
Added local example test for long messages.
Closes IDF-1083
Backport following Wifi fixes:
1. Optimize WiFi sleep in WiFi/BT coexist mode
I> If any data TX/RX in WiFi slice, force wakeup next TBTT
II> Increase active timeout to coex TBTT to avoid sleep in WiFi slice
2. Fix esp_wifi_stop() crash
esp_wifi_stop() crashes if it's called when WiFi is not initialized.
3. Fix WiFi log print level
4. Return fails if AP's configuring AP channel is out of range
5. esp_wifi_sta_get_ap_info() returns actual values of group ciphers
Problem:
mbedtls_ctr_drbg_context was initialized in crypto_ec_point_mul. This
was okay in releases before 2.16.4 as entropy_len used to get set to
MBEDTLS_CTR_DRBG_ENTROPY_LEN in function mbedtls_ctr_drbg_seed. The
function is now changed to set the length to
MBEDTLS_CTR_DRBG_ENTROPY_LEN if previous length is 0 and hence the bug.
Solution:
Initialize mbedtls_ctr_drbg_context in crypto_ec_point_mul.
Wifi_provisioning: Change service_uuid to non standard 128 bit UUID and add retries in test script (backport v3.3)
See merge request espressif/esp-idf!8164
Fixes an issue where build fails if the build directory is a symlink.
The issue is caused by the rule target and the final executable dependency
not matching.
Closes https://github.com/espressif/esp-idf/issues/3626
When a handler instance is the last one in the list und unregisters
itself, the handler iterator will be invalidated by entering free'd
memory. Same applies for event base and id, if they become empty.
Merges https://github.com/espressif/esp-idf/pull/4139
getc, getchar, putc, putchar were defined both as functions and as
macros. The macro versions are not thread safe, and should not be used
in multithreaded applications.
Upstream fix: b0f271d1db
The NimBLE host buffers that consume a significant amount of memory are
now allocated dynamically.
The advantage is that, the memory can be reclaimed in cases where BLE
is turned off and not required for the current boot cycle
- Add menuconfig option for NimBLE host flow control
- Include changes in `blecent` example from upstream PR!702
- add ble_hs_lock in ble_gap_unpair Upstream PR!584
- ble_hs_hci_rx_evt, upstream PR!738
1. Add wifi stop check at wifi deinit entry.
2. Add TX packets size check.
3. Reduce wifi bin size.
4. Fix the bug for setting channel when wifi in NULL mode.
5. Place the Vendor Specific element at the end according to the protocol.
6. Coex adjust scheme when bt is in connnected status.
The global interrupts will be disabled before taking current
time for scheduling further bluetooth events. Earlier disabling
interrupts was taking some time because of which WiFi events were
interrupting in current bluetooth scheduling.
Also fixes ble crash issue triggered by ble event irq miss (0x20000).
1. The fault signal 3 for unit 2 is corrected to the right value
2. Now `mcpwm_fault_set_oneshot_mode` will clear the status before, no
need to reset the peripheral.
3. The capture feature relies on the prescaler, but it's only
initialized in the mcpwm_init funciton, which is used to initialize a
PWM channel. This means, the capture may not work correctly if no PWM
channel is enabled.
Now the prescaler is also updated when `mcpwm_capture_enable` is
called.
Fix an error of mesh deinit lock.
Fix mesh send returns TIMEOUT.
Increase root window close time to 120s.
Clear ie.child when the child connected or fully associated.
Update rc_rssi when roots direct/forward.
ix assoc in mesh ie wrong.
Mesh packets use AC_VI instead of AC_BE.
this issue is mainly exposed when using larger (4096) client key in TLS mutual auth,
since it uses multiplications > 2048 when mbedtls_mpi_mul_mpi is used in recursion,
which works only if both operands point to different location than result since
mpi_mult_mpi_overlong() called mbedtls_mpi_grow() to reallocate buffers used in previous
pointer arithmetics and thus corrupting it. Fixed by growing the mpi buffer before
calling mpi_mult_mpi_overlong()
components/esp_wifi: improve coexistence performance according to specific WiFi/BT/BLE scienario (Backport v3.3)
See merge request espressif/esp-idf!7410
1. Improve WiFi throughput in some Classic BT scienarios(idle, inquire scan,
connected, sniff, a2dp pause, etc).
2. Support WiFi + Classic BT + BLE mesh coexistence scienario.
3. Improve WiFi scan and connect succeed ratio in coexistence scienario.
4. Do not support to choose software coexistence preference anymore for it is
determined according to coexistence scienario automatically.
components/lwip: increase TCP send buffer and receive window limitation when TCP window scale is enabled
components/ble_mesh: Fix some bugs about ble mesh
1. fix send acl pkt after ble have sent terminate ind modify min adv interval to 10ms.
1. BLE Mesh Core
* Provisioning: Node Role
* PB-ADV and PB-GATT
* Authentication OOB
* Provisioning: Provisioner Role
* PB-ADV and PB-GATT
* Authentication OOB
* Networking
* Relay
* Segmentation and Reassembly
* Key Refresh
* IV Update
* Proxy Support
* Multiple Client Models Run Simultaneously
* Support multiple client models send packets to different nodes simultaneously
* No blocking between client model and server
* NVS Storage
* Store BLE Mesh node related information in flash
* Store BLE Mesh Provisioner related information in flash
2. BLE Mesh Models
* Foundation Models
* Configuration Server Model
* Configuration Client Model
* Health Server Model
* Health Client Model
* Generic
* Generic OnOff Server
* Generic OnOff Client
* Generic Level Server
* Generic Level Client
* Generic Default Transition Time Server
* Generic Default Transition Time Client
* Generic Power OnOff Server
* Generic Power OnOff Setup Server
* Generic Power OnOff Client
* Generic Power Level Server
* Generic Power Level Setup Server
* Generic Power Level Client
* Generic Battery Server
* Generic Battery Client
* Generic Location Server
* Generic Location Setup Server
* Generic Location Client
* Generic Admin Property Server
* Generic Manufacturer Property Server
* Generic User Property Server
* Generic Client Property Server
* Generic Property Client
* Sensor Server Model
* Sensor Server
* Sensor Setup Server
* Sensor Client
* Time and Scenes
* Time Server
* Time Setup Server
* Time Client
* Scene Server
* Scene Setup Server
* Scene Client
* Scheduler Server
* Scheduler Setup Server
* Scheduler Client
* Lighting
* Light Lightness Server
* Light Lightness Setup Server
* Light Lightness Client
* Light CTL Server
* Light CTL Setup Server
* Light CTL Client
* Light CTL Temperature Server
* Light HSL Server
* Light HSL Setup Server
* Light HSL Client
* Light HSL Hue Server
* Light HSL Saturation Server
* Light xyL Server
* Light xyL Setup Server
* Light xyL Client
* Light LC Server
* Light LC Setup Server
* Light LC Client
3. BLE Mesh Applications
* BLE Mesh Node
* OnOff Client Example
* OnOff Server Example
* BLE Mesh Provisioner
* Example
* Fast Provisioning
* Vendor Fast Prov Server Model
* Vendor Fast Prov Client Model
* Examples
* Wi-Fi & BLE Mesh Coexistence
* Example
* BLE Mesh Console Commands
* Examples
Even if frame->exccause != PANIC_RSN_CACHEERR, it is possible that
the cache error interrupt status is set. For example, this may happen
due to an invalid cache access in the panic handler itself.
Check cache error interrupt status instead of frame->exccause to
decide whether to do CPU reset or digital reset.
Also remove unnecessary esp_dport_access_int_pause from
esp_cache_err_get_cpuid, since the panic handler already calls
esp_dport_access_int_abort on entry.
implemented workaround in idf_monitor for known usbser.sys bug which
causes changes in RTS signal to only be sent if DTR signal also changes.
Works by forcing a dummy change in DTR signal (re-assigning its current
value, as it has previously been done in the flashing tool)
Closes https://github.com/espressif/esp-idf/pull/4676
Fix A2DP stuck when BLE's interval is too small
Bugfix that bluetooth controller may not be able to enter sleep after end of wake up request
Fix LMP sniff req timeout
components/esp_https_ota: Changes in public requirement list for CMake and esp_ota_ops.h is included in esp_https_ota.c
bootloader_support is added in public requirements of CMake
bootloader_common.h is included in esp_https_ota.h
Closes https://github.com/espressif/esp-idf/issues/4198
Closes IDFGH-2066
Current implimentation of esp_http_ota does not perform any error-checking in the data writing phase calls `esp_ota_get_next_update_partition()` irrespetive of the received state of the image. A few additional error checking mechanism have now been added inside the esp_https_ota which returns the control in case an invalid header is received and a wrapper to the function `esp_http_client_is_complete_data_received()` of `esp_http_client` has been added.
While downloading OTA firmware, if their is a Origin Respnse Timeout or the binary is only partially downloaded, OTA failure is observed. Checking binary size can also be helpful for simple http client applications.
Closes https://github.com/espressif/esp-idf/issues/3004
If an application wants to use webserver, instead of creating another
webserver instance, the wifi provisioning manager can re-use the same.
The webserver handle can be passed using this new API.
Signed-off-by: Piyush Shah <piyush@espressif.com>
Regression introduced in commit 79e74e5d5f
It is possible that some FreeRTOS APIs are invoked prior to
scheduler start condition (e.g. flash initialization in unicore mode).
In that condition these asserts should not trigger (scheduler state being yet to be started),
hence changes per this fix.
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.
Closes https://github.com/espressif/esp-idf/issues/4230
Latest versions of apt-get don't install as much packages by default
as older ones. This fix adds some missing packages discovered for an OS
derived from the latest stable Debian. These packages exist for older
Debian derivatives as well (tested with Ubuntu 16.04 LTS).
Closes https://github.com/espressif/esp-idf/issues/4480
Fixes an issue where if idf_build_process is called in a CMake
subdirectory, menuconfig looks for the mconf-idf binary in the wrong
place (in the subdirectory build dir instead of root binary dir).
arg1 = MAX(int64_t arg1, uint64_t arg2) gave the wrong result, if arg1 < 0, it was presented as a larger value.
And ALARM_REG = (uin32_t)arg1. This leads to an infinite loop.
Fixed: both args are int64_t.
Closes: WIFI-1511
1. Fix WiFi scan leads to poor performance of Bluetooth.
2. Improve WiFi connect success ratio when coexist with Bluetooth.
3. Check if WiFi is still connected when CSA or beacon timeout happen.
4. add coex pre init
These features are not supported in the CMake build system preview, but previously
had to read the notice in the CMake Getting Started guide to know this.
Related to https://github.com/espressif/esp-idf/issues/4419
Sometimes, libphy.a call phy_enter_critical() to protect accessing critical sections, such like
operating on I2C, but it may not effect when both the CPU core call it. It may cause accessing
I2C blocking and cannot recover by esp_restart(), until do HW reboot.
1. revision defined in bot message
2. branch name (or tag name) of current IDF
3. CI_MERGE_REQUEST_TARGET_BRANCH_NAME
4. branch name parsed from `git describe`
5. default branch
The workaround for PSRAM that will occupy an SPI bus is enabled only when:
1. used on 32MBit ver 0 PSRAM.
2. work at 80MHz.
The test used to only check 32MBit by the config option, but for PSRAM
on Wrover-B module seems to use a newer version of 32MBit PSRAM. So it
expects the workaround to be enabled, but actually not.
This commit split the unit test into two parts:
1. check all SPI buses are available, for all configs except psram_hspi
and psram_vspi, run on regular runners (including Wrover and Wrover-B).
a hidden option is enabled so that the compiler knows it's not building
psram_hspi or psram_vspi.
2. check the specified bus are acquired, for config psram_hspi and
psram_vspi. This only run on special runner (legacy Wrover module).
Some APs incorrectly advertize newer WPS2.0 config method bits
without setting bits for the corresponding older methods. This
results in failures during 8-way handshake. Add a workaround to
relax this check so that WPS handshake can proceed.
The MQTT broker URL used as default in the examples has ceased operation. All examples and documention have been updated to point to the new domain mqtt.eclipse.org.
This also required an update of the python example test scripts to use TLS 1.2
1. Fix high beacon and broadcast packets loss ratio of WiFi to make
MDNS test pass.
2. Improve stability of WiFi performance with a little
sacrifice of throughput.
3. Improve BLE advertising and connection performance with dynamic
priority. It sacrifices a little WiFi throughput, but achieves balance
between WiFi and Bluetooth.
4. fix bug bb reset lock flag to avoid bb reset lock unhandle
5. fix bug wifi reset mac cause task watch dog timeout
6. fix bug wifi reset mac position
1. Since BLE full-scan feature for BLE mesh change the controller code cause this problem,
it cause coex semaphore take in "interrupt disable", then it may cause task schedule
and cause crash in freertos
2. Fix newlib lock ISR context and critical section check
3. Fix bt controller ISR context and critical section check
This commit fixes multiple bugs caused by incorrect calls to
can_enter_reset_mode() and can_exit_reset_mode. Example test
scripts also updated to match new runners.
Basically, in the portability layer, it is checked if the socket is
NON-block, and if not, then even the EAGAIN and EWOULDBLOCK errors are
diverted to a RECV error. This causes a problem for sockets with
receive timeouts set. When such a timeout is set, the condition for
NON_BLOCK isn't met and hence a hard error is returned.
Searching for EAGAIN and EWOULDBLOCK in lwip returns only 3 results
(accept, recvfrom, close) and all of them look to be genuine cases for
EWOULDBLOCK. So removing this check to make receive timeout with TLS
work.
Includes all the latest NimBLE stack changes from idf-v4.0 with few idf-v3.3
specific modifications.
- Addition of nimble component as submodule (`nimble-1.1.0-idf-v3.3`), contains
IDF v3.3 specific minor changes.
- Example applications are identical to idf-v4.0
- Modification in `bt/Kconfig` to accommodate NimBLE as a BT host.
Fix following WiFi bugs:
1. Fix the bug that wpa2 enterprise sta can connect open AP
2. Fix TKIP/CCMP PN replay attack detection bug
3. Increase buffer number type from uint8_t to uint16_t to support more than 255 buffers
4. Avoid recalculating PMK if esp_wifi_set_config() is not called
5. Fix the bug that scan done leads to crash because of uint8 overflow
6. Fix 5.5M signal test bug
ICY URIs e.g `http://uk1.internet-radio.com/proxy/vombat?mp=/;` need to
be handled differently.
For basic use case, these URIs are similar to HTTP with exception that they reply with `ICY 200` etc in place of `HTTP/1.1 200`.
In http_parser, we now also parse ICY URIs to be able to handle these similar to HTTP.
Signed-off-by: Vikram Dattu <vikram.dattu@espressif.com>
incorrect set of the MB_EVENT_COILS_WR event is changed while read coils in mbcontroller.c file
added read/write handling for appropriate registers in freemodbus.c example file
Closes https://github.com/espressif/esp-idf/issues/3289
Bugfixes:
- Fix http url redirection issue
- Fix basic/digest auth issue with http url
Features:
- Add support for adding custom http header
- Add support for reading firmware image header
- Add support for monitoring upgrade status
- This requires breaking down esp_https_ota API such that it allows finer application level control
- For simpler use-cases previous API is still supported
Closes https://github.com/espressif/esp-idf/issues/3218
Closes https://github.com/espressif/esp-idf/issues/2921
There was existing support for adding authorization info in esp_http_client
but it was functional only while using `esp_http_client_perform` API. This commit just moves
existing authorization addition logic into publicly exposed API.
Acquires PM_APB_FREQ_MAX lock when carrying any transaction on I2S if
Power Management Framework is enabled.
Signed-off-by: Sachin Parekh <sachin.parekh@espressif.com>
Acquires PM_APB_FREQ_MAX lock when carrying any transaction on I2C if
Power Management Framework is enabled.
Signed-off-by: Sachin Parekh <sachin.parekh@espressif.com>
Currently, the only way of exiting the idf_monitor program is to hit the CTRL+] button, if your keyboard doesn't have that key unless you hit another modifier key, it's not super trivial to exit.
This change adds the option to exit with CTRL+T (for menu) then hitting X (or CTRL+X) for exiting.
Closes https://github.com/espressif/esp-idf/pull/4167
Closes https://github.com/espressif/esp-idf/issues/4129
1. add kconfig help for GPIO0 output mode
2. fix a bug when select gpio0 output mode and initialize psram
3. make default config to official development board
4. fix wrong LAN8720 register index
Previous version read all data to the buffer including header which reduced maximum payload read. This version uses a local array to receive header and reads payload bytes to the buffer
cherry-picked from db121a56e1
1.Fix the bug that WiFi stop leads to task watchdog(526c6956)
2.Fix the WiFi init sequence bug
3.Fix smartconfig ipc crash
4.Put g_promis_buf to IRAM
5.esp_wifi_set_channel should return error when sniffer is not enabled
6.fix the bug when set WEP authmode or wrong authmode, there is no error return
7.fix the bug that STA parse authmode wrong when AP sets WPA_WPA2_PSK mode
8.fix the bug that wrong error code and wrong event when there is an auto AP in multi-ssid case
- Backport(v3.3) of IDF MR!6122
- Modifies `smp_utils.c` to add check on encryption key size received from
peer.
- Modifies `esp_ble_gap_set_security_param` API to add minimum encryption key
size requirement.
Remove xtensa/xruntime.h
Fix sending Lmp_feature_req_ext in a loop
Fix 2 bugs in r_ld_fm_sket_isr
fix data loss and send same pkt twice sometimes
fix adv data error in air sometimes
fix adv start/stop crash sometimes
Fix connect fail with some speakers
clear BT/BLE interruots after controller disable
add sco_data_path to be set in sdkconfig and do not reset the value upon HCI reset command
1. modify the limit of frames to send to avoid dropping packet on A2DP source due to TX data queue overflow
2. reduce the A2DP source data queue size in order to achieve faster control respnonse
l: Try to allocate some L memories in SPIRAM first. If failed, try to allocate in internal RAM then.(Backport v3.3)
See merge request espressif/esp-idf!5671
Reported in https://github.com/espressif/esp-idf/issues/3299
If a config item contains a reserved filename in Windows like _CON_ then an invalid
directory is created.
We don't rely on this feature all, so disable it.
This MR is intended to fix incorrect parsing of HTTP requests when empty header values are present.
The issue is was due to asymmetric behavior of `http_parser` library, which in case of:
non-empty header values : invokes callbacks with the pointer to the start of a value
empty header values : invokes callbacks with pointer to the start of next header or section
Since HTTP server relies on this pointer (along with length of the value) to locate the end of a value, and replace the line terminators (CRLFs) with null characters, the second case needed to be handled correctly.
Closes IDFGH-1539
Closes https://github.com/espressif/esp-idf/issues/3803
If httpd_sess_trigger_close() gets called twice for the same socket,
the first httpd_sess_close() cb closes the correct socket, but the second
invocation closes the wrong socket which was just accepted and added to
the socket db. Checking for the lru counter will help identify this as the
counter is set only for requests actually served.
We fixed some flash bugs in bootloader, but for the users used the old
vrsion bootloader, they can not fix these bugs via OTA, the solution is
add these updates in app startup.
These updates include:
1. SPI flash gpio matrix and drive strength configuration
2. SPI flash clock configuration
3. SPI flash read dummy configuration
4. SPI flash cs timing configuration
5. Update flash id of g_rom_flashchip
Hardware AES-CBC performance changes:
Release config 11.0MB/sec -> 10.8MB/sec
Debug config 9.4MB/sec -> 9.8MB/sec
(Unrolling the loop to optimize the check improves
performance at -Og, even with the fault check.)
Made MMU pages available check in `esp_image_format.c`
This now makes it possible to map and process bootoader image as well in chunks when image doesn't fit completely into available free pages.
Signed-off-by: Vikram Dattu <vikram.dattu@espressif.com>
There are lot of prints of `Allocate TX buffer for DMA`
Changed these from `ESP_LOGI` to `ESP_LOGD`
Signed-off-by: Vikram Dattu <vikram.dattu@espressif.com>
This problem may cause HCI send command timeout.
When host call VHCI api to do btdm_wakeup_request, then controller
wakeup process will be handled in ISR and controller task context.
As host task priority is lower than controller task and ISR,
it will cause an incorrect behavior that before VHCI take the
rx_flow_on_semaphore, controller sleep again, then VHCI cannot take
the semaphore and has to wait the automatic wakeup.
On flash program operation (either erase or write), if corresponding address has
cache mapping present then cache is explicitly flushed (for both pro and app cpu)
Closes https://github.com/espressif/esp-idf/issues/2146
Other changes:
* Command line argument name and descriptions updated and formatted
* Some exception messages updated for clarity
* READMEs updated for tool and all provisioning examples
* Minor update in example test scripts due to change in esp_prov.get_transport() API
* Transport_Softap renamed to Transport_HTTP
* Transport_HTTP now forces connect on initialization
These changes guarantee that the SSID and Passphrase received via protocomm are NULL terminated and size limited to their standard lengths.
List of changes:
* Corrected length of passphrase field in wifi_prov_config_set_data_t structure
* Performing length checks on SSID, passphrase and bssid, when populating wifi_prov_config_set_data_t structure with received credentials
1. resend eb which are pending in g_ic.tx_buf due to channel switch.
2. add lock for mgmg/xon/bcast to protect send from user flush.
3. softap: add check if secondary offset is correct when start softap.
4. softap: in inactive timer handler, add check if child bss is removed to avoid removing it again.
5. disable A-MPDU for non-root.
6. fix reusing a freed eb.
7. fix when node becomes root, it does not record assoc value to nvs.
8. discard unnecessary forwarded group packets.
9. fix toDS state is not updated in time.
10. fix s_sta_cnx_times is not cleared when deinit causes root sends ADD annoucement.
11. root: increase beacon timeout time from 6 seconds to 15 seconds to delay initiation of reconnection.
12. add esp_mesh_get_tsf_time to return TSF time.
13. send the whole routing table multi-times.
14. clear candidate settings if not receive candidate beacon within 8 seconds.
When flash work in DIO Mode, in order to ensure the fast read mode of flash
is a fixed value, we merged the mode bits into address part, and the fast
read mode value is 0 (the default value).
open_fn() was introduced in the context of HTTPS server, as a configurable callback function that is called by the HTTP server, on every newly created socket. It is responsible of allocating resources for per session transport security.
Earlier, if open_fn were to fail, the newly created socket would be closed by the server but the corresponding entry, for the now invalid socket, will remain in the internal socket database until that invalid socket is detected due to error when calling select(). Because of this delayed closing of sockets, the HTTPS server would quickly face shortage of available sessions when a lot of SSL handshake errors are happening (this typically occurs when a browser finds that the server certificate is self signed). This changes in this MR fix this issue by clearing up the socket from internal database, right after open_fn fails.
Closes https://github.com/espressif/esp-idf/issues/3479
List of changes in components/wifi_provisioning:
* Manager version is now v1.1
* .proto files and protocomm handler added for sending Wi-Fi scan command and receiving scan results
* Implemented handlers for wifi_scan protocomm endpoint
* Update manager context data structure to hold scan state and results
* scheme_softap now runs Wi-Fi in APSTA mode
* Wi-Fi is started in AP mode when provisioning is started. This is necessary for scan list to work
* Docs updates with information about new wifi_scan endpoint
List of changes in tools/esp_prov:
* Added functions for sending and receiving protobuf messages compatible with wifi_scan protocomm endpoint
* Added feature to display/refresh scan results and accept user selection at runtime
* New functions:
* get_version() : only returns the protocol version string
* has_capability() : check is a capability is present according to proto-ver response
* wifi_scan feature is provided only if the `wifi_scan` capability is present
Other changes:
* Replace recursive mutex with plain mutex
* assert on return value of mutex give / take calls
* replace all calls with macros ACQUIRE_LOCK and RELEASE_LOCK
* some checks added in scanning related private APIs
* free and nullify scanning context and state if service is stopped while ongoing scan
port*_CRITICAL_SAFE API calls port*_CRITICAL or port*_CRITICAL_ISR
depending on the context (Non-ISR or ISR respectively).
FREERTOS_CHECK_PORT_CRITICAL_COMPLIANCE Kconfig option added
Signed-off-by: Sachin Parekh <sachin.parekh@espressif.com>
xTaskIncrementTick have to unwind uxPendedTicks on CPU1 and CPU0.
Use case: If an erase operation was run on the CPU1 then it leads
to starving other tasks which waiting time. Waited tasks just skipped.
Closes: https://github.com/espressif/esp-idf/issues/1952
Closes: IDF-183
Fixed the case when the first part of log was missed
this was happened when:
* CONFIG_CONSOLE_UART_CUSTOM option is selected (UART1)
* The selected CONSOLE_UART port is used also for the console component
* in code esp_restart() or abort() functions were called.
List of changes:
* Retrieve UUID property from Bluez device object before connecting to retrieve UUID contained in advertisement
* Read Characteristic User Descriptions attribute of each UUID for mapping endpoint names
* To support older implementations with hardcoded Name-UUID map, revert to fallback mode in order if advertisement data has no UUID field
List of changes:
* Use 128 bit characteristic UUIDs when creating GATT table entries
* Change primary service attribute value to 128 bit custom service UUID
* Use raw advertisement data to convey flags and 128 bit primary service UUID
* Use raw scan response to send device name as complete local name
* Increase maximum device name length in relation to maximum scan response length
* Set Characteristic User Description attributes for each characteristic to convey protocomm endpoint names
List of changes:
* Kconfig option HTTPD_LOG_PURGE_DATA enables logging of purged data
* Kconfig option HTTPD_PURGE_BUF_LEN sets purge buffer length
* Purged data is logged in hex
Closes https://github.com/espressif/esp-idf/issues/3359
Fix following wpa2 enterprise vulnerability issues:
1. The station can complete 4-way handshake after EAP-FAIL is received
2. The station crashes if EAP-SUCCESS is received before PMK is setup
Issue is that when users creates a custom bootloader from
$IDF_PATH/components/bootloader. Parent project build uses the copy but
bootloader subproject build uses the original still. The issue is solved
by passing the custom bootloader as extra component directory so
bootloader build knows to use the new copy (itself) in the build.
This prevents a device from being bricked in case when both secure boot & flash encryption are enabled and encryption gets interrupted during first boot. After interruption, all partitions on the device need to be reflashed (including the bootloader).
List of changes:
* Secure boot key generation and bootloader digest generation logic, implemented inside function esp_secure_boot_permanently_enable(), has been pulled out into new API esp_secure_boot_generate_digest(). The enabling of R/W protection of secure boot key on EFUSE still happens inside esp_secure_boot_permanently_enable()
* Now esp_secure_boot_permanently_enable() is called only after flash encryption process completes
* esp_secure_boot_generate_digest() is called before flash encryption process starts
Issue : Restarting the server without 30sec delay between httpd_stop() and httpd_start() causes EADDRINUSE error
Resolution : Use setsockopt() to enable SO_REUSEADDR on listener socket
Closes https://github.com/espressif/esp-idf/issues/3381
This change prevents buffer overflows in case of really long file paths.
Other changes:
* Remove query (?) and fragment (#) component from URI when converting to file path
* /index.html and favicon.ico can be overridden by files with same name and path in SPIFFS
* README.md updated
Fixed adjtime function: While using the adjtime() function,
the time correction accumulated an error
when reading the time frequently (using gettimeofday).
Operation:
In `esp_http_client_set_url`, we check for if old_host is same as new_host.
Delete and open new connection if host is different.
Issue:
We just pointed `client->connection_info.host` to `old_host` and reassigned it.
This made old_host and new_host always point to same location and hence, using old_host with new request.
Fix:
Made a separate copy for old_host using strdup.
Closes https://github.com/espressif/esp-idf/issues/2631
Signed-off-by: Vikram Dattu <vikram.dattu@espressif.com>
1. Softap support multicast and broadcast saving and flushing when the associated stations enable IEEE80211 legacy power save(which is called modem sleep in ESP32).
2. Improve the frame saving and flushing mechanism of softap power save.
Earlier eraseItem function in Storage class would do lazy cleanup of
multi-page blobs if called using type "ANY" instead of "BLOB". It used to
just delete BLOB data and index would remain as is. Any subsequent read
would delete index entry as well. This however would return a valid
length without error if nvs_get_blob API was just used for finding
length and not reading the complete blob. This change fixes this issue.
Closes https://github.com/espressif/esp-idf/issues/3255
1. remove redundant SPI clock settings, use rom functions to set clock.
2. remove redundant SPI cs setup and hold settings.
3. for old 32Mbit psram, cs hold time must only be 0.5T due to the special driving mode.(cs_setup = 0; cs_hold = 0)
4. for new 64Mbit psram, cs hold time is recommended to be 2.5T. (cs_setup = 1, cs_setup_time = 0;cs_hold = 1, cs_hold_time = 1)
1. Pass the correct conn_id to protocomm_req_handle
In transport_simple_ble_write(), passing param->exec_write.conn_id would
be invalid. Instead param->write.conn_id should be passed
Similar change in transport_simple_ble_exec_write() to use
param->exec_write.conn_id
2. simple_ble_start() assumes that the mode is BLE only and enables
Bluetooth controller accordingly. For, cases having BT + BLE like Alexa
(Provisioning over BLE + Audio over classic BT), this assumption should
be removed.
Linker script generator produces build/esp32/esp32.common.ld from
components/esp32/ld/esp32.common.ld.in
This works fine until IDF is downgraded to V3.1 which uses components/esp32/ld/esp32.common.ld and
doesn't track build/esp32/esp32.common.ld at all.
At this point, the linker runs in the build/esp32 directory and "-T esp32.common.ld" picks up the
linker script generated .ld file, which causes mis-builds.
As reported on forums: https://esp32.com/viewtopic.php?f=13&t=9684&p=40105
This fix prevents HTTP server from accepting new connections when the total count of connected
sockets has reached the max_open_sockets limit set during configuration. The pending connections
are kept in backlog until atleast one of the connected sockets is closed. The maximum number of
connection requests that can kept in backlog is specified as backlog_conn configuration option.
Note that this modification has no effect when LRU purge is enabled.
Also added sanity check on setting for max_open_sockets during configuration.
Solution suggested by jimparis https://github.com/espressif/esp-idf/issues/3183#issue-421234265
Closes https://github.com/espressif/esp-idf/issues/3183
Fix following STA WFA certification issues:
1. STA HT2040 coexist
2. Disallow WEP/TKIP with HT rates
3. WPA2 improvement
4. Minor refactor for WiFi internal global variable auth_type
List of changes:
* When parsing requests, count termination from LF characters only
* Correct memcpy() length parameter in httpd_unrecv() (pointed out by jimparis in GitHub issue thread)
* Use ssize_t to store results of length subtractions during parsing
* Modify some comments to reduce ambiguity
Closes https://github.com/espressif/esp-idf/issues/3182
Works around bug where components/soc/CMakeLists.txt was testing "EXISTS
${COMPONENT_PATH}/${SOC_NAME}" and this test could pass during early
expansion if COMPONENT_PATH was empty and a directory /esp32 exists
on Windows.
Closes https://github.com/espressif/esp-idf/issues/3195
V2 adds:
* Independent result for visibility (showing/hiding menus)
* Includes adding IDs for all items (menus & symbols) in kconfig_menus.json
Still backwards compatible with V1, with some small changes (menu items now listed in results).
Also added some protocol docs, changed the "listening on stdin" message to come after any kconfiglib warnings
newlib uses significantly more stack space when printing to an
unbuffered stream. To reduce the amount of stack space required to
use the console, don’t disable buffering. linenoise should support
unbuffered stdout instead.
Issue: MDNS server initially sends probing packets to resolve naming confilicts with already registered service instances. In case of a conflict, instance name is altered and probing restarts. Original instance however wasnnot removed from the structure and upon service removal only one entry was removed and a dangling service might have been kept in the structure to bring about a crash.
Resolution: Keep only one instance of a service in the probing structure.
Closes IDF-498
possible race condition: user task runs mdns_init, which enables pcbs while mdns-task already created could execute enable/disable of the same pcbs if an appropriate system event received
mnds_free() initiates stop and delete timer tasks, which after locking the mutex could lead to a dead lock in case timer task executed before deleting the task, as it would wait indefinitelly for unlocking the mutex. This condition is fixed by calling _mdns_stop_timer without locking the mutex, because there's no need to protect any data when stopping and deleting the timer task
Closes https://github.com/espressif/esp-idf/issues/1696
Issue: mdns_service_add API allocates and queues an action to be processed in mdns task context; when allocation or queueing fails, allocated structure needs to be freed. Function _mdns_free_service did not only fee all the structures, but also updates packet data.
Resolution: Moved removal of packet data outside of _mdns_free_service function.
packets scheduled to transmit are pushed to action queue and removed from tx_queue_head structure, which is searched for all remaining services and while service is removed, then service questions/asnwers are also removed from this structure. This update fixes possible crash when packet is pushed to action queue, and when service is removed, its answers are removed from tx_queue_head, but not from action queue. this could lead to a crash when the packet is poped from action queue containing questions/answers to already removed (freed) service
Closes IDF-504
When generating JSON metadata for ranges where there are conditional ranges (ie different allowed range
depending on another config setting), the JSON metadata would always have the last named range as
the expression was not evaluated properly.
Thanks to ulfalizer on GitHub for pointing this out.
Closes https://github.com/espressif/esp-idf/issues/2195
2019-03-13 16:48:57 +11:00
15845 changed files with 546689 additions and 2546357 deletions
description:Before submitting a new issue, please follow the checklist and try to find the answer.
options:
- label:I have read the documentation [ESP-IDF Programming Guide](https://docs.espressif.com/projects/esp-idf/en/latest/) and the issue is not addressed there.
required:true
- label:I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
required:true
- label:I have searched the issue tracker for a similar issue and not found a similar issue.
required:true
- type:input
id:idf_version
attributes:
label:IDF version.
description:Onwhich IDF version does this issue occur on? Run `git describe --tags` to find it.
placeholder:ex. v3.2-dev-1148-g96cd3b75c
validations:
required:true
- type:dropdown
id:operating_system
attributes:
label:Operating System used.
multiple:false
options:
- Windows
- Linux
- macOS
validations:
required:true
- type:dropdown
id:build
attributes:
label:How did you build your project?
multiple:false
options:
- Command line with Make
- Command line with CMake
- Command line with idf.py
- Eclipse IDE
- CLion IDE
- VS Code IDE
- Other (please specify in More Information)
validations:
required:true
- type:dropdown
id:windows_comand_line
attributes:
label:If you are using Windows, please specify command line type.
multiple:false
options:
- PowerShell
- CMD
validations:
required:false
- type:textarea
id:expected
attributes:
label:What is the expected behavior?
description:Please provide a clear and concise description of the expected behavior.
placeholder:I expected it to...
validations:
required:true
- type:textarea
id:actual
attributes:
label:What is the actual behavior?
description:Please describe actual behavior.
placeholder:Instead it...
validations:
required:true
- type:textarea
id:steps
attributes:
label:Steps to reproduce.
description:'How do you trigger this bug? Please walk us through it step by step. If this is build bug, please attach sdkconfig file (from your project folder). Please attach your code here.'
value:|
1. Step
2. Step
3. Step
...
validations:
required:true
- type:textarea
id:debug_logs
attributes:
label:Build or installation Logs.
description:Build or installation log goes here, should contain the backtrace, as well as the reset source if it is a crash.
placeholder:Your log goes here.
render:plain
validations:
required:false
- type:textarea
id:more-info
attributes:
label:More Information.
description:Do you have any other information from investigating this?
placeholder:ex. I tried on my friend's Windows 10 PC and the command works there.
description:Before submitting a new issue, please follow the checklist and try to find the answer.
options:
- label:I have read the documentation [ESP-IDF Programming Guide](https://docs.espressif.com/projects/esp-idf/en/latest/) and the issue is not addressed there.
required:true
- label:I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
required:true
- label:I have searched the issue tracker for a similar issue and not found a similar issue.
required:true
- type:input
id:idf_version
attributes:
label:IDF version.
description:Onwhich IDF version does this issue occur on? Run `git describe --tags` to find it.
placeholder:ex. v3.2-dev-1148-g96cd3b75c
validations:
required:true
- type:input
id:chip_revision
attributes:
label:Espressif SoC revision.
description:Onwhich Espressif SoC revision does your application run on? Run `esptool chip_id` to find it.
placeholder:ex. ESP32-C3 (QFN32) (revision v0.3)
validations:
required:true
- type:dropdown
id:operating_system
attributes:
label:Operating System used.
multiple:false
options:
- Windows
- Linux
- macOS
validations:
required:true
- type:dropdown
id:build
attributes:
label:How did you build your project?
multiple:false
options:
- Command line with Make
- Command line with CMake
- Command line with idf.py
- Eclipse IDE
- CLion IDE
- VS Code IDE
- Other (please specify in More Information)
validations:
required:true
- type:dropdown
id:windows_comand_line
attributes:
label:If you are using Windows, please specify command line type.
multiple:false
options:
- PowerShell
- CMD
validations:
required:false
- type:input
id:devkit
attributes:
label:Development Kit.
description:Onwhich Development Kit does this issue occur on?
* We welcome any ideas or feature requests! It’s helpful if you can explain exactly why the feature would be useful.
* There are usually some outstanding feature requests in the [existing issues list](https://github.com/espressif/esp-idf/labels/Type%3A%20Feature%20Request), feel free to add comments to them.
* If you would like to contribute, please read the [contributions guide](https://docs.espressif.com/projects/esp-idf/en/stable/esp32/contribute/index.html).
- type:textarea
id:problem-related
attributes:
label:Is your feature request related to a problem?
description:Please provide a clear and concise description of what the problem is.
placeholder:ex. I'm always frustrated when ...
- type:textarea
id:solution
attributes:
label:Describe the solution you'd like.
description:Please provide a clear and concise description of what you want to happen.
placeholder:ex. When connecting to an Espressif chip ...
- type:textarea
id:alternatives
attributes:
label:Describe alternatives you've considered.
description:Please provide a clear and concise description of any alternative solutions or features you've considered.
placeholder:ex. Choosing other approach wouldn't work, because ...
- type:textarea
id:context
attributes:
label:Additional context.
description:Please add any other context or screenshots about the feature request here.
description:Before submitting a new issue, please follow the checklist and try to find the answer.
options:
- label:I have read the documentation [ESP-IDF Programming Guide](https://docs.espressif.com/projects/esp-idf/en/latest/) and the issue is not addressed there.
required:true
- label:I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
required:true
- label:I have searched the issue tracker for a similar issue and not found a similar issue.
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.`
_All texts in italics are instructional and should be replaced by contents or removed._
## Checklist
_This entire section can be deleted if all items are checked._
* [ ] Enough information to help reviewers understand the issue, its root cause, impact, and the proposed solution
* [ ] Enough information to help reviewers understand the feature, its functional description, example, documentation, test cases, test results, feature TODO list
* [ ] The MR Title describes the change, including the component name, ie "lwip: Add support for IP over Pigeon"
* [ ] All related links, including JIRA, backport, submodule MR, are mentioned in the `Related` subsection.
* [ ] Any GitHub issues are linked inside the git commit message and corresponding release notes
* [ ] Add label for the area this MR is part of
* [ ] For documentation updates, check if label `Docs` and `needs translation:CN` or `needs translation:EN` have been added when the other language version still needs the update. Skip adding the label if the document is not yet translated.
* [ ] Check if documents requiring translation fall under get-started section. If yes, add the labels mentioned above. Then the documentation team will assign a translator for you. Please inform the translator to prepare translation once your MR is ready to merge. The translation should be included in your MR to get it merged. For more information, see documentation workflow in Wiki.
* [ ] Any necessary "needs backport" labels are added
* [ ] Check if this is a breaking change. If it is, add notes to the `Breaking change notes` subsection below
* [ ] Release note entry if this is a new public feature, or a fix for an issue introduced in the previous release.
* [ ] The commit log is clean and ready to merge.
* [ ] All relevant CI jobs have been run, i.e. jobs which cover the code changed by the MR.
---
_For issues, put enough information here to help reviewers understand the issue, its root cause, impact, and the proposed solution._
_If this issue is a regression, specify in the `Related` subsection below, in which commit or MR it was introduced. This helps reviewers to check if the backport labels are set correctly._
---
_For features, put enough information here to help reviewers understand the feature, its functional description, example, documentation, test cases, test results, feature TODO list._
---
_For other small/non-public changes, which are not expected to be in the release notes, can be mentioned here, include:_
* changes that don't apply to customers, e.g. some CI fixes, test only MR and etc
## Related
* Mention or related JIRA tasks (e.g. IDF-0000), to make sure they get updated.
* Mention submodule MR, if there is
* Mention backport(ed) MR, if there is
_Don't touch the subsection titles below, they will be parsed by scripts._
## Release notes (Mandatory)
_Changes made in this MR that should go into the **Release Notes** should be listed here. Please use **past tense** and *specify the area (see maintainers page of IDF internal wiki)*. If there is a subscope, include it and separate with slash (`/`). Minor changes can go to the descriptions above without a release notes entry._
_Write all the changes in a **list** (Start at the beginning of the line with `-` or `*`). If multiple changes are made, each of them should take a single line. If there is only one change to list, it should still be the only line of a list. If this MR does not need any release notes, write "No release notes" here without the `-` or `*`. e.g._
_If there are any breaking changes, please mention it here. Talking about (1) what is not accepted any more, (2) the alternative solution and (3) the benefits/reason. e.g._
_Please strictly follow the breaking change restriction, which means, if there is a breaking change but you are merging to non-major versions, you have to separate the breaking part out to another MR for a major version. The breaking change subsection is only accepted in MRs merging to major versions._
* [VFS/UART] Now vfs_uart_set_rts_cts accept one more instance argument, to support configuration to different ports.
# 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/articles/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>`?
* 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 <http://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 official development framework for the [ESP32](https://espressif.com/en/products/hardware/esp32/overview) chip.
# Developing With ESP-IDF
## Setting Up ESP-IDF
See https://idf.espressif.com/ for links to detailed instructions on how to set up the ESP-IDF depending on chip you use.
See setup guides for detailed instructions to set up the ESP-IDF:
**Note:** Each SoC series and each ESP-IDF release has its own documentation. Please see Section [Versions](https://docs.espressif.com/projects/esp-idf/en/latest/esp32/versions.html) on how to find documentation and how to checkout specific release of ESP-IDF.
* [Getting Started Guide for the stable ESP-IDF version](https://docs.espressif.com/projects/esp-idf/en/stable/get-started/)
* [Getting Started Guide for the latest (master branch) ESP-IDF version](https://docs.espressif.com/projects/esp-idf/en/latest/get-started/)
### 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
@@ -59,72 +31,101 @@ To start your own project based on an example, copy the example project director
See the Getting Started guide links above for a detailed setup guide. This is a quick reference for common commands when working with ESP-IDF projects:
## Setup Build Environment
(See the Getting Started guide listed above for a full list of required steps with more details.)
* Install host build dependencies mentioned in the Getting Started guide.
* Run the install script to set up the build environment. The options include `install.bat` or `install.ps1` for Windows, and `install.sh` or `install.fish` for Unix shells.
* Run the export script on Windows (`export.bat`) or source it on Unix (`source export.sh`) in every shell environment before using ESP-IDF.
## Configuring the Project
*`idf.py set-target <chip_name>` sets the target of the project to `<chip_name>`. Run `idf.py set-target` without any arguments to see a list of supported targets.
*`idf.py menuconfig` opens a text-based configuration menu where you can configure the project.
`make menuconfig`
* Opens a text-based configuration menu for the project.
* Use up & down arrow keys to navigate the menu.
* Use Enter key to go into a submenu, Escape key to go out or to exit.
* Type `?` to see a help screen. Enter key exits the help screen.
* Use Space key, or `Y` and `N` keys to enable (Yes) and disable (No) configuration items with checkboxes "`[*]`"
* Pressing `?` while highlighting a configuration item displays help about that item.
* Type `/` to search the configuration items.
Once done configuring, press Escape multiple times to exit and say "Yes" to save the new configuration when prompted.
## Compiling the Project
`idf.py build`
`make -j4 all`
... will compile app, bootloader and generate a partition table based on the config.
NOTE: The `-j4` option causes `make` to run 4 parallel jobs. This is much faster than the default single job. The recommended number to pass to this option is `-j(number of CPUs + 1)`.
## Flashing the Project
When the build finishes, it will print a command line to use esptool.py to flash the chip. However you can also do this automatically by running:
`idf.py -p PORT flash`
`make -j4 flash`
Replace PORT with the name of your serial port (like `COM3` on Windows, `/dev/ttyUSB0` on Linux, or `/dev/cu.usbserial-X` on MacOS. If the `-p` option is left out, `idf.py flash` will try to flash the first available serial port.
This will flash the entire project (app, bootloader and partition table) to a new chip. The settings for serial port flashing can be configured with `make menuconfig`.
This will flash the entire project (app, bootloader and partition table) to a new chip. The settings for serial port flashing can be configured with `idf.py menuconfig`.
You don't need to run `idf.py build` before running `idf.py flash`, `idf.py flash` will automatically rebuild anything which needs it.
You don't need to run `make all` before running `make flash`, `make flash` will automatically rebuild anything which needs it.
## 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 `make 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 the ESP32. 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-].
To build, flash and monitor output in one pass, you can run:
`idf.py flash monitor`
`make -j4 flash monitor`
## Compiling & Flashing Only the App
After the initial flash, you may just want to build and flash just your app, not the bootloader and partition table:
*`idf.py app` - build just the app.
*`idf.py app-flash` - flash just the app.
*`make app` - build just the app.
*`make app-flash` - flash just the app.
`idf.py app-flash` will automatically rebuild the app if any source files have changed.
`make app-flash` will automatically rebuild the app if any source files have changed.
(In normal development there's no downside to reflashing the bootloader and partition table each time, if they haven't changed.)
## Parallel Builds
ESP-IDF supports compiling multiple files in parallel, so all of the above commands can be run as `make -jN` where `N` is the number of parallel make processes to run (generally N should be equal to the number of CPU cores in your system, plus one.)
Multiple make functions can be combined into one. For example: to build the app & bootloader using 5 jobs in parallel, then flash everything, and then display serial output from the ESP32 run:
```
make -j5 flash monitor
```
## The Partition Table
Once you've compiled your project, the "build" directory will contain a binary file with a name like "my_app.bin". This is an ESP32 image binary that can be loaded by the bootloader.
A single ESP32's flash can contain multiple apps, as well as many different kinds of data (calibration data, filesystems, parameter storage, etc). For this reason a partition table is flashed to offset 0x8000 in the flash.
Each entry in the partition table has a name (label), type (app, data, or something else), subtype and the offset in flash where the partition is loaded.
The simplest way to use the partition table is to `make menuconfig` and choose one of the simple predefined partition tables:
* "Single factory app, no OTA"
* "Factory app, two OTA definitions"
In both cases the factory app is flashed at offset 0x10000. If you `make partition_table` then it will print a summary of the partition table.
For more details about partition tables and how to create custom variations, view the [`docs/en/api-guides/partition-tables.rst`](docs/en/api-guides/partition-tables.rst) file.
## 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 `make 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 `make 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 `make 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).
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.
@@ -3,56 +3,64 @@ The latest support policy for ESP-IDF can be found at [https://github.com/espres
Support Period Policy
=====================
* [中文版](./SUPPORT_POLICY_CN.md)
Each ESP-IDF major and minor release (V4.0, V4.1, etc) is supported for
18 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.
Users are encouraged to upgrade 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.
Support period is divided into "Service" and "Maintenance" 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.
| Period | Duration | Recommended for new projects? |
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).
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.)
Long Term Support releases
--------------------------
During the Maintenance period, the version is still supported but only bugfixes for high severity issues or security issues will be applied.
Some releases (starting with ESP-IDF V3.3) are designated Long Term
Support (LTS). LTS releases are supported for 30 months (2.5 years)
after the initial stable release date.
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.
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).
A new LTS release will be made at least every 18 months. This means
there will always be a period of at least 12 months to upgrade from the
previous LTS release to the following LTS release.
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 and is a Long Term Support
(LTS) release, meaning 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 V3.3 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 support period policy was announced,
the following 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.
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.
- ESP-IDF V3.1.x and V3.2.x will both be supported until October 2020.
- ESP-IDF V3.0.9 (planned for October 2019) will be the last V3.0
bugfix release. ESP-IDF V3.0.x is End of Life from October 2019.
- ESP-IDF versions before V3.0 are already End of Life.
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.
