1. send null data when state change from association to run
2. fix sta auth failed but softAP shows it connected issue
3. mesh: layer2 node will scan all channels when root leave in fixed root network
Inadequate locking in the esp_timer component allowed corruption
of the s_timers linked list:
1. timer_armed(timer) returns false
2. another task arms the timer and adds it to s_timers
3. the list is locked
4. the timer is inserted into s_timers again
The last step results in a loop in the s_timers list, which causes
an infinite loop when iterated. This change always locks the
list before checking if the timer is already armed avoiding
the data race.
bt: Fixed the inconsistency between the indicator event received by the HF application layer and the actually received indicator(v4.2)
See merge request espressif/esp-idf!23564
1. Fixed crash after controller disable and re-enable
2. Fixed the crash caused by processing the HCI_Read_Remote_Extented_Features command in the non-connected state
3. Fixed disconnection due to not handling lmp_unsniff_req in LC_WAIT_SNIFF_SUB_RSP state
4. Fixed crash caused by supervision timeout greater than sniff interval
Closes https://github.com/espressif/esp-idf/issues/11164
Closes https://github.com/espressif/esp-idf/issues/10835
Fixed vulnerability attacks that could cause heap overflow in fragmented Blufi packet processing (back port v4.2)
See merge request espressif/esp-idf!23063
The remaining 4 kB had been reserved for storing RF calibration and
BT stack state since 4e092be6. However, these features never got
implemented. If we ever need to place RF related data into RTC slow
memory, we can do this by creating a variable with RTC_NOINIT_ATTR
instead.
https://github.com/espressif/esp-idf/issues/6515
This commit adds a workaround for the TWAI listen only mode errata which is
present on the ESP32, ESP32-S2, ESP32-S3, and ESP32-C3. twai_get_status_info()
has also been updated to account for the fact that TEC/REC are frozen in
listen only mode.
Errata Description:
When the TWAI controller is put into listen only mode, it should not influence
the TWAI bus in any way (i.e., should never send a dominant bit). However,
on the targets listed above, the TWAI controller will send dominant bits in an
error frame (i.e., active error frame), even if the controller is set to listen
only mode.
Workaround:
We can force the TWAI controller into the error passive state on startup (by
setting the REC to >= 128). Since the TEC/REC are frozen in listen only mode,
the TWAI controller will remain error passive and only send recessive bits
(i.e., passive error frames), thus will not influence the TWAI bus.
Closes https://github.com/espressif/esp-idf/issues/9157
1. fix softap beacon memory leak issue.
2. fix esp wifi sta get ap info does not return connected ssid issue.
3. update inactive timer when recv ps-poll or success send data.
- Add config to set duplicate scan list refresh period
- overwrite the oldest device infor if the list is full
- Fixed duplicate scan period is not accurate
- Change default TX power to 9 dBm
- Fixed disconnect reason 0x1f (unspecified error)
- Fixed connection timeout due to terminate ind has not been acknowledged
- Fixed some memory was not released after bluetooth controller initialization failed on ESP32
bluetooth: use non-blocking coexistence callback functions so that Wi-Fi task is not blocked by Bluetooth(backport v4.2)
See merge request espressif/esp-idf!20811
1. fix sta reset beacon timeout timer issue
2. fix pairwise cipher tkip pmf compability issue
3. fix country policy issue
4. fix deinit return wrong status issue
5. fix get wrong channel value use esp_wifi_get_config
6. fix bug of missing unlock when wifi stop
7. fix error of esp_wifi_start_scan in api esp_wifi_connect
8. fix fail to scan after recv disassoc/deauth for esp32s2
bt:No need to use local copy of btc_msg_t in btc_transfer_context, create it on heap and pass to osi_thread_post()(v4.2)
See merge request espressif/esp-idf!19694
Fixed calling esp_ble_get_cur_sendable_packets_num() sometimes crashes when bluetooth is disconnecting(backport v4.2)
See merge request espressif/esp-idf!20379
In previous transmission(s), the TX_DONE interrupt raw bit may be raised, but never been cleared.
TX_DONE interrrupt status bit should be cleared before enabling it to check the new transmission.
Introduced in 239e56541c
update gpio_sig at `spics_out` array in each spi_periph.c of chips later than s2
then `spi_bus_add_device` can correctly distribute gpio_signals for cs_signal
Closes https://github.com/espressif/esp-idf/issues/8876
define: lock_bits = (lock->status & LOCK_MASK) >> LOCK_SHIFT; This `lock_bits` is the Bit 29-20 of the lock->status
1. spi_hdl_1:
acquire_end_core():
uint32_t status = lock_status_clear(lock, dev_handle->mask & LOCK_MASK);
Becuase this is the first `spi_hdl_1`, so after this , lock_bits == 0`b0. status == 0
2. spi_hdl_2:
acquire_core:
uint32_t status = lock_status_fetch_set(lock, dev_handle->mask & LOCK_MASK);
Then here status is 0`b0, but lock_bits == 0`b10. Because this is the `spi_hdl_2`
3. spi_hdl_2:
`acquire_core` return true, because status == 0. `spi_bus_lock_acquire_start(spi_hdl_2)` then won't block.
4. spi_hdl_2:
spi_device_polling_end(spi_hdl_2).
5. spi_hdl_1:
acquire_end_core:
status is 0, so it cleas the lock->acquiring_dev
6. spi_hdl_2:
spi_device_polling_end:
assert(handle == get_acquiring_dev(host)); Fail
Closes https://github.com/espressif/esp-idf/issues/8179
Adding prop and lit sections to the ELF will let the debugger and the disassembler
have more info about data bytes present in the middle of the Xtensa
instructions, usually used for padding.
Due to the lack of synchronized connections, the hf_client can not create audio_connection to
hf_ag. Set default number of synchronized connection to 1.
Closes https://github.com/espressif/esp-idf/issues/9537
1. fix not update phy according to country code.
2. sync peripheral device reg base.
3. fix for default ap ssid not set.
4. do not recv unencrypted unicaset ESPNOW packets when local encrypted.
- Bugfix for close sniffer mode when wifi stop
- Bugfix for qos null update ba ssn
- Bugfix for wrong configuration of static txbuf
- Fix deep sleep can't reconnect to ap when pmf enable.
- Fix some ap will ignore auth when rx deauth for a while.
- update wifi header file
As heap block may be allocated into multiple non-continuous chunks, to
reserve enough memory for dma/internal usage, we do the malloc in the
step of max available block.
The "FreeRTOS Event Groups" main task will only wait a single tick for the created
tasks to set their response bits. This short delay may not be sufficent if the tick
frequency is high.
This commit updates the test so that
- the main task waits indefinitely for all the response bits to be set.
- created tasks are cleaned up by the main task
FreeRTOS synchronization primitives (e.g., queues, eventgroups) use various event lists (i.e., task lists) to track what
tasks are blocked on a current primitive. Usually these event lists are accessed via one of the event lists functions
(such as vTask[PlaceOn|RemoveFrom]UnorderedEventList()), which in turn ensure that the global task list spinlock
(xTaskQueueMutex) is taken when accessing these lists.
However, some functions in event_groups.c manually traverse their event lists. Thus if a tick interrupt occurs on
another core during traversal and that tick interrupt unblocks a task on the event list being traversed, the event list
will be corrupted.
This commit modifies the following event_groups.c functions so that they take the global task list lock before
traversing their event list.
- xEventGroupSetBits()
- vEventGroupDelete()
The Xtensa FreeRTOS port does not save the threadptr register when
doing a voluntary yield. This can result in a crash when multiple
tasks used the threadptr register and call "taskYIELD()".
This commit adds the threadptr register to the solicited stack frame.
This function is necessary to provide the emergency exception
memory pool size for C++ code.
Since our libstdc++ always has exceptions enabled, this function
must exist here even if -fno-exception is set for user code.
1. The 2nd bootloader always call `rom_spiflash_unlock()`, but never help to clear the WEL bit when exit. This may cause system unstability.
This commit helps to clear WEL when flash configuration is done.
**RISK:** When the app starts, it didn't have to clear the WEL before it actually write/erase. But now the very first write/erase operation should be done after a WEL clear. Though the risk is little (all the following write/erase also need to clear the WEL), we still have to test this carefully, especially for those functions used by the OTA.
2. The `rom_spiflash_unlock()` function in the patch of ESP32 may (1) trigger the QPI, (2) clear the QE or (3) fail to unlock the ISSI chips.
Status register bitmap of ISSI chip and GD chip:
| SR | ISSI | GD25LQ32C |
| -- | ---- | --------- |
| 0 | WIP | WIP |
| 1 | WEL | WEL |
| 2 | BP0 | BP0 |
| 3 | BP1 | BP1 |
| 4 | BP2 | BP2 |
| 5 | BP3 | BP3 |
| 6 | QE | BP4 |
| 7 | SRWD | SRP0 |
| 8 | | SRP1 |
| 9 | | QE |
| 10 | | SUS2 |
| 11 | | LB1 |
| 12 | | LB2 |
| 13 | | LB3 |
| 14 | | CMP |
| 15 | | SUS1 |
QE bit of other chips are at the bit 9 of the status register (i.e. bit 1 of SR2), which should be read by RDSR2 command.
However, the RDSR2 (35H, Read Status 2) command for chip of other vendors happens to be the QIOEN (Enter QPI mode) command of ISSI chips. When the `rom_spiflash_unlock()` function trys to read SR2, it may trigger the QPI of ISSI chips.
Moreover, when `rom_spiflash_unlock()` try to clear the BP4 bit in the status register, QE (bit 6) of ISSI chip may be cleared by accident. Or if the ISSI chip doesn't accept WRSR command with argument of two bytes (since it only have status register of one byte), it may fail to clear the other protect bits (BP0~BP3) as expected.
This commit makes the `rom_spiflash_unlock()` check whether the vendor is issi. if so, `rom_spiflash_unlock()` only send RDSR to read the status register, send WRSR with only 1 byte argument, and also avoid clearing the QE bit (bit 6).
3. `rom_spiflash_unlock()` always send WRSR command to clear protection bits even when there is no protection bit active. And the execution of clearing status registers, which takes about 700us, will also happen even when there's no bits cleared.
This commit skips the clearing of status register if there is no protection bits active.
Also move the execute_flash_command to be a bootloader API; move
implementation of spi_flash_wrap_set to the bootloader
Replaces the previously used Docker Hub autobuild infrastructure.
This allows for more flexible configuration of the build process,
at the expense of some extra maintenance of CI workflow files
required.
These two arguments can be used to reduce the size of the Docker
image:
- Setting IDF_CLONE_SHALLOW enables shallow cloning.
- Setting IDF_INSTALL_TARGETS to the comma separated list of targets
results in toolchains being installed only for these targets.
Since ulp wakeup signal are connected to ulp int raw(except esp32), we
need to clear ulp int raw before sleep when ulp wakeup enabled. Otherwise,
if the ulp int raw is already set, chip will not sleep properly.
Closes https://github.com/espressif/esp-idf/issues/6229
TWAI: Add FIFO overrun handling and ESP32 hardware errata workarounds + Refactor TWAI HAL to store state information (backport v4.2)
See merge request espressif/esp-idf!17106
Prior to this change "esp_wifi_clear_default_wifi_driver_and_handlers"
will not remove netif pointer from table when both AP and STA interfaces were
created and destroying default wifi interfaces is done in unfortunate
order. As a result there is dangling pointer left and it may cause crash in
later code (i.e. when esp_wifi_stop() is called).
While using esp_wifi_set_config, flag pmf_capable defaults to 0.
Users may not bother to enable it, which prevents connection to a
WPA3 AP. Or the AP may reset into WPA3 mode failing the re-connection.
To ensure better security, deprecate the pmf_capable flag and set it to
true internally.
Additionally add API esp_wifi_disable_pmf_config to disable PMF for
debug purposes or to avoid PMF issues on AP side.
ESP32 in revision0 and revision1 uses touchpad to provide
current to oscillate xtal 32k. But revision2 and revision3
do not need to do that.
Note: touchpad can not work and toupad/ULP wakeup sources
are not available when toupad provides current to xtal 32k
Avoid adding one extra fade cycle when performing a one-time duty update.
Add some notes to ledc_get_duty and ledc_update_duty APIs, so that users
are aware of when the new duty will be effective.
Closes https://github.com/espressif/esp-idf/issues/7288
(cherry picked from commit e175086226)
- Simplify PHY access API
- Move coexist initializing and deinitializing out from PHY API
to Wi-Fi and Bluetooth
- Remove coexist pause and resume for they are no longer needed.
Add following bugfixes
1. Station not able to connect when WPS pin is pressed first on AP.
2. PBC overlap getting detected for selected registrar PIN APs.
3. Station not considering authorised MACs for PIN method.
4. For PIN methodm If no AP is found, station will loop through
APs in its vicinity and try to do WPS with them one by one till
WPS timeout occurs. This is for some APs which do not set
selected registrar correctly.
1. fix the issue that no tbtt is generated in station+softap mode when maximum modem sleep is enabled
2. store PHY digital registers before disabling PHY and load them after enabling PHY
3. update libphy.a to V4670 719f9f6_20210218 for esp32
4. update libphy.a to V1500 20210225_0a54a2f for esp32s2
esp_wifi_mesh: fix the issue that layer2 node connect to lower-layer node when FIXED-ROOT root disappeared(backport_v4.2)
See merge request espressif/esp-idf!15730
gpio: Bugfix - Move esp_intr_free() out of the critical section in gpio_uninstall_isr_service() (backport v4.2)
See merge request espressif/esp-idf!16597
Closes https://github.com/espressif/esp-idf/issues/5571
Fix the bug that if the API was called from one core to free the interrupt source on the other core, it would trigger interrupt watchdog.
(cherry picked from commit 0e8286c57b)
Current issue: output reports sent by Windows not received.
The report characteristic declaration should also support write without
response as specified by HIDS profile:
See https://www.bluetooth.com/specifications/GATT/ (page 14)
ringbuf: Fix bug where comparision between a signed and unsigned operand resulted in incorrect free size for no-split/allow-split buffers (v4.2)
See merge request espressif/esp-idf!15883
Initial version of freemodbus master port files have been added to ESP-IDF based on https://github.com/armink/FreeModbus_Slave-Master-RTT-STM32.
The overall repository license, at the time of adding these files, has been BSD 3-clause. However at that time, several port files carried LGPL license headers. As the author of these files confirmed in https://github.com/armink/FreeModbus_Slave-Master-RTT-STM32/issues/61#issuecomment-977828450, this wasn't intentional. ESP-IDF version of modbus master port has been rewritten to target FreeRTOS instead of RT-Thread, but the license headers remained from the original version. This commit corrects this, replacing the license of these files with BSD 3-clause.
This commit fixes a bug in no-split and allow-split ring buffers free buffer size calculation.
When the free size available in the buffers less than the size of one item header,
the function prvGetCurMaxSizeNoSplit/AllowSplit() incorrectly returned the maxItemSize instead of 0.
This is due to the comparision between a negative and a positive value
where both operands are treated as unsigned during the comparision operation,
thereby treating the negative operand as a large integer.
Also added new unit tests to test buffer-full and almost-full conditions
where this scenario is likely to be hit.
Closes https://github.com/espressif/esp-idf/issues/7344
Closes https://github.com/espressif/esp-idf/pull/7371
The release of the semaphore indicating the item was successfully sent must be the last semaphore released. The receiver may be in another task and may delete the Ringbuffer (such as with a return code across tasks design pattern) if they are through with the Ringbuffer.
The function xRingbufferSendAcquire followed by xRingbufferSendComplete had the semaphores released in the proper order and that same pattern should have been used in xRingbufferSend and xRingbufferSendFromISR. This commit fixes this order.
Issue (IDFGH-6030) #7716 describes the problem in more detail.
Closes IDFGH-6030, https://github.com/espressif/esp-idf/issues/7716
Closes IDFGH-6036, https://github.com/espressif/esp-idf/pull/7721
1. fix the device can not receive IP_EVENT_STA_GOT_IP when the router restarted
2. fix the issue that layer2 node connect to lower-layer node when FIXED-ROOT root disappeared
This commit brings two esp-lwip fixes to IDF:
1) Add configuration to disable DHCP client identification
2195f7416f
This config could be used to disable option 61 in DHCP packets, so that
clients will be identified by their chaddr only.
(This is the lwip upstream original behaviour)
2) Fix server_idx increasing to DNS_MAX_SERVERS and trigger the LWIP_ASSERT
5a567d52f7
When lwip doesn't have DNS server and resolve a domain address, the server_idx
will increase to DNS_MAX_SERVERS, which will trigger the LWIP_ASSERT and make device crash.
Closes https://github.com/espressif/esp-idf/issues/7912
1. fix(pp): fix fragment plt loss when 2td pn compare with 1th pn
2. pmf allow keyindex in big endian format to workaround faulty APs
3. docs: update miswritten and abbreviated words and syntax errors for initialize WiFi section in esp_wifi.h header file
4. allow for minimal scope of wifi_init_config_t
1. Added config options to chose from protocom security.
It can be chosen 0/1 or custom.
Possible to set POP as well
2. Added support in `esp_local_ctrl.py` test script for sec_ver selection
Signed-off-by: Vikram Dattu <vikram.dattu@espressif.com>
1. Fix airkiss and esptouch find channel crash issue
2. Fix RF singal test without 9M rate issue
3. Fix issue of setting invalid size to nvs misc log even after erasing it
4. Fix WEP connection and crash issue
Current code does not correctly free all pins in wps_free_pins due to the
semicolon at the end of dl_list_for_each_safe(). Fix it.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
The body of the bootloader_debug_buffer function was conditioned to
macros that were never defined, resulting in deactivated code.
Signed-off-by: Gustavo Henrique Nihei <gustavo.nihei@espressif.com>
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.
For the CID10564,10384,10280,10098,10038,The memory was released in other place.
For the CID10365,it release the memory in the function when sent successfully.
For the CID10268,10011, we need not change the code.
Increase reset assertion time from 100µs (as specified minimum in the datasheet) to 150µs.
Some specimen of the LAN8720 need the reset signal asserted longer than 100µs to initialise properly. Otherwise they are in a zombie state where they are establishing and loosing an Ethernet link once in a seconds interval.
The psram cache bug fix was also being applied to the bootloader binary (for cmake),
which doesnt do any psram access.
Applying this fix would increase the binary size, as much as 300 bytes in worst case scenarios
The issue is related to the non-sequential way of description when
such fields going together sequential.
Related to esp32h2 chip for eFuses: MAC_FACTORY and MAC_EXT.
The issue is in wrong indexes of MAC_EXT.
MAC_EXT got indexes like it is joined to MAC_FACTORY.
const esp_efuse_desc_t* ESP_EFUSE_MAC_FACTORY[] = {
&MAC_FACTORY[0],
&MAC_FACTORY[1],
&MAC_FACTORY[2],
&MAC_FACTORY[3],
&MAC_FACTORY[4],
&MAC_FACTORY[5],
NULL
};
const esp_efuse_desc_t* ESP_EFUSE_MAC_EXT[] = {
&MAC_EXT[6],
&MAC_EXT[7],
NULL
};
This commit fixed it to:
const esp_efuse_desc_t* ESP_EFUSE_MAC_EXT[] = {
&MAC_EXT[0],
&MAC_EXT[1],
NULL
};
esp_http_client: Fix HEAD request will affect the all next HTTP requests unless we close the HTTP request(backport v4.2)
See merge request espressif/esp-idf!15713
Large SD cards (16GB+) require significant amount of time for FS formatting.
Added FS mount checkpoint in example test python, timeout set to 60 sec
Closes IDFCI-706
It was when in the partition table there is a partition with type="data" and suptype=""(empty),
in this case type=1, suptype=0. It is similar to otadata partition.
This commit fixes it, now it will handle it as type=1, suptype=6 (ESP_PARTITION_SUBTYPE_DATA_UNDEFINED).
For https connection `ESP_TLS_ERR_SSL_WANT_READ` of esp_transport_read was getting treated as error.
Treated this as a timeout to fix connection abort issue!
Also handled http connection EAGAIN with `errno == EAGAIN` check.
Signed-off-by: Vikram Dattu <vikram.dattu@espressif.com>
Allow user to select specific ESP_TARGET while setting up ESD_IDF.
Only necessary tools for given target will be downloaded and installed.
Closes https://github.com/espressif/esp-idf/issues/5113
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.
Issue:
Missing newline between header and attachment
Issue seen with email clients viz., AppleMail and YahooMail. Attachment is not renderable.
Some clients like Google mail, Samsung mail tolerate the issue.
Fix:
Added newline between header and attachment.
Closes https://github.com/espressif/esp-idf/issues/6098
Signed-off-by: Vikram Dattu <vikram.dattu@espressif.com>
WPS strict disables workarounds with different APs and may cause
IOT issues. Remove this as default and introduce as a config option.
Also declare esp device as single band mobile device otherwise
WFA sniffer was not able to identify it in the certification setup.
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.
* Patched longjmp to be context-switch safe
longjmp modifies the windowbase and windowstart
registers, which isn't safe if a context switch
occurs during the modification. After a context
switch, windowstart and windowbase will be
different, leading to a wrongly set windowstart
bit due to longjmp writing it based on the
windowbase before the context switch. This
corrupts the registers at the next window
overflow reaching that wrongly set bit.
The solution is to disable interrupts during
this code. It is only 6 instructions long,
the impact shouldn't be significant.
The fix is implemented as a wrapper which
replaces the original first instructions of
longjmp which are buggy. Then, it jumps back
to execute the rest of the original longjmp
function.
Added a comparably reliable test to the
test apps.
* 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
1. Fixed the crash when using scan parameter: window = 4 slots, interval = 5 slots
2. Fixed BLE ACL tx flush issue during reset
3. Added remove sniff when peer not accepted sniff mode
- Add `wifi_prov_scheme_ble_set_mfg_data` API to set custom manufacturer data
in BLE advertisements.
- Run format.sh script on modified files.
- Fix few typos in `protocomm_nimble.c`.
- Incorporate suggestion to remove extra check on protocomm_ble_mfg_data_len
- Remove few unnecessary comments.
This is mostly important on ESP32 ECO3 with the
ESP32_ECO3_CACHE_LOCK_FIX, because when we stall the other CPU core
before we disable the TG1 WDT then the first CPU can get stuck
in WDT ISR handle_livelock_int routine waiting for the other CPU.
After we have the performance dashboard, we have more data and no longer depend on the threshold to ensure performance.
Set looser performance thresholds to avoid CI failure.
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
This makes the test faster and more robust in very a busy WiFi environment
(our CI) and still exercises the scenario of fragmenting the message on
both mqtt and ssl levels (binary size to send > mqtt buffer size)
This commit fixes an issue with gdbstub, where it would list threads
with TIDs 1 to N in qfThreadInfo/qsThreadInfo responses, and then
would tell GDB that the current TID is 0 in the qC response. This
caused an assertion failure in GDB, because it couldn't find the
thread structure corresponding to TID 0:
src/gdb/gdb/thread.c:93: internal-error: thread_info* inferior_thread(): Assertion `tp' failed.
The issue was caused by the logic of qfThreadInfo/qsThreadInfo.
If the "paniced" task index was 1, the code would report it in the
response to qfThreadInfo, and then mistakenly skip task with index 0
in qsThreadInfo, due to the use of pre-increment instead of a
post-increment.
With that issue fixed, GDB assertion doesn't happen anymore. However
the code contained a deeper problem, which manifested itself in the
fact that GDB would incorrectly show task index 0 as the current task,
after the above fix.
Previous version of the code assumed that when GDB requests the thread
list, it uses the first thread returned by the target as the "default"
thread, and subsequently shows the user that the program is stopped
in that thread. This assumption was incorrect. In fact, after
connecting to a remote target, GDB obtains information about the
"default" or "current" thread from two sources:
1. the 'thread' special register indicated in the status response
($T00thread;00000001#ee)
2. if the target has only sent the plain stop response ($T00#ee), GDB
would ask for the current thread using a qC packet.
With that in mind, it is not necessary to report the paniced task as
the first task in qfThreadInfo response. We can simply returns the
tasks in their natural order, and then indicate the current task in
the qS packet response.
However even that change does not fully resolve the issues with task
list. The previous version of this code also incorrectly interpreted
the meaning of GDB TIDs -1 and 0. When GDB sends an "Hg0" command
early in the connection process, it doesn't expect the server to set
task 0 as the current task, as the code assumed. Rather, it tells the
server to "set any (arbitrary) task as the current one", and the most
logical thing to do for the server that is already in "stopped" state
is to keep the current task selection.
Since TID 0 has a special meaning in GDB remote protocol, gdbstub code
is now modified to map task indices (which start from 0) to GDB TIDs.
GDB TIDs are arbitrary, and for simplicity we keep the same order and
start counting them from 1.
The summary of all the above changes is:
1. Use "task index + 1" as the TID reported to GDB
2. Report the tasks in natural order; don't complicate the code to
make the paniced task first in the list.
3. Centralize modification of 'current_task_index' and 'regfile'
in the new 'set_active_task' function, to improve encapsulation.
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.
The previous location was the return from the first ets_printf call
that prints ROM sign-on message. Since the main function was patched
in ECO3, the new address no longer works — there is no instruction at
0x40007901 in ECO3 ROM. This could be solved by setting two
breakpoints (one would work for ECO <=2, the other for ECO3), but we
would need to remove the unused breakpoint later.
Fix this by setting the breakpoint at ets_printf. This means that when
debugging a loadable ELF the ROM sign-on message will no longer be
shown, but this doesn't seem to be an issue.
Possible for a joined task to be deleted at the moment it is logging,
meaning it might hold the stdout lock. In that case the lock isn't
released and the next task to try and take it (i.e. call printf)
will block indefinitely.
At -O2 optimization level, GCC seems to optimize out the copying of the
first byte of the checksum, assuming it is zero. This "miscompilation"
happens because the esp_app_desc struct is declared const, but then modified
post-compilation. Casting to volatile disables the optimization.
Closes: https://github.com/espressif/esp-idf/pull/6389
Fixes an issure where the first part of an object file name is not
included, due to matching the rule for a section entry previously.
Reduce depedency on matching literal strings in sections which might
change depending on toolchain (ex. matching 'elf32-xtensa-le')
Make sure parsing rule succeeds for the entirety of the sections info
string by adding 'parseAll=True'.
Add test for sections info parsing.
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
* Better comment of nvs_get_used_entry_count()
* Mention C++ example in API reference
* WIP: Used target instead of hard code ESP32
* Note that strings can only span one page
* Reflect that item types have been moved
* Some clarification about nvs_commit()
* Improved reference to the ESP Partition API
* fixed little mistake in documenting-code.rst
* Change of nvs_open_from_part() to
nvs_open_from_partition() reflected in docs
* Corrected documentation of
NVSHandle::get_string(), NVSHandle::get_blob()
and NVSHandle::get_item_size().
* Closes IDF-1563
* Closes IDF-859
* Closes https://github.com/espressif/esp-idf/issues/6123
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.
ROM will erase the region a partition is in as soon as it receives the
first bit of the data that is in the partition. For large partitions it
takes more than 5 seconds to erase which is a hard-coded limit in
dfu-utils.
This splits large binaries and adds them by chunks which should avoid
timing-out during flashing.
Closes https://github.com/espressif/esp-idf/issues/6999
Esptool submodule got updated which changed the function signature for EncryptFlashDataArgs.
Update example test script to reflect the new function signature
Since dd849ffc, _rodata_start label has been moved to a different
linker output section from where the TLS templates (.tdata, .tbss)
are located. Since link-time addresses of thread-local variables are
calculated relative to the section start address, this resulted in
incorrect calculation of THREADPTR/$tp registers.
Fix by introducing new linker label, _flash_rodata_start, which points
to the .flash.rodata output section where TLS variables are located,
and use it when calculating THREADPTR/$tp.
Also remove the hardcoded rodata section alignment for Xtensa targets.
Alignment of rodata can be affected by the user application, which is
the issue dd849ffc was fixing. To accommodate any possible alignment,
save it in a linker label (_flash_rodata_align) and then use when
calculating THREADPTR. Note that this is not required on RISC-V, since
this target doesn't use TPOFF.
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
mbedtls: fix mbedtls dynamic resource memory leaks and mbedtls_ssl_send_alert_message crash due to ssl->out_iv is NULL[backport v4.2]
See merge request espressif/esp-idf!13301
RX process caches the session information in "ssl->in_ctr" not in "ssl->in_buf".
So when freeing the SSL, can't free the "ssl->in_ctr", because the "ssl->in_buf"
is empty.
Make the RX process like TX process, and cache the session information in
"ssl->in_buf", so that the cache buffer can be freed when freeing the SSL.
Closes https://github.com/espressif/esp-idf/issues/6104
When user forgot to add git.exe or python to the PATH, there was a not
very helpful error message.
This improves the error with which tool is misssing and shows a link to
the espressif installer tool.
mdns resolver didn't correctly resolved queries when host name wasn't
assigned. Fixed by allowing processing also if some answer present
(non-strict mode)
Closes https://github.com/espressif/esp-idf/issues/6598
The resolver was able to respond correctly, but would also resolve its
own queries and cause issues with BCT 1.5.2, specifically
* MULTIPLE QUESTIONS - DUPLICATE SUPPRESSION
* MULTIPLE QUESTIONS - DISTRIBUTED DUPLICATE SUPPRESSION
tests failed.
Strict mode was hardcoded in private header file, but it's useful for
users to enable/disable it depending on the mdns library they are using.
e.g. Avahi might not resolve the non-strict answers.
Current code stopped inquiry if major class is not Phone. Modified the
condition to consider for both Phone and Audio to cover majority of real
world devices.
Closes https://github.com/espressif/esp-idf/issues/6548
1. Unlock mutex for esp_wifi_80211_tx when out of memory.
2. Fix issue that esp_wifi_80211_tx can't be used in ap mode.
3. Clear hotspot bss when auth timeout happens.
4. Fix PMK not saved in NVS for SoftAP for PSK mode.
5. Fix the bug for esptouch find hidden AP fail.
6. Fix not connect to open AP when WPA3 auth fail.
7. Fix issue with hidden AP scans after connecting AP.
8. Fix the watchdog issue when receiving action frame.
9. Fix the issue that the parameters obtained form RAM cannot be saved to NVS.
10.Modify not to store the default value in NVS.
11.Delete interface STATIONAP_IF.
12.Modify the _do_wifi_start and _do_wifi_stop parameters to mode.
13.Fixed issue of reason code change from 15 to 204 when provide wrong password.
14.Fix set config return value error.
15.Fix ampdu age timer memory leak.
Fixes issue with DPORT init task, this task uses minimum stack size and may not be
enough if stack smashing detection is set to Overall mode.
Also reworks the way we calculate minimum stack to allow for adding multiple
contributing factors.
Closes https://github.com/espressif/esp-idf/issues/6403
1. Change wifi scan duration from 120ms to 100ms
2. Using deport reg instead of ahb
3. Revert to report specific reason code when receiving deauth during 4-way-handshark
4. Fix the bug that tx ampdu parameter is not from peer device
5. Faster WiFi station connect improvement, avoid 100ms passive scan
6. Add FCS failed packets filter
7. Fix country code last byte to space instead of NULL
8. Fix softap cannot forward A-MSDU
9. Fix max tx power to 20dBm
10. Fix the issue that the esp_wifi_sta_get_ap_info can't get country
11. Update esp32 phy lib to v4660
12. Update esp32s2 phy lib to v1300
13. Fix the bug that esp32s2 can't get CSI info
On S2 the brown out detector would occasionally trigger erroneously during deep sleep.
Disable it before sleeping to circumvent this issue.
Closes https://github.com/espressif/esp-idf/issues/6179
Sometimes the flash size read from bootloader is not correct. This may
forbid SPI Flash driver from reading the the area larger than the size
in bootloader header.
When the new config option is enabled, the latest configured
ESPTOOLPY_FLAHSIZE in the app header will be used to override the value
read from bootloader header.
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().
With the introduction of cookies to track a session, it is possible that the
clients restart the provisioning on the same session, specifically when a user
cancels a current provisioning attempt. This can result in an error as the state
on the device side and client side will go out of sync.
This has now been changed such that if SESSION_STATE_CMD0 is received on
an existing session, the state is reset and flow allowed to continue.
Earlier, a "socket connection" was being considered as a protocomm "session".
However, for HTTP, we cannot expect clients to necessarily use the same
socket for all requests of a given transaction. This was indeed causing
some failures for Wi-Fi provisioning from Android phones.
So, we have introduced http cookies to track a session even if the socket
connection does not stay intact throughout the transaction.
This change is backward compatible. If the client does not use cookies, the
socket connection will be considered as the session.
Closes: https://github.com/espressif/esp-idf/issues/6316
Reference: https://github.com/espressif/esp-idf/pull/6330
Not necessary in these cases, and prevents parens from expanding into the
assembly code added in the parent commit - a pattern which is accepted
by GCC assembler but illegal syntax for LLVM assembler.
Fix for issues where RTC FAST memory is updated as part of going into deep
sleep. Very high risk if heaps are in RTC memory - in particular task stacks
may be in RTC memory, but also other variables.
Also fixes potential concurrency problems as RTC FAST memory is not accessible
by CPU during the CRC calculation itself.
Method:
- Disable interrupts (currently for single core only, will need update for S3)
- Load all registers before calculating CRC or going to sleep
This reverts commit bf35ef1ce7.
It has been noticed that there are scenarios where even though firmware is not enabled
with flash encryption config feature, it should be able to write to encrypted partitions.
This revert adds the feature back which was removed around v4.0 timelines, and same
change will be backported to all releases (upto v4.0) for consistency.
esp_http_server: Add flag in sock_db to identify httpd_sess_close is called from httpd_session_close_lru (v4.2)
See merge request espressif/esp-idf!12112
esp_modem_stop_ppp() stops both ppp netif and switches the modem back to
command mode. IF these two actions are not synchronised, we might
experience issues of
* active PPP session trying to send/receive uart-data
* command mode already active before modem switched to it
both resulting in crashes.
Fixed by introducing the transition mode and running these actions in sequence
* set esp-modem to transition mode
* enter command mode, wait for the reply or re-sync
* close the PPP netif
* wait until the netif closes
Other fixes include ignoring certain events if modem component not ready
or not in appropriate mode:
* ignoring all UART events comming from DTE with no DCE attached
* ignore pattern detection in PPP mode
- 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
To be in line with other interfaces, when deleting the driver and it's glue layer to esp-netif, we DO NOT delete the related esp-netif (since is was allocated and created outside of the glue code and it works the same way in esp-eth and esp-wifi driver/glue layers).
Closes https://github.com/espressif/esp-idf/issues/5486
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).
the mDNS responder should not repeat questions when replying, however resolvers
must ignore these questions field if they are present. esp-idf mDNS
library does include questions in answering packets (thus not strictly
following the RFC6762) so the resolver did not correctly resolved
another instance host name.
Closes https://github.com/espressif/esp-idf/issues/6190
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.
* When deinitializing or erasing a partition,
nvs used to close all handles instead of only
the current partition's handles.
This is fixed now
* Added a unit test for that case
* Unit tests clean up after each test case now
Closes FCS-533
Flag ESP32_WIFI_ENABLE_WPA3_SAE from Menuconfig is used to
control the stack size required by WPA3. Use the same flag
to compile out the WPA3 code and control the code size.
With this flag disabled code footprint reduces by about 7.7kB
in libwpa_supplicant.a
Update WiFi libs with added checks to cleanly handle disabling
of WPA3 callbacks.
1. Add description for esp_wifi_set_inactive_time()
2. Add documentation to avoid using WiFi modem sleep for WiFi/BT coexistence
3. Remove description of unusable API esp_wifi_restart()
4. Update esp_now_fetch_peer discription
5. Update table format prblm for esp_wifi_set_max_tx_power()
6. Update description for ssid and password
Curretly wpa_supplicant uses internal APIs for RSA operations
which internally uses lots of big num operations.
Big num operations are CPU expensive and can take a lot of time
which can cause watchdog timer to tigger.
This can be optimize by using mbedtls APIs which uses
hardware blocks for big num operations.
To fix this, write new crypto_mbedtls-rsa.c which has APIs
similar to crypto_internal-rsa.c but uses mbedtls APIs.
By default adds original queries to responses in order to be resolved by some resolvers, such as lwIP mdns library. This functionality however is discouraged by the RFC6762, so it could be disabled in menuconfig if MDNS_STRICT_MODE configured
Closes https://github.com/espressif/esp-idf/issues/5521
esp_http_client: Skip check for redirection counter if status code is success, fix issue with digest auth, configurable user agent string. (v4.2)
See merge request espressif/esp-idf!11597
tools/ldgen: Parse paths with Unicode characters in archives & fix parsing of section names on Windows (v4.2)
See merge request espressif/esp-idf!10964
* 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
This commit adds the feature where the TWAI 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_TWAI_ISR_IN_IRAM option.
This commit simplifies the defines made in the _caps.h header. Kconfig
option dependencies were moved into the LL, and the check for a
valid BRP has bee simplified.
esp-modem netif glue layer implements esp-netif attach callback to setup corresponding driver functions and start the modem. The error code of esp_modem_start_ppp() was ignored and ESP_OK returned in all cases. Fixed by passing esp_modem_start_ppp()'s error code to post_attach callback.
Closes https://github.com/espressif/esp-idf/issues/5430
The struct definition of ip6_addr_t in lwip and esp_ip6_addr_t
differs since zone could be possibly disabled in lwip. Using memcpy to copy the
address will cause wrong source address. Copy the entries manually
instead.
Merges https://github.com/espressif/esp-idf/pull/6055
1. will post twice disconnect event when read error
2. will block `timeout` times when set disable_auto_connect
3. When `esp_websocket_client_stop` before `esp_websocket_client_send*`,
if the `esp_websocket_client_send*` fails, the status will change to
'WEBSOCKET_STATE_WAIT_TIMEOUT', and the next `esp_websocket_client_start` will fail forever
When `pthread_mutex_destroy` is used to release mutex, `pthread_mutex_lock_internal` is used,
which results in the increase of `uxmutexehold` and no recovery base priority
1.Fix supervision timeout in LLC DISC busy statue can not disconnect issue.
2.Solve the problem that the ble terminate ack packet may lose with a high probability in coex mode.
For WPA3 connection nearing PMK lifetime expiry, PMK Cache
needs a re-authentication or the cache will expire. After
current expiry of 12 hours Station ends up sending a deauth
to the AP. An SAE re-authentication also cannot occur without
a disconnection with current implementation. So increase the
PMK lifetime to 100 days for now.
use eventgroup to sync spp_vfs_write
each connection has a switch_delay_timer not sharing a one
revert functions like spp_find_slot_by_xxx
fix vfs read bug when peer close
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
1. Add STA checks during STA PMF operations
2. Fix WPA2-Ent issue with Open AP
3. Skip WPA-TKIP profile if PMF is required
4. Skip & clear Supplicant PMK Cache with mismatching AP config
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.
Also add some explanation about configuring the project in the README
Previously with the default build-esp32.sh script, the build directory was
deleted and recreated so the project would always be built with default config.
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.
Commit 5e8795eebe has changed the partition table offset, which
has resulted in the ciphertext not matching the one expected in the
example test.
Fix by calculating the ciphertext using espsecure.py.
When the flash encryption is enabled then we do not need to change the partition table.
The partition_example.csv should not have fixed offsets for partitions because we want to move the whole table.
The fixed offsets in the table were cleared.
When idf.py gdb starts, it expects openocd was started in the background
and creates a thread to watch for openocd errors. when gdb target exits,
the debug_ext.py aims to cleanup all threads and processes, but fails
with traceback if openocd-watch thread not available, which could happen
if openocd started separately.
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
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
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.
1. Modify LR for esp32 and esp32s2
2. Fix esp32s2 RTS rate
3. Optimize some debug logs for probe response
4. Optimize phy and soc files
5. Add IPv6 DSCP
6. Fix classify AC to TID
7. Fix the bug that no event for connect
Commit 891eb3b0 was fixing an issue with PS and EPC1 not being
preserved after the window spill procedure. It did so by saving PS in
a2 and EPC1 in a4. However the a4 register may be a live register of
another window in the call stack, and if it is overwritten and then
spilled to the stack, then the corresponding register value will end
up being corrupted. In practice the problem would show up as an
IllegalInstruction exception, when trying to return from a function
when a0 value was 0x40020.
Fix by using a0 register instead of a4 as scratch. Also fix a comment
about xthal_save_extra_nw, as this function in fact doesn't clobber
a4 or a5 because XCHAL_NCP_NUM_ATMPS is defined as 1.
Closes https://github.com/espressif/esp-idf/issues/5758
Can still be enabled by passing --cmake-warn-uninitialized on the command line
Prevents CMake warnings printed by default if IDF_PATH is underneath the CMake
project directory.
The reason for this is that CMake --warn-uninitialized only enables checks
inside the project directory (ie top-level CMakeLists.txt directory and
subdirectories), it doesn't enable for files included from other directories.
(The only way to enable warnings in other directories is to pass
--check-system-dirs and this looks like it's only useful for CMake's own
developers as it prints a lot of warnings from inside CMake otherwise - see
https://gitlab.kitware.com/cmake/cmake/-/issues/19645 )
Plan to follow up with a later commit to clean up most of the warnings (which
aren't problems for CMake execution), but we'll also disable this option by
default to avoid this unexpected triggering of IDF warnings.
Due to eager_exclude, Sphinx jobs cannot use the doc cache (doctrees).
PDF and HTML building are now seperate CI jobs to avoid this issue.
PDF building will only be ran on deploy branches and when started
with build_docs tag to reduce CI load
1. Add g_av_with_rc to avrc_tg_init function
2. Remove g_av_open_fail
3. Add comment in API files
4. Add a2dp init & deinit state variable to inidcate a2dp statement
1. Add reaction for a2dp snk & src disconn req when no link up
2. Change state machine set before EVT upto APP layer in some cases
3. Add bool open_fail to choose whether post disconnection evt to app layer
Fixup more for PSRAM issue;
Allow GDB work correctly with Privileged Registers;
Based on GCC 8.4.0;
Update a fix of C++ exception crashs from the GCC mainline;
Fixup strptime_l() and some locale in libc;
If Secure Boot is enabled, there's no bootloader flasher arguments in the
project (to encourage careful manual flashing), so this command would
fail with a KeyError.
Per WiFi library requirement, SSID can be non-null terminated string
if its length goes to 32 bytes (maximum). Use of strncpy in this case,
along with compiler optimization level -O2 results in some warnings
for potential use of non-null terminated strings.
Fix here ensures use of memcpy to copy SSID string upto appropriate
desired length. This helps to avoid compiler specific workaround
flags added earlier.
Closes https://github.com/espressif/esp-idf/issues/5866
Closes IDFGH-3983
bootloader_support: don't check signature when JTAG is attached, fix signed partition table generation (v4.2)
See merge request espressif/esp-idf!10378
Bootloader DRAM now ends at 0x3FFEAB00 which is the start of ROM
static RAM (reclaimable after app is running).
IRAM loader segment increased by 8KB.
Available total static RAM for the app is now reduced by 16KB.
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.
Fixes the issue that signed partition table was not generated when
CONFIG_SECURE_BOOT_BUILD_SIGNED_BINARIES was on, because
partition_table_bin depended on unsigned_partition_bin twice.
Regression from acb7a211.
Also use final_partition_bin variable in esptool_py_flash_target_image
arguments, to avoid issues in the future if final_partition_bin is
changed.
- 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.
{esp32,esp32s2}.inc files contain most of the bits and code snippets
which are different between targets. These bits are included from the
rest of the source files.
Also included is an update to the section about OpenOCD configuration
variables and files. This section wasn't updated when some of the
files and variables got renamed.
CONFIG_FREERTOS_ISR_STACKSIZE was set to 2100 when ELF core dump was
enabled, which resulted in a non-16-byte-aligned interrupt stack
offset. This triggered "is SP corrupted" check in the backtrace,
terminating the backtrace early.
Fix the default value, and make sure that the stack is always aligned,
regardless of the value of CONFIG_FREERTOS_ISR_STACKSIZE.
InstrFetchProhibited usually occurs because of a jump to an invalid
pointer. In this case, PC in the exception frame is the address of
the jump destination. 'esp_ptr_executable' check in print_backtrace
function recognizes the first frame as invalid, and the backtrace is
interrupted. This prevents the user from finding the location where
the invalid pointer is dereferenced.
Bypass the 'esp_ptr_executable' check if the exception cause is
InstrFetchProhibited. Update the test case to no longer ignore this
issue.
1. Add logs for SPP not enabled successfully
2. Add information to Applicatioin layer that the A2DP is connecting to peer device
Regular BTC and BTU Task name & Add BTC Init protection
1. Regular the BTC Task Name to Close a Github issue
Closes https://github.com/espressif/esp-idf/issues/4966
2. Add BTC Init failure protection
3. Regular BTU Task Name with BTC
4. Correct the comment of
a. SDP_ServiceSearchRequest and SDP_ServiceSearchRequest2
b. l2cu_create_conn_after_switch
5. Correct comment of esp_bt_hf_vra();
6. Fix cpp compilier region
Add logic to set `FIN` flag automatically for transmitted WS frames, but
if `fragmented` option set indicating an expert/manual mode, then the
`FIN` flag is set according to the `final` option.
H/W decryption of Mgmt frames was disabled for PMF and done through
S/W. If ESPNOW packets go through this path, it affects backward
compatibility since method of decrypting Mgmt packets is different in H/W.
To address PMF + ESPNOW Co-existance, CCMP decryption method is modified
for ESPNOW packets so that they can be decrypted correctly. Since Tx
of ESPNOW packets can still be done in H/W alongside PMF, no change
required in encryption method in S/W.
Co-Authored-By: Nachiket Kukade <nachiket.kukade@espressif.com>
Co-Authored-By: zhangyanjiao <zhangyanjiao@espressif.com>
Co-Authored-By: kapil.gupta <kapil.gupta@espressif.com>
wpa_supplicant: Deinit wpa2 states in wifi deinit
See merge request espressif/esp-idf!10103
(cherry picked from commit 4dcaa0e6f4)
06bc7f1d wpa_supplicant: Deinit wpa2 states in wifi deinit
ESP32 lets the user choose from using Vref, Lookup Table, and Two-Point Calibration. In ESP32S2 only two-point calibration is supported. This commit support these changes in idf.
Closes https://github.com/espressif/esp-idf/issues/5455
1.Fix WiFi fragment issue
2.fix the bug for softAP power save buffer issue
3.fix softap mode event issue
4.fix connect hidden AP doesn't update information
5.update esp32 phy v4370
If esp_restart_noos() is run and the stack address points to external memory (SPIRAM)
then Cache_Read_Disable() raises up the error "Cache disabled but cached memory region accessed"
to fix this we switch stack to internal RAM before disable cache.
Added unit tests.
Closes: https://github.com/espressif/esp-idf/issues/5107
1. If Device is connected to AP in WPA3-PSK mode, AP switching
security to WPA2-PSK causes connection failures even after reset.
Fix is to not store WPA3's PMK in NVS for caching.
2. AP switching back to WPA3 causes even more connection failures.
This is due to device not clearing Supplicant level PMK Cache when
it is no longer valid. Fix is to clear the Cache when 4-way handshake
fails and to check Key Mgmt of Cache before using.
3. When AP switches from WPA3 to WPA2, device's PMF config in
Supplicant remains enabled. This may cause failures during
4-way handshake. So clear PMF config in when PMF is no longer used.
If the olddelta argument is not a null pointer, the adjtime function returns information
about any previous time adjustment that has not yet completed.
Closes: https://github.com/espressif/esp-idf/issues/5194
Replace periph_module_enable/disable by periph_wifi_bt_common_module_enable which are in IRAM.
AddIRAM_ATTR periph_ll_wifi_bt_module_enable_clk_clear_rstandIRAM_ATTR periph_ll_wifi_bt_module_disable_clk_set_rstto fit O0 optimization level.
Delete duplicated spinlock and counter.
Extended test cases for DHCP server and DHCP client state transitions to include also manual transitions using esp_netif_dhcps_start/stop() esp_netif_dhcpc_start/stop()
This commit adds TWAI driver support for the
ESP32-S2. The following features were added:
- Expanded BRP support
- Expanded CLKOUT Divider Support
- Updated example READMEs
In some cases gen_version_specific_includes.py would fail to find a branch/tag name for a commit
and would fall back to using commit SHA-1.
This should never happen in docs that should be published as we use the branch/tag name to generate
example commands for our users. E.g. "git clone -b $branch_name"
Closes https://github.com/espressif/esp-idf/issues/5657
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.
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.
Add following changes as part of this:
1. EAP client will crash during validation of key size when CA
certs and keys not present. Add changes to validate it first.
2. Free memory allocated in TLS context
Allows booting in QIO/QOUT mode or with PSRAM on ESP32-PICO-V3 and
ESP32-PICO-V3-O2 without any config changes.
Custom WP pins (needed for fully custom circuit boards) should still be compatible.
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.
mbedTLS stack does not keep TLS renegotiation enabled even if
relevant config option is turned on, it needs explicit API call
`mbedtls_ssl_conf_renegotiation` to do so.
This issue was observed in case of Azure IoT, where keys needs to
be refreshed periodically to keep TLS connection intact.
Same logic as for the ESP32, except two changes:
* need to set UART_SW_FLOW_CON_EN bit for UART_FORCE_XOFF to take
effect
* need to check if the peripheral is not clockgated and out of reset
Previously both tasks had equal priority, possible for write task and another
internal task to be scheduled at the same time - starving read task and
causing data loss.
Related to IDFCI-59
Some errors (for example the errors caused by macro values, as fixed in previous
commit) get logged to stderr even if WARN_LOGFILE is set, but Doxygen succeeds.
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
1. Avoid parsing RSN/WPA IE's after connection
2. Remove AUTH_CHANGED reason code logic
3. fix the bug when calculating the PMK, the local rx beacon time increment is 0
4. mesh: don't disconnect when tbtt update
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.
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.
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.
Signed-off-by: Chinmay Chhajed <chinmay.chhajed@espressif.com>
1. remove warning log when mesh is started:
Error! Should use default passive scan time parameter for WiFi scan when Bluetooth is enabled!!!!!!
2. remove abort when mesh is started:
Error! Should enable WiFi modem sleep when both WiFi and Bluetooth are enabled!!!!!!
- 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.
1.In the description of the ESP_API header file, it should be the event that the application layer needs to handle, not the BTA layer.
2.Fix name typo of BTA_GATTS_CREATE_SRVC_EVT event
Closes https://github.com/espressif/esp-idf/issues/5446
In commit 309376f51a, it seems like regression
was added to use ROM level API for disabling flash write protection. This
started random firmware crashes (on specific modules) with exception
`IllegalInstruction` during encrypted flash writes.
Fix here removes relevant ROM API call, since disabling flash write protection
is already ensured by caller of this API.
Closes https://github.com/espressif/esp-idf/issues/5467
- 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.
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.
If IDF_PYTHON_ENV_PATH was not set, an exception occurred:
Traceback (most recent call last):
File "/home/user/esp/esp-idf/tools/check_python_dependencies.py", line 108, in <module>
if idf_python_env_path not in sys.executable:
TypeError: 'in <string>' requires string as left operand, not NoneType
and the final line in the diagnostic message was not printed.
Fix to print the PATH if IDF_PYTHON_ENV_PATH is not set.
esp32/esp32s2: Reduce using ESP_EARLY_LOGx and move some code after the stdout initialization in startup code (v4.2)
See merge request espressif/esp-idf!9202
1. Fix WPA3 Auth timeout during BLE coex
2. fix addba ssn and send bar for first ampdu
3. fix the bug that airkiss find hidden AP fail
4. update mesh lib
5. fix interrupt handle param variable error
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.
check_public_headers.py would fail when reading non-ascii chars on systems where
the default encoding was ascii.
Also fixes error handling issues, as any uncaught exeception would cause the program
to run indefinitely.
Added following as part of this change
1. Removed auth_changed event
2. Updated doc regarding usage of WPA/WEP secuiry modes
3. Fixed WPA2 enterprise authmode threshold.
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
description:Before submitting a new issue, please follow the checklist and try to find the answer.
options:
- label:I have read the documentation [ESP-IDF Programming Guide](https://docs.espressif.com/projects/esp-idf/en/latest/) and the issue is not addressed there.
required:true
- label:I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
required:true
- label:I have searched the issue tracker for a similar issue and not found a similar issue.
required:true
- type:input
id:idf_version
attributes:
label:IDF version.
description:Onwhich IDF version does this issue occur on? Run `git describe --tags` to find it.
placeholder:ex. v3.2-dev-1148-g96cd3b75c
validations:
required:true
- type:dropdown
id:operating_system
attributes:
label:Operating System used.
multiple:false
options:
- Windows
- Linux
- macOS
validations:
required:true
- type:dropdown
id:build
attributes:
label:How did you build your project?
multiple:false
options:
- Command line with Make
- Command line with CMake
- Command line with idf.py
- Eclipse IDE
- CLion IDE
- VS Code IDE
- Other (please specify in More Information)
validations:
required:true
- type:dropdown
id:windows_comand_line
attributes:
label:If you are using Windows, please specify command line type.
multiple:false
options:
- PowerShell
- CMD
validations:
required:false
- type:textarea
id:expected
attributes:
label:What is the expected behavior?
description:Please provide a clear and concise description of the expected behavior.
placeholder:I expected it to...
validations:
required:true
- type:textarea
id:actual
attributes:
label:What is the actual behavior?
description:Please describe actual behavior.
placeholder:Instead it...
validations:
required:true
- type:textarea
id:steps
attributes:
label:Steps to reproduce.
description:'How do you trigger this bug? Please walk us through it step by step. If this is build bug, please attach sdkconfig file (from your project folder). Please attach your code here.'
value:|
1. Step
2. Step
3. Step
...
validations:
required:true
- type:textarea
id:debug_logs
attributes:
label:Build or installation Logs.
description:Build or installation log goes here, should contain the backtrace, as well as the reset source if it is a crash.
placeholder:Your log goes here.
render:plain
validations:
required:false
- type:textarea
id:more-info
attributes:
label:More Information.
description:Do you have any other information from investigating this?
placeholder:ex. I tried on my friend's Windows 10 PC and the command works there.
description:Before submitting a new issue, please follow the checklist and try to find the answer.
options:
- label:I have read the documentation [ESP-IDF Programming Guide](https://docs.espressif.com/projects/esp-idf/en/latest/) and the issue is not addressed there.
required:true
- label:I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
required:true
- label:I have searched the issue tracker for a similar issue and not found a similar issue.
required:true
- type:input
id:idf_version
attributes:
label:IDF version.
description:Onwhich IDF version does this issue occur on? Run `git describe --tags` to find it.
placeholder:ex. v3.2-dev-1148-g96cd3b75c
validations:
required:true
- type:input
id:chip_revision
attributes:
label:Espressif SoC revision.
description:Onwhich Espressif SoC revision does your application run on? Run `esptool chip_id` to find it.
placeholder:ex. ESP32-C3 (QFN32) (revision v0.3)
validations:
required:true
- type:dropdown
id:operating_system
attributes:
label:Operating System used.
multiple:false
options:
- Windows
- Linux
- macOS
validations:
required:true
- type:dropdown
id:build
attributes:
label:How did you build your project?
multiple:false
options:
- Command line with Make
- Command line with CMake
- Command line with idf.py
- Eclipse IDE
- CLion IDE
- VS Code IDE
- Other (please specify in More Information)
validations:
required:true
- type:dropdown
id:windows_comand_line
attributes:
label:If you are using Windows, please specify command line type.
multiple:false
options:
- PowerShell
- CMD
validations:
required:false
- type:input
id:devkit
attributes:
label:Development Kit.
description:Onwhich Development Kit does this issue occur on?
* We welcome any ideas or feature requests! It’s helpful if you can explain exactly why the feature would be useful.
* There are usually some outstanding feature requests in the [existing issues list](https://github.com/espressif/esp-idf/labels/Type%3A%20Feature%20Request), feel free to add comments to them.
* If you would like to contribute, please read the [contributions guide](https://docs.espressif.com/projects/esp-idf/en/stable/esp32/contribute/index.html).
- type:textarea
id:problem-related
attributes:
label:Is your feature request related to a problem?
description:Please provide a clear and concise description of what the problem is.
placeholder:ex. I'm always frustrated when ...
- type:textarea
id:solution
attributes:
label:Describe the solution you'd like.
description:Please provide a clear and concise description of what you want to happen.
placeholder:ex. When connecting to an Espressif chip ...
- type:textarea
id:alternatives
attributes:
label:Describe alternatives you've considered.
description:Please provide a clear and concise description of any alternative solutions or features you've considered.
placeholder:ex. Choosing other approach wouldn't work, because ...
- type:textarea
id:context
attributes:
label:Additional context.
description:Please add any other context or screenshots about the feature request here.
description:Before submitting a new issue, please follow the checklist and try to find the answer.
options:
- label:I have read the documentation [ESP-IDF Programming Guide](https://docs.espressif.com/projects/esp-idf/en/latest/) and the issue is not addressed there.
required:true
- label:I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
required:true
- label:I have searched the issue tracker for a similar issue and not found a similar issue.
**Reminder: If your issue is a general question, starts similar to "How do I..", or is related to 3rd party development kits/libs, please discuss this on our community forum at https://esp32.com instead.**
INSTRUCTIONS
============
Before submitting a new issue, please follow the checklist and try to find the answer.
- [ ] I have read the documentation [ESP-IDF Programming Guide](https://docs.espressif.com/projects/esp-idf/en/latest/) and the issue is not addressed there.
- [ ] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
- [ ] I have searched the issue tracker for a similar issue and not found a similar issue.
If the issue cannot be solved after the steps before, please follow these instructions so we can get the needed information to help you in a quick and effective fashion.
1. Fill in all the fields under **Environment** marked with [ ] by picking the correct option for you in each case and deleting the others.
2. Describe your problem.
3. Include [debug logs from the "monitor" tool](https://docs.espressif.com/projects/esp-idf/en/latest/get-started/idf-monitor.html#automatically-decoding-addresses), or [coredumps](https://docs.espressif.com/projects/esp-idf/en/latest/api-guides/core_dump.html).
4. Providing as much information as possible under **Other items if possible** will help us locate and fix the problem.
5. Use [Markdown](https://guides.github.com/features/mastering-markdown/) (see formatting buttons above) and the Preview tab to check what the issue will look like.
6. Delete these instructions from the above to the below marker lines before submitting this issue.
**IMPORTANT: If you do not follow these instructions and provide the necessary details, your issue may not be resolved.**
The main development is done in Espressif Gitlab project.
Espressif [GitHub project espressif/esp-idf](https://github.com/espressif/esp-idf) is only a public mirror.
Therefore, all changes and updates to DangerJS files (`.github/dangerjs`) must be made via MR in the **Gitlab** repository by Espressif engineer.
When adding a new Danger rule or updating existing one, might be a good idea to test it on the developer's fork of GitHub project. This way, the new feature can be tested using a GitHub action without concern of damaging Espressif's GitHub repository.
Danger for Espressif GitHub is implemented in TypeScript. This makes the code more readable and robust than plain JavaScript.
Compilation to JavaScript code (using `tsc`) is not necessary; Danger handles TypeScript natively.
A good practice is to store each Danger rule in a separate module, and then import these modules into the main Danger file `.github/dangerjs/dangerfile.ts` (see how this is done for currently present modules when adding a new one).
If the Danger module (new check/rule) uses an external NPM module (e.g. `axios`), be sure to add this dependency to `.github/dangerjs/package.json` and also update `.github/dangerjs/package-lock.json`.
In the GitHub action, `danger` is not installed globally (nor are its dependencies) and the `npx` call is used to start the `danger` checks in CI.
## Adding new Danger rule
For local development you can use following strategy
#### Install dependencies
```sh
cd .github/dangerjs
npm install
```
(If the IDE still shows compiler/typing errors, reload the IDE window.)
#### Add new code as needed or make updates
#### Test locally
Danger rules can be tested locally (without running the GitHub action pipeline).
To do this, you have to first export the ENV variables used by Danger in the local terminal:
👋 **Hi ${authorLogin}**, thank you for your another contribution to \`espressif/esp-idf\` project!
If the change is approved and passes the tests in our internal git repository, it will appear in this public Github repository on the next sync.
***
`;
constmessageFirstContributor: string=`
***
👋 **Welcome ${authorLogin}**, thank you for your first contribution to \`espressif/esp-idf\` project!
📘 Please check [Contributions Guide](https://docs.espressif.com/projects/esp-idf/en/latest/esp32/contribute/index.html#contributions-guide) for the contribution checklist, information regarding code and documentation style, testing and other topics.
🖊️ Please also make sure you have **read and signed** the [Contributor License Agreement for espressif/esp-idf project](https://cla-assistant.io/espressif/esp-idf).
#### Pull request review and merge process you can expect
Espressif develops the ESP-IDF project in an internal repository (Gitlab). We do welcome contributions in the form of bug reports, feature requests and pull requests via this public GitHub repository.
1. An internal issue has been created for the PR, we assign it to the relevant engineer
2. They review the PR and either approve it or ask you for changes or clarifications
3. Once the Github PR is approved, we synchronize it into our internal git repository
4. In the internal git repository we do the final review, collect approvals from core owners and make sure all the automated tests are passing
- At this point we may do some adjustments to the proposed change, or extend it by adding tests or documentation.
5. If the change is approved and passes the tests it is merged into the \`master\` branch
6. On next sync from the internal git repository merged change will appear in this public Github repository
***
`;
/**
* Check whether the author of the pull request is known or a first-time contributor, and add a message to the PR with information about the review and merge process.
- [Manifest File to Control the Build/Test apps](#manifest-file-to-control-the-buildtest-apps)
- [Grammar](#grammar)
- [Special Rules](#special-rules)
- [Upload/Download Artifacts to Internal Minio Server](#uploaddownload-artifacts-to-internal-minio-server)
- [Users Without Access to Minio](#users-without-access-to-minio)
- [Users With Access to Minio](#users-with-access-to-minio)
- [Env Vars for Minio](#env-vars-for-minio)
- [Artifacts Types and File Patterns](#artifacts-types-and-file-patterns)
- [Upload](#upload)
- [Download](#download)
## General Workflow
1. Push to a remote branch
2. Create an MR, choose related labels (not required)
3. A `detached` pipeline will be created.
4. if you push a new commit, a new pipeline will be created automatically.
## What if Expected Jobs ARE NOT Created?
1. check the file patterns
If you found a job that is not running as expected with some file changes, a git commit to improve the `pattern` will be appreciated.
2. please add MR labels to run additional tests, currently we have to do this only for `target-test` jobs, please use it as few as possible. Our final goal is to remove all the labels and let the file changes decide everything!
## MR labels for additional jobs
### Supported MR Labels
-`build`
-`build_docs`
-`component_ut[_esp32/esp32s2/...]`
-`custom_test[_esp32/esp32s2/...]`
-`docker`
-`docs`
-`docs_full`, triggers a full docs build, regardless of files changed
-`example_test[_esp32/esp32s2/...]`
-`fuzzer_test`
-`host_test`
-`integration_test`
-`iperf_stress_test`
-`macos`
-`macos_test`
-`nvs_coverage`
-`submodule`
-`windows`
There are two general labels (not recommended since these two labels will trigger a lot of jobs)
-`target_test`: includes all target for `example_test`, `custom_test`, `component_ut`, `integration_test`
-`all_test`: includes all test labels
### How to trigger a `detached` pipeline without pushing new commits?
Go to MR web page -> `Pipelines` tab -> click `Run pipeline` button.
In very rare case, this tab will not show up because no merge_request pipeline is created before. Please use web API then.
```shell
curl -X POST --header "PRIVATE-TOKEN: [YOUR PERSONAL ACCESS TOKEN]"[GITLAB_SERVER]/api/v4/projects/103/merge_requests/[MERGE_REQUEST_IID]/pipelines
```
## How to Develop With `rules.yml`?
### General Concepts
-`pattern`: Defined in an array. A GitLab job will be created if the changed files in this MR matched one of the patterns. For example:
```yaml
.patterns-python-files: &patterns-python-files
- "**/*.py"
```
- `label`: Defined in an if clause, similar as the previous bot command. A GitLab job will be created if the pipeline variables contains variables in `BOT_LABEL_xxx` format (DEPRECATED) or included in the MR labels. For example:
- `rule`: A combination of various patterns, and labels. It will be used by GitLab YAML `extends` keyword to tell GitLab in what conditions will this job be created. For example:
```yaml
.rules:build:docs:
rules:
- <<: *if-protected
- <<: *if-label-build_docs
- <<: *if-label-docs
- <<: *if-dev-push
changes: *patterns-docs
```
An example for GitLab job on how to use extends:
```yaml
check_docs_lang_sync:
extends:
- .pre_check_template
- .rules:build:docs
script:
- cd docs
- ./check_lang_folder_sync.sh
```
### How to Add a New `Job`?
check if there's a suitable `.rules:<rules-you-need>` template
1. if there is, put this in the job `extends`. All done, now you can close this window. (`extends` could be array or string)
2. if there isn't
1. check [How to Add a New `Rules` Template?](#how-to-add-a-new-rules-template), create a suitable one
2. follow step 1
### How to Add a New `Rules` Template?
check if this rule is related to `labels`, `patterns`
1. if it is, please refer to [dependencies/README.md](./dependencies/README.md) and add new rules by auto-generating
2. if it isn't, please continue reading
check if there's a suitable `.if-<if-anchor-you-need>` anchor
1. if there is, create a rule following [`rules` Template Naming Rules](#rules-template-naming-rules).For detail information, please refer to [GitLab Documentation `rules-if`](https://docs.gitlab.com/ee/ci/yaml/README.html#rulesif). Here's an example.
```yaml
.rules:patterns:python-files:
rules:
- <<: *if-protected
- <<: *if-dev-push
changes: *patterns-python-files
```
2. if there isn't
1. check [How to Add a New `if` Anchor?](#how-to-add-a-new-if-anchor), create a suitable one
2. follow step 1
### How to Add a New `if` Anchor?
Create an `if` anchor following [`if` Anchors Naming Rules](#if-anchors-naming-rules). For detailed information about how to write the condition clause, please refer to [GitLab Documentation `only/except (advanced)](https://docs.gitlab.com/ee/ci/yaml/README.html#onlyexcept-advanced). Here's an example.
```yaml
.if-schedule:&if-schedule:
if:'$CI_PIPELINE_SOURCE == "schedule"'
```
### Naming Rules
#### Common Naming Rules
if a phrase has multi words, use `_` to concatenate them.
> e.g. `regular_test`
if a name has multi phrases, use `-` to concatenate them.
> e.g. `regular_test-example_test`
#### `if` Anchors Naming Rules
- if it's a label: `.if-label-<label_name>`
- if it's a ref: `.if-ref-<ref_name>`
- if it's a branch: `.if-branch-<branch_name>`
- if it's a tag: `.if-tag-<tag_name>`
- if it's multi-type combination: `.if-ref-<release_name>-branch-<branch_name>`
a combination of `example_test`, `custom_test`, `component_ut`, `integration_test` and all targets
#### `rules` Template Naming Rules
- if it's tag related: `.rules:tag:<tag_1>-<tag_2>`
- if it's label related: `.rules:labels:<label_1>-<label_2>`
- if it's test related: `.rules:test:<test_type>`
- if it's build related: `.rules:build:<build_type>`
- if it's pattern related: `.rules:patterns:<patterns>`
## Reusable Shell Script `tools/ci/utils.sh`
It is used to put all the reusable shell scripts as small functions. If you want to set `before_script: []` for you job, now you can set `extends: .before_script_slim` instead. it will only run `source tools/ci/utils.sh`
If you're developing CI shell scripts, you can use these functions without `source` them. They're already included in all `before_script`
To run these commands in shell script locally, place `source tools/ci/utils.sh` at the very beginning.
### Functions
#### CI Job Related
-`add_gitlab_ssh_keys`
-`add_github_ssh_keys`
-`add_doc_server_ssh_keys`
-`fetch_submodules`
-`get_all_submodules`
#### Shell Script Related
-`error`: log in red color
-`warning`: log in orange color
-`info`: log in green color
-`run_cmd`: run the command with duration seconds info
-`retry_failed`: run the command with duration seconds info, retry when failed
## Manifest File to Control the Build/Test apps
`.build-test-rules.yml` file is a manifest file to control if the CI is running the build and test job or not. The Supported Targets table in `README.md` for apps would be auto-generated by `pre-commit` from the app's `.build-test-rules.yml`.
### Grammar
We're using the latest version of [idf-build-apps][idf-build-apps]. Please refer to their [documentation][manifest-doc]
- if [ -n "$LOCAL_GITLAB_HTTPS_HOST" ]; then export LOCAL_CI_REPOSITORY_URL="https://gitlab-ci-token:${CI_JOB_TOKEN}@${LOCAL_GITLAB_HTTPS_HOST}/${CI_PROJECT_PATH}"; fi
- if [ -n "$LOCAL_GIT_MIRROR" ]; then export LOCAL_CI_REPOSITORY_URL="${LOCAL_GIT_MIRROR}/${CI_PROJECT_PATH}"; fi
- echo "Using repository at $LOCAL_CI_REPOSITORY_URL"
1. Auto-generate some labels/rules we need and update them in `rules.yml`
2. Generate a dependency tree graph
## Schema
This file only used basic YAML grammar and has nothing to do with the GitLab version YAML file.
It has five custom keywords:
-`matrix`: An array of sub-arrays, used to replicate rules by formatting strings. You can use the format string everywhere, it will be formatted recursively
-`labels`: An array of `labels`.
-`patterns`: An array of `patterns`. Patterns that not included
-`included_in`: An array of other `rule` names. It indicates the `labels` and `patterns` will be included in all specified `rules` as well
-`deploy`: An array of strings, used to replicate rules by adding postfix `-<item in deploy array>`. It indicates the extra `label` used in `rules`, which will explain later.
## How to use this file to generate `rules.yml`
Let's take a complicated example to help understand the process
```yaml
"test-{0}-{1}":
matrix:
- [a, b]
- [c, d]
labels:
- "{0}-{1}"
patterns:
- "{0}"
- pattern-not-exist
included_in:
- build-{0}
```
1. expand the mapping dicts defined by `matrix`
After this step, it will turn into 4 dicts:
| key | labels | patterns | included_in |
| -------- | ------ | -------- | ----------- |
| test-a-c | a-c | a | build-a |
| test-a-d | a-d | a | build-a |
| test-b-c | b-c | b | build-b |
| test-b-d | b-d | b | build-b |
**Advanced Usage: You can overwrite a mapping by declaring it again later**, For example:
If we concatenate this part to the previous example,
```yaml
# ... The same as the previous example
test-a-c:
labels:
- overwrite
```
`rule` `test-a-c` will be turned into:
| key | labels |
| -------- | --------- |
| test-a-c | overwrite |
**Mappings with the keyword `deploy` will also replicate by adding a postfix `-<item in deploy array>` to the mapping key**
2. create rules by `included_in`
After this step, it will turn into 6 mapping dicts:
| key | labels | patterns |
| -------- | -------- | -------- |
| test-a-c | a-c | a |
| test-a-d | a-d | a |
| test-b-c | b-c | b |
| test-b-d | b-d | b |
| build-a | a-c, a-d | a |
| build-b | b-c, b-d | b |
3. replace the auto-generated region in `rules.yml` with `labels`, and `rules`. Each mapping will generate a `rule` and all the required labels. `patterns` are pre-defined in `rules.yml` and could not be generated automatically. If a mapping is using a `pattern` undefined, the `pattern` will be ignored.
- If a mapping key has postfix `-preview`, no `if-protected-xxx` clause will be added
- else if a mapping key has postfix `-production`, an `if-protected-no_label` clause will be added
- else, an `if-protected` clause will be added
## Graph
All `label` nodes are in green, `pattern` nodes are in cyan, `rule` nodes are in blue
### Requirements
There are a few extra dependencies while generating the dependency tree graph, please refer to [pygraphviz](https://github.com/pygraphviz/pygraphviz/blob/master/INSTALL.txt) documentation to install both `graphviz` and `pygraphviz`
- git diff --exit-code -- ${IDF_TARGET}/esp_efuse_table.c || { echo 'Differences found for ${IDF_TARGET} target. Please run idf.py efuse-common-table and commit the changes.'; exit 1; }
- cd ${IDF_PATH}/components/efuse/test_efuse_host
- ./efuse_tests.py
test_efuse_table_on_host_esp32:
extends:.test_efuse_table_on_host_template
test_efuse_table_on_host_esp32s2:
extends:.test_efuse_table_on_host_template
variables:
IDF_TARGET:esp32s2
test_efuse_table_on_host_esp32s3:
extends:.test_efuse_table_on_host_template
variables:
IDF_TARGET:esp32s3
test_efuse_table_on_host_esp32c3:
extends:.test_efuse_table_on_host_template
variables:
IDF_TARGET:esp32c3
test_efuse_table_on_host_esp32h2:
extends:.test_efuse_table_on_host_template
variables:
IDF_TARGET:esp32h2
test_efuse_table_on_host_esp32c6:
extends:.test_efuse_table_on_host_template
variables:
IDF_TARGET:esp32c6
test_logtrace_proc:
extends:.host_test_template
artifacts:
when:on_failure
paths:
- tools/esp_app_trace/test/logtrace/output
- tools/esp_app_trace/test/logtrace/.coverage
expire_in:1week
script:
- cd ${IDF_PATH}/tools/esp_app_trace/test/logtrace
- ./test.sh
test_sysviewtrace_proc:
extends:.host_test_template
artifacts:
when:on_failure
paths:
- tools/esp_app_trace/test/sysview/output
- tools/esp_app_trace/test/sysview/.coverage
expire_in:1week
script:
- cd ${IDF_PATH}/tools/esp_app_trace/test/sysview
- ./test.sh
test_mkdfu:
extends:.host_test_template
variables:
LC_ALL:C.UTF-8
script:
- cd ${IDF_PATH}/tools/test_mkdfu
- ./test_mkdfu.py
test_autocomplete:
extends:
- .host_test_template
artifacts:
when:on_failure
paths:
- ${IDF_PATH}/*.out
expire_in:1week
script:
- ${IDF_PATH}/tools/ci/test_autocomplete.py
test_detect_python:
extends:
- .host_test_template
script:
- cd ${IDF_PATH}
- shellcheck -s sh tools/detect_python.sh
- shellcheck -s bash tools/detect_python.sh
- shellcheck -s dash tools/detect_python.sh
- "bash -c '. tools/detect_python.sh && echo Our Python: ${ESP_PYTHON?Python is not set}'"
- "dash -c '. tools/detect_python.sh && echo Our Python: ${ESP_PYTHON?Python is not set}'"
- "zsh -c '. tools/detect_python.sh && echo Our Python: ${ESP_PYTHON?Python is not set}'"
return`You are a helpful assistant that creates suggestions for single git commit message, that user can use to describe all the changes in their merge request.
Use git diff: {mrDiff} and users current commit messages: {mrCommitMessages} to get the changes made in the commit.
Output should be git commit message following the conventional commit format.
Output only git commit message in desired format, without comments and other text.
Do not include the closing statements ("Closes https://....") in the output.
Here are the strict rules you must follow:
- Avoid mentioning any JIRA tickets (e.g., "Closes JIRA-123").
- Be specific. Don't use vague terms (e.g., "some checks", "add new ones", "few changes").
- The commit message structure should be: <type><(scope/component)>: <summary>
- Types allowed: ${allowedTypes.join(", ")}
- If 'scope/component' is used, it must start with a lowercase letter.
- The 'summary' must NOT end with a period.
- The 'summary' must be between ${minimumSummaryChars} and ${maximumSummaryChars} characters long.
If a 'body' of commit message is used:
- Each line must be no longer than ${maximumBodyLineChars} characters.
- It must be separated from the 'summary' by a blank line.
`- correct format of commit message should be: \`<type/action>(<scope/component>): <summary>\`, for example \`fix(esp32): Fixed startup timeout issue\``,
`- allowed types are: \`${allowedTypes}\``,
`- sufficiently descriptive message summary should be between ${minimumSummaryChars} to ${maximumSummaryChars} characters and start with upper case letter`,
`- avoid Jira references in commit messages (unavailable/irrelevant for our customers)`,
`- follow this [commit messages guide](${process.env.DANGER_GITLAB_HOST}/espressif/esp-idf/-/wikis/dev-proc/Commit-messages)`,
];
letdangerMessage=`\n**Some issues found for the commit messages in this MR:**\n${issuesAllCommitMessages.join(
"\n"
)}
\n***
\n**Please consider updating these commit messages** - here are some basic tips:\n${basicTips.join(
"\n"
)}
\n\`TIP:\` You can install commit-msg pre-commit hook (\`pre-commit install -t pre-commit -t commit-msg\`) to run this check when committing.
\n***
`;
if(generateAISuggestion){
// Create AI generated suggestion for git commit message based of gitDiff and current commit messages
`- closing ticket \`${ticket.record}\` seems to be in the wrong format (or inaccessible to Jira DangerBot).. The correct format is for example \`- Closes JIRA-123\`.`
);
}
// Get closing GitHub issue links from JIRA tickets
`- the GitHub issue [\`${ticket.closingGithubLink}\`](${ticket.closingGithubLink}) does not seem to exist on GitHub (referenced from JIRA ticket [\`${ticket.ticketName}\`](${ticket.jiraUIUrl}) )`
);
continue;// skip the following checks
}
// Search in commit message if there are all GitHub closing links (from Related section) for still open GH issues
:"";// if the Jira ticket has an unfilled Description, the ".description" property is missing in API response - in that case set "jiraDescription" to an empty string
constdescriptionChunk=mrDescription.match(/^([^#]*)/)[1].trim();// Extract all text before the first section header (i.e., the text before the "## Release notes")
constshortMrDescriptionThreshold=50;// Description is considered too short below this number of characters
returnwarn(`The \`Release Notes\` section seems to be missing. Please check if the section header in MR description is present and in the correct markdown format ("## Release Notes").\n\nSee [Release Notes Format Rules](${wiki_link}).`);
error_output.push('`No release notes` comment shows up when there is valid entry. Remove bullets before comments in release notes section.');
}
}else{
if(!valid_entries_found){
error_output.push('The `Release Notes` section seems to have no valid entries. Add bullets before valid entries, or add `No release notes` comment to suppress this error if you mean to have no release notes.');
}
}
if(error_output.length>0){
// Paragraphs joined by double `\n`s.
error_output=[...error_output,`See [Release Notes Format Guide](${wiki_link}).`].join('\n\n');
recordRuleExitStatus(ruleName,"Failed");
returnwarn(error_output);
}
// At this point, the rule has passed
recordRuleExitStatus(ruleName,'Passed');
};
functioncheck_entry(entry){
constentry_str=`- \`${entry}\``;
constindent=" ";
if(entry.match(/no\s+release\s+note/i)){
return[entry_str,`${indent}- \`No release notes\` comment shouldn't start with bullet.`].join('\n');
}
// Remove a leading escaping backslash of the special characters, https://www.markdownguide.org/basic-syntax/#characters-you-can-escape
return[entry_str,`${indent}- Please specify the [area] to which the change belongs (see guide). If this line is just a comment, remove the bullet.`].join('\n');
}
// area is in match[2]
constdescription=match[3].trim();
letviolations=[];
if(match[1]){
violations.push(`${indent}- Release note entry should start from the beginning of line. (Nested release note not allowed.)`);
}
if(!/^[A-Z0-9]/.test(description)){
violations.push(`${indent}- Release note statement should start with a capital letter or digit.`);
constdocsFilesMR=parseMrDocsFiles(allMrFiles);// Create single object of all doc files in MR with names, paths and groups
// Both versions (EN and CN) of document found changed in this MR
for(constfileofdocsFilesMR.bothFilesInMr){
file.contentEn=awaitgetContentFileInMR(file.fileEnPath);// Get content of English file
file.linesEn=file.contentEn.split("\n").length;// Get number of lines of English file
file.contentCn=awaitgetContentFileInMR(file.fileCnPath);// Get content of Chinese file
file.linesCn=file.contentCn.split("\n").length;// Get number of lines of English file
// Compare number of lines in both versions
if(file.linesEn!==file.linesCn){
// Check if CN file is only link to EN file
if(!regexIncludeLink.test(file.contentCn)){
// if not just a link ...
partMessages.push(
`- please synchronize the EN and CN version of \`${file.fileName}\`. [\`${file.fileEnPath}\`](${file.fileUrlRepoEN}) has ${file.linesEn} lines; [\`${file.fileCnPath}\`](${file.fileUrlRepoCN}) has ${file.linesCn} lines.`
);
}
}
}
// Only Chinese version of document found changed in this MR
for(constfileofdocsFilesMR.onlyCnFilesInMr){
partMessages.push(
`- file \`${file.fileEnPath}\` doesn't exist in this MR or in the GitLab repo. Please add \`${file.fileEnPath}\` into this MR.`
);
}
// Only English version of document found in this MR
for(constfileofdocsFilesMR.onlyEnFilesInMr){
consttargetBranch=danger.gitlab.mr.target_branch;
file.contentCn=awaitgetContentFileInGitlab(
file.fileCnPath,
targetBranch
);// Try to fetch CN file from target branch of Gitlab repository and store content
if(file.contentCn){
// File found on target branch in Gitlab repository
if(!regexIncludeLink.test(file.contentCn)){
// File on Gitlab master is NOT just an ..include:: link to ENG version
`- file \`${file.fileCnPath}\` was not updated in this MR, but found unchanged full document (not just link to EN) in target branch of Gitlab repository [\`${file.fileCnPath}\`](${file.fileUrlRepoMasterCN}). Please update \`${file.fileCnPath}\` into this MR.`
);
}
}else{
// File failed to fetch, probably does not exist in the target branch
partMessages.push(
`- file \`${file.fileCnPath}\` probably doesn't exist in this MR or in the GitLab repo. Please add \`${file.fileCnPath}\` into this MR.`
);
}
}
// Create a report with found issues with documents in MR
createReport();
// At this point, the rule has passed
recordRuleExitStatus(ruleName,'Passed');
/**
* Generates an object that represents the relationships between files in two different languages found in this MR.
*
* @param {string[]} docsFilesEN - An array of file paths for documents in English.
* @param {string[]} docsFilesCN - An array of file paths for documents in Chinese.
* @returns {Object} An object with the following properties:
* - bothFilesInMr: An array of objects that represent files that found in MR in both languages. Each object has the following properties:
* - fileName: The name of the file.
* - fileEnPath: The path to the file in English.
* - fileCnPath: The path to the file in Chinese.
* - fileUrlRepoEN: The URL link to MR branch path to the file in English.
* - fileUrlRepoCN: The URL link to MR branch path to the file in Chinese.
* - onlyCnFilesInMr: An array of objects that represent files that only found in MR in English. Each object has the following properties:
* - fileName: The name of the file.
* - fileEnPath: The path to the file in English.
* - fileCnPath: The FUTURE path to the file in Chinese.
* - fileUrlRepoEN: The URL link to MR branch path to the file in English.
* - fileUrlRepoCN: The URL link to MR branch path to the file in Chinese.
* - onlyEnFilesInMr: An array of objects that represent files that only found in MR in Chinese. Each object has the following properties:
* - fileName: The name of the file.
* - fileEnPath: The FUTURE path to the file in English.
* - fileCnPath: The path to the file in Chinese.
* - fileUrlRepoEN: The URL link to MR branch path to the file in English.
* - fileUrlRepoCN: The URL link to MR branch path to the file in Chinese.
constfileContentAfter=content.after.trim();// Trim trailing new lines
returnfileContentAfter;
}catch(error){
console.error(`Error while getting file content MR: ${error}`);
returnnull;
}
}
/**
* Creates a compiled report for found documentation issues in the current MR and alerts the Documentation team if there are any "needs translation" labels present.
*
* Report if documentation labels have been added by mistake.
*/
functioncreateReport(){
constmrLabels=danger.gitlab.mr.labels;// Get MR labels
`Please remove the \`needs translation: XX\` labels. For documents that need to translate from scratch, Doc team will translate them in the future. For the current stage, we only focus on updating exiting EN and CN translation to make them in sync.`
);
}
// Docs issues found in this MR
partMessages.sort();
letdangerMessage=`Some of the documentation files in this MR seem to have translations issues:\n${partMessages.join(
"\n"
)}\n`;
if(partMessages.length){
if(!translationLabelsPresent){
dangerMessage+=`
\nWhen synchronizing the EN and CN versions, please follow the [Documentation Code](https://docs.espressif.com/projects/esp-idf/zh_CN/latest/esp32/contribute/documenting-code.html#standardize-document-format). The total number of lines of EN and CN should be same.\n
\nIf you have difficulty in providing translation, you can contact Documentation team by adding <kbd>needs translation: CN</kbd> or <kbd>needs translation: EN</kbd> labels into this MR and retrying Danger CI job. The documentation team will be automatically notified and will help you with the translations before the merge.\n`;
recordRuleExitStatus(ruleName,"Failed");
returnwarn(dangerMessage);// no "needs translation: XX" labels in MR; report issues as warn
}else{
dangerMessage+=`\nTranslation labels <kbd>needs translation: CN</kbd> or <kbd>needs translation: EN</kbd> were added - this will automatically notify the Documentation team to help you with translation issues.`;
`The source branch name \`${sourceBranch}\` contains more than one slash. This can cause troubles with git sync. Please rename the branch.`
);
}
// Check if the source branch name contains any uppercase letters
if(sourceBranch!==sourceBranch.toLowerCase()){
recordRuleExitStatus(ruleName,"Failed");
returnwarn(
`The source branch name \`${sourceBranch}\` contains uppercase letters. This can cause troubles on case-insensitive file systems (macOS). Please use only lowercase letters.`
_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/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests>`_.
Before Contributing
-------------------
Before sending us a Pull Request, please consider this list of points:
* Is the contribution entirely your own work, or already licensed under an Apache License 2.0 compatible Open Source License? If not then we unfortunately cannot accept it.
* Does any new code conform to the esp-idf :doc:`Style Guide <style-guide>`?
* Does the code documentation follow requirements in :doc:`documenting-code`?
* Is the code adequately commented for people to understand how it is structured?
* Is there documentation or examples that go with code contributions? There are additional suggestions for writing good examples in :idf:`examples` readme.
* Are comments and documentation written in clear English, with no spelling or grammar errors?
* Example contributions are also welcome. Please check the :doc:`creating-examples` guide for these.
* If the contribution contains multiple commits, are they grouped together into logical changes (one major change per pull request)? Are any commits with names like "fixed typo" `squashed into previous commits <https://eli.thegreenplace.net/2014/02/19/squashing-github-pull-requests-into-a-single-commit/>`_?
* If you're unsure about any of these points, please open the Pull Request anyhow and then ask us for feedback.
Pull Request Process
--------------------
After you open the Pull Request, there will probably be some discussion in the comments field of the request itself.
Once the Pull Request is ready to merge, it will first be merged into our internal git system for in-house automated testing.
If this process passes, it will be merged onto the public github repository.
Legal Part
----------
Before a contribution can be accepted, you will need to sign our :doc:`contributor-agreement`. You will be prompted for this automatically as part of the Pull Request process.
- Please read [the support policy](SUPPORT_POLICY.md) and [the documentation](https://docs.espressif.com/projects/esp-idf/en/latest/esp32/versions.html) for more information about ESP-IDF versions.
- Please see the [End-of-Life Advisories](https://www.espressif.com/en/support/documents/advisories?keys=&field_type_of_advisory_tid%5B%5D=817) for information about ESP-IDF releases with discontinued support.
# ESP-IDF Release and SoC Compatibility
The following table shows ESP-IDF support of Espressif SoCs where ![alt text][preview] and ![alt text][supported] denote preview status and support, respectively. The preview support is usually limited in time and intended for beta versions of chips. Please use an ESP-IDF release where the desired SoC is already supported.
There are variants of revisions for a series of chips. See [Compatibility Between ESP-IDF Releases and Revisions of Espressif SoCs](https://github.com/espressif/esp-idf/blob/master/COMPATIBILITY.md) for the details of the compatibility between ESP-IDF and chip revisions.
Espressif SoCs released before 2016 (ESP8266 and ESP8285) are supported by [RTOS SDK](https://github.com/espressif/ESP8266_RTOS_SDK) instead.
ESP-IDF is the development framework for Espressif SoCs (released after 2016<sup>[1](#fn1)</sup>) provided for Windows, Linux and macOS.
# Developing With ESP-IDF
@@ -43,9 +14,11 @@ See https://idf.espressif.com/ for links to detailed instructions on how to set
### Non-GitHub forks
ESP-IDF uses relative locations as its submodules URLs ([.gitmodules](.gitmodules)). So they link to GitHub. If ESP-IDF is forked to a Git repository which is not on GitHub, you will need to run the script [tools/set-submodules-to-github.sh](tools/set-submodules-to-github.sh) after git clone.
The script sets absolute URLs for all submodules, allowing `git submodule update --init --recursive` to complete. If cloning ESP-IDF from GitHub, this step is not needed.
ESP-IDF uses relative locations as its submodules URLs ([.gitmodules](.gitmodules)). So they link to GitHub.
If ESP-IDF is forked to a Git repository which is not on GitHub, you will need to run the script
[tools/set-submodules-to-github.sh](tools/set-submodules-to-github.sh) after git clone.
The script sets absolute URLs for all submodules, allowing `git submodule update --init --recursive` to complete.
If cloning ESP-IDF from GitHub, this step is not needed.
## Finding a Project
@@ -92,7 +65,7 @@ You don't need to run `idf.py build` before running `idf.py flash`, `idf.py flas
## Viewing Serial Output
The `idf.py monitor` target uses the [esp-idf-monitor tool](https://github.com/espressif/esp-idf-monitor) to display serial output from Espressif SoCs. esp-idf-monitor also has a range of features to decode crash output and interact with the device. [Check the documentation page for details](https://docs.espressif.com/projects/esp-idf/en/latest/get-started/idf-monitor.html).
The `idf.py monitor` target uses the [idf_monitor tool](https://docs.espressif.com/projects/esp-idf/en/latest/get-started/idf-monitor.html) to display serial output from Espressif SoCs. idf_monitor also has a range of features to decode crash output and interact with the device. [Check the documentation page for details](https://docs.espressif.com/projects/esp-idf/en/latest/get-started/idf-monitor.html).
Exit the monitor by typing Ctrl-].
@@ -113,18 +86,21 @@ After the initial flash, you may just want to build and flash just your app, not
## Erasing Flash
The `idf.py flash` target does not erase the entire flash contents. However it is sometimes useful to set the device back to a totally erased state, particularly when making partition table changes or OTA app updates. To erase the entire flash, run `idf.py erase-flash`.
The `idf.py flash` target does not erase the entire flash contents. However it is sometimes useful to set the device back to a totally erased state, particularly when making partition table changes or OTA app updates. To erase the entire flash, run `idf.py erase_flash`.
This can be combined with other targets, ie `idf.py -p PORT erase-flash flash` will erase everything and then re-flash the new app, bootloader and partition table.
This can be combined with other targets, ie `idf.py -p PORT erase_flash flash` will erase everything and then re-flash the new app, bootloader and partition table.
# Resources
* Documentation for the latest version: https://docs.espressif.com/projects/esp-idf/. This documentation is built from the [docs directory](docs) of this repository.
* [Beginner's Guide to Key Concepts and Resources of ESP-IDF](https://youtu.be/J8zc8mMNKtc?feature=shared)
* The [esp32.com forum](https://esp32.com/) is a place to ask questions and find community resources.
* [Check the Issues section on github](https://github.com/espressif/esp-idf/issues) if you find a bug or have a feature request. Please check existing Issues before opening a new one.
* If you're interested in contributing to ESP-IDF, please check the [Contributions Guide](https://docs.espressif.com/projects/esp-idf/en/latest/contribute/index.html).
________
<a name="fn1">1</a>: ESP8266 and ESP8285 are not supported in ESP-IDF. See [RTOS SDK](https://github.com/espressif/ESP8266_RTOS_SDK) instead.
Please refer to https://docs.espressif.com/projects/esp-idf/en/latest/esp32/versions.html#support-periods for more details on ESP-IDF supported versions and support period policy.
## Reporting a Vulnerability
Please refer to [Espressif Security Incident Response Process](https://www.espressif.com/sites/default/files/Espressif%20Security%20Incident%20Response%20Process%20v1.0_EN.pdf) on the guidelines to report a security vulnerability. Please do **NOT** create a public GitHub issue.
Each ESP-IDF major and minor release (V4.1, V4.2, etc) is supported for 30 months after the initial stable release date.
Each ESP-IDF major and minor release (V4.0, V4.1, etc) is supported for
18 months after the initial stable release date.
Supported means that the ESP-IDF team will continue to apply bug fixes, security fixes, etc to the release branch on GitHub, and periodically make new bugfix releases as needed.
Supported means that the ESP-IDF team will continue to apply bug fixes,
security fixes, etc to the release branch on GitHub, and periodically
make new bugfix releases as needed.
Support period is divided into "Service" and "Maintenance" period:
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.
| Period | Duration | Recommended for new projects? |
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.
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.)
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 Maintenance period, the version is still supported but only bugfixes for high severity issues or security issues will be applied.
Long Term Support releases
--------------------------
Using an “In Service” version is recommended when starting a new project.
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.
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.
