When the virt efuse mode is on and psram is on as well
then efuse buffer is not filled by efuses (it is filled by 0).
So the psram init func gets wrong pkg_ver = 0.
Closes https://github.com/espressif/esp-idf/issues/10925
Close IDFGH-9576
When release sdkconfig is set, substract_poison_overhead() is not inlined
and called from IRAM in multi_heap_get_allocated_size(). By wlways inlining
substract_poison_overhead(), we assure that this problem will not happen.
heap: Fix erroneous value returned by heap_caps_get_allocated_size() when poisoning is enabled (backport v4.3)
See merge request espressif/esp-idf!22190
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
When light (or comprehensive) poisoning is enabled, the size requested by the user for allocation
is extended by a few bytes to store the canary header and footer. heap_caps_get_allocated_size() should
return the original size asked by the user (without the additional canary bytes).
test_malloc.c extended with a new test assuring that heap_caps_get_allocated_size() returns the proper size
regardless of the degree of poisoning.
When stack check is enabled, certain functions (sometimes placed in RAM)
are being decorated with stack guards and a call to __stask_chk_fail() in
case ofr stack corruption. For this reason, __stack_chk_fail() must be
placed in RAM too.
Add stack check config in heap tests on all targets to find eventual flash to RAM
calls due to stack checks when running callgraph_check.py
On xtensa architecture, the call to __assert_func uses a reference to __func__ that can
sometimes be placed in flash. Since the __asert_func can be called from functions in IRAM
the check_callgraph script can report an error when checking for invalid calls from IRAM
to flash sections. However, the __asert_func prevents this scenario at runtime so the
check_callgraph script reports a 'flas positive' situation. For this reasson, all references
to __func__$x found prior to a call to __assert_func are droped in the parsing of the rtl files.
this commits:
- adds build-time test to check that no call to flash regions are done from IRAM functions
- resolves problems related to IRAM function using content in flash memory
- update heap_caps_alloc_failed to use a default function name in DRAM
when necessary instead of creating a function name variable in DRAM for
each call of heap_caps_alloc_failed. This allows to save some extra bytes
in RAM.
This commits adds a internal.md file in the heap directory to clarify the idea behind
which functions is placed in IRAM or in flash.
A section in mem_alloc.rst documentation is added to specify which functions from the
heap component API can be used in interrupt handlers.
This commit aims to place in the IRAM section only the functions that
are relevent for performance instead of placing the entire content of
multi_heap.c, mullti_heap_poisoning.c and tlsf.c in the IRAM.
The calculation of fl index max is changed to always be the smallest
number that includes the size of the registered memory.
The control_construct() function now checks for minimum size as the control structure
parameters are calculated.
There is no longer a minimum configuration for fl index max so the tlsf_config
enum is striped down to remove unecessary compile time values.
the tlsf_size() function will fail if no tlsf pointer is passed as parameter since there
is no way to calculate a default tlsf size anymore.
bitfields are now used in control_t when possible which reduces the size of the structure
from 56 bytes to 36 bytes.
When SECURE BOOT V2 is enabled and CONFIG_SECURE_BOOT_SIGNED_BINARIES
is not set, sector-pad the bootloader image, which is required for an
external PKCS#11 interface to generate a signature.
esptool_py: Update submodule to release/v3 (4bc311767b7c6df41def6f95a50f87b1c9406cbd)
Before this fix, when we call esp_pm_configure after gpio_wakeup_enable,
the configuration of GPIO in sleep state in gpio_wakeup_enable will be
overwritten by esp_pm_configure.
mktime function uses tm_isdst member as an indicator whether the time
stamp is expected to be in daylight saving time (1) or not (0).
FAT filesystem uses local time as mtime, so no information about DST
is available from the filesystem.
According to mktime documentation, tm_isdst can be set to -1, in which
case the C library will try to determine if DST was or wasn't in
effect at that time, and will set UTC time accordingly.
Note that the conversion from UTC to local time and then back to UTC
(time_t -> localtime_r -> FAT timestamp -> mktime -> time_t) does not
always recover the same UTC time. In particular, the local time in the
hour before DST comes into effect can be interpreted as "before DST"
or "after DST", which would correspond to different UTC values. In
this case which option the C library chooses is undefined.
Closes https://github.com/espressif/esp-idf/issues/9039
Originally reported in https://github.com/espressif/arduino-esp32/issues/6786
1. fix ftm timer macro issue
2. send null data when state change from association to run
3. bugfix for optimize abnormal beacon log
4. bugfix RSNXE related changes
5. send ftm frames immediately
6. fix ftm procedure with peer failed status 4 issue
For Secure Boot v2 case, unsigned image is first padded to next 64K
aligned boundary and then a signature block of 4K gets appended. Thus
an app partition whose size is 4K aligned should be allowed here.
For Secure Boot v1 case, app partition size must be 64K aligned as the
signature block lies at the very end of 64K boundary.
Relevant:
57b601ab7f
- If internet connectivity weakened or disappeared suddenly while we were
in the TLS handshake stage, the app got stuck at that point indefinitely.
- This was because when timeout was not explicitly specified in esp_tls_cfg_t,
the default timeout was set at the wrong place. This causes the sockets to be
setup with zero timeout, hence the indefinite wait.
- 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
- 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
- Fixed some memory was not released after bluetooth controller initialization failed
- Fixed privacy errorr for directed advertising
- Fixed multiple periodic advertising sync failed in air
- Fixed lld_con.c line 3048 assert
- Fixed crash sometimes when connected as a slave by the 8th device
1 change default TX power to 9 dBm
2 fixed disconnect reason 0x1f (unspecified error)
3 fixed connection timeout due to terminate ind has not been acknowledged
1.wifi: fixed sniffer mode can not capture control packet when station is enabled
2.Fixed WAPI issue on GTK compability and reference to broadcast arp pkts.
3.Fixed TX fragment issue that PN code is less than MSDU after PN code add two for TX fragment.
4.Added station connect retry count to make it easier to connect to the except AP
5.Fixed some issues on Soft-AP power save.
6.Fixed SoftAP memory leak after wifi init and deinit
7.Fixed sta get ap info does not return connected ssid issue.
8.Fixed SoftAP disconnection happened even when receive PS-Poll.
Bluetooth low power related logic and regs have separate power domain from MAC and BB,
and do not power down during light sleep. If reset when power up MAC and BB in sleep
flow, it may destroy the state of bt low power part.
By default, disabled the BLE Encrpyption requirement for provisioning characteristic.
With this flag enabled, when remote attempts to read and if the ACL link is not encrypted,
ESP device will return Insufficient Authentication. It is remote device responsibility to go
for link encryption which may result in pairing.
Some devices do not proceed for any pairing and just show failure pop-up. Also, user needs
to remove bonding on remote phone manually and then try again. This is causing bad user experience.
End user can enable it as per their use case.
- Added config to disable scan backoff
- Fixed llm_scan.c assert at line 1485 during controller deinit if duplicate scan is not stopped
- Call pll track in controller task
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.
Since cpu retention dma use rc fast as clk source, so rc_fast_digi
will be enabled when we config to pd cpu. And cpu retention does not
need rc fast keep on during light sleep. So, if we use rc_fast_digi
to determine whether rc fast can be powered down, then cpu and and
rc fast cannot pd at the same time.
introduced in e44ead5356
1. The int8M power domain config by default is PD. While LEDC is using
RTC8M as clock source, this power domain will be kept on.
But when 8MD256 is used as RTC clock source, the power domain should
also be kept on.
On ESP32, there was protection for it, but broken by commit
e44ead5356. Currently the power domain
will be forced on when LEDC is using RTC8M as clock source &&
!int8m_pd_en (user enable ESP_PDP_DOMAIN_RTC8M in lightsleep). Otherwise
the power domain will be powered off, regardless of RTC clock source.
In other words, int8M domain will be forced off (even when 8MD256
used as RTC clock source) if LEDC not using RTC8M as clock source, user
doesn't enable ESP_PDP_DOMAIN_RTC8M, or in deep sleep.
On later chips, there's no such protection, so 8MD256 could't be used as
RTC clock source in sleep modes.
This commit adds protection of 8MD256 clock to other chips. Fixes the
incorrect protection logic overriding on ESP32. Now the power domain
will be determiend by the logic below (order by priority):
1. When RTC clock source uses 8MD256, power up
2. When LEDC uses RTC8M clock source, power up
3. In deepsleep, power down
4. Otherwise determined by user config of ESP_PDP_DOMAIN_RTC8M,
power down by default. (This is preferred to have highest
priority, but it's kept as is because of current code structure.)
2. Before, after the macro `RTC_SLEEP_CONFIG_DEFAULT` decides dbias, the
protection above may force the int8m PU. This may cause the inconsistent
of dbias and the int8m PU status.
This commit lifts the logic of pd int8m/xtal fpu logic to upper layer
(sleep_modes.c).
Related: https://github.com/espressif/esp-idf/issues/8007, https://github.com/espressif/esp-idf/pull/8089
temp
bluetooth: use non-blocking coexistence callback functions so that Wi-Fi task is not blocked by Bluetooth(backport v4.3)
See merge request espressif/esp-idf!20780
light sleep wakeup flag is true to indicate the most recent successful wakeup from light sleep,
which means the most recent light sleep occurred successfully and then wakes up by wakeup source
1. Deinit does not return ESP_ERR_WIFI_NOT_INIT if the wifi driver is no longer initialized.
2. Fix get wrong channel value use esp_wifi_get_config.
3. Fix bug of missing unlock when wifi stop.
4. Fix annotation error of api esp_wifi_connect.
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.3)
See merge request espressif/esp-idf!19693
27eb4726067465c5c67d4ecdca5ddccd26f02580..60983d1dd54196b1e3f399c6f928d77256ec742a
Detailed description of the changes:
* [Backport] mqtt_client: fix esp_mqtt_client_enqueue for len=0
- See merge request espressif/esp-mqtt!144
- mqtt_client: fix esp_mqtt_client_enqueue for len=0
(espressif/esp-mqtt@e918742)
- Fixed the usage of PLL track related baseband IRQs
- Fixed connect failed due to error sync found signal
- Fixed BLE disconnect failed due to terminate_ind have sent but no ACK is received
- Added ADV mode error check in ADV rx isr handler function
- Fixed BLE RAL_UNDERRUN and TX_CRYPT_ERR assert
- Disable scan continue
- Fixed scan forever if scan continue is disable
- Fixed BLE disconnection issue when channel map update failed due to bad channels
ledc_ls_timer_update is required only when CLK_DIV and DUTY_RES bits are changed.
Calling ledc_timer_rst while re-configure PWM frequency through ledc_set_freq can cause glitch in the signal
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
Fix below build warning when CONFIG_OTA_ALLOW_HTTP is set:
esp_https_ota.c:165:13: warning: 'is_server_verification_enabled' defined but not used [-Wunused-function]
While at it, also simplify the is_server_verification_enabled logic.
Fixes: 48987ad9df ("esp_https_ota: Enable option of using global_ca_store and x509_crt_bundle")
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Closes https://github.com/espressif/esp-idf/pull/6882
Signed-off-by: Aditya Patwardhan <aditya.patwardhan@espressif.com>
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.
1. Fixed not update phy according to country code.
2. Fixed crashed when esp_wifi_set_ant_gpio() called
3. Fixed a bug when ftm used with ps enabled
4. Fixed a potential issue to allocate PSRAM to wifi stack where internal RAM is required
5. Fixed potential fail to scan AP after receiving disassoc/deauth from AP on esp32s2
y
The test in question is "performance test - no dedicated task".
Its performance dropped significantly during a WiFi library commit,
although there is no obvious reason. This needs to be investigated
and until then, we temporarily lower the performance threshold to
let the test pass.
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. bluedroid: use standard function pointer define.
2. blufi: Change ESP_BD_ADDR_LEN into ESP_BLUFI_BD_ADDR_LEN
3. doc/sphinx_known_warnings: Remove fixed parts.
There should be only one workqueue for BTU task. The queue length for the second workqueue of BTU can be uninitialized and caused memory overflow and corruption.
Closes https://github.com/espressif/esp-idf/issues/9507
1. Clear old keys before going for new connection
2. Fix deep sleep can't reconnect to ap when pmf enable
3. Fix some ap will ignore auth when rx deauth for some time
4. Support force ht40 for espnow & 80211_tx
5. WAPI: Key mgmt type compability issue
6. Update wifi header file
7. Fix espnow recv unencrypted packets issue
some fixes after modifications:
1. removed the use of waiting_command_t
2. fix assert for HCI write_eir command
3. fixed the crash upon handling command status event when trying to free to the HCI command buffer
4. fixed the issue in transmitting HCI vendor specific commands
5. fixed the lost command complete callbacks for HCI commands LE_RAND and LE_ENCRYPT
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.
1 Bugfix for wrong config of static txbuf
2 fix bug that qos data will update BA SSN
3 reset beacon timeout timer
4 Bugfix for close sniffer mode when wifi stop
5 update wifi header files
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()
This commit fixes the systimer_counter_value_t by adding a resreved field so that the
type fills 64-bits.
Without the reserved field, when compiling with -O0 optimization, the unoccupied high
bits would not be initalized by the compiler, leading to systimer_hal_get_counter_value()
returning a garbage value.
The following functions are only defined when CONFIG_PM_ENABLE is defined:
- wifi_apb80m_request()
- wifi_apb80m_release()
This commit makes their linker script mapping statements also dependent on CONFIG_PM_ENABLE
thus fixing some linker errors when CONFIG_PM_ENABLE is disabled.
1. Rename MACROs SYSTEM_WIFI_RST_EN register bit fields to be more recognizable
2. reset Bluetooth baseband and MAC bits to fix the issue of task watchdog triggered during controller initialization due to invalid hardware state
Idle tick hook that indicates completion of scheduler init must be launched
on other core than the one where main task runs. Earlier it was assumed that
main task shall always run on PRO cpu but that behavior can be changed with
ESP_MAIN_TASK_AFFINITY_CPU1 and hence this fix.
Closes https://github.com/espressif/esp-idf/issues/9247
Closes IDFGH-7705
On riscv core, core cycle counter counts the clock cycles only when core is active (not sleeping).
In spi_slave/sender example, it uses ccount (core cycle counter) to do a simple debounce.
Therefore, when using spi_slave/sender and spi_slave/receiver, program will be stuck.
This commit fix this issue by using esp_timer
(cherry picked from commit afe3bfe19f)
The Xtensa FreeRTOS port does not save the threadptr register when
doing a voluntary yield. This can result in a crash when multiple
tasks used the threadptr register and call "taskYIELD()".
This commit adds the threadptr register to the solicited stack frame.
The change fixes thread-local-storage size by removing .srodata section
from it. It initially was included in TLS section by mistake.
The issue was found when stack size increased after building applications
with GCC-11.1 compiler. Stack size became bigger because some new data
appeared in .srodata. See more details here:
adce62f53d
This fixes the issue where multiline strings and strings with delimiters inside the nvs input csv file were incorrectly parsed, and adds back the ability to add comment lines anywhere in the CSV file.
The issue stems from the move away from the python built in csv module to manual parsing, which was made after moving away from using the csv module to parse mfg data.
This reverts back to using the csv module for parsing and writing csv data in both mfg_gen and nvs_partition_gen, fixes the original issue in mfg_gen and improves code quality which makes the code more readable and maintainable.
Closes https://github.com/espressif/esp-idf/issues/7175
This fixes a potential race condition in select() if both a socket-fd
and non-socket fd trigger simultaneously to unblock this select.
In case of both fds, we use lwip's local thread semaphore, so we only
have to try return it (if it was taken/triggered more than once) when
we exit select().
Closes https://github.com/espressif/esp-idf/issues/8896
Refactor examples to build with MBEDTLS_CERTIFICATE_BUNDLE disabled. Only examples
that can work with certificate bundle disabled have been modified here.
Purpose:
This will allow for easily automating periodic updates to
"cacrt_all.pem" file.
Note:
For now newly created "cacrt_local.pem" contains single "DST Root CA X3"
which we are keeping to manage compatibility with endpoints like
"howsmyssl.com". Please note this Root CA is expired and is not part of
Mozilla’s NSS root certificate store.
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
Bluetooth: disable PLL track function for ESP32-C3/ESP32-S3 as it introduced coexistence issues(bacport v4.3)
See merge request espressif/esp-idf!18140
fix(server): Fix websocket server not support handle multiple connections when client send CLOSE frame (backport v4.3)
See merge request espressif/esp-idf!18019
Prior to this change "esp_wifi_clear_default_wifi_driver_and_handlers"
will not remove netif pointer from table when both AP and STA interfaces were
created and destroying default wifi interfaces is done in unfortunate
order. As a result there is dangling pointer left and it may cause crash in
later code (i.e. when esp_wifi_stop() is called).
mask_get_id and gpio_hal_iomux_func_sel were called while cache
is disabled, but were not inlined as expected at -0O.
Force these functions to always be inlined.
While using esp_wifi_set_config, flag pmf_capable defaults to 0.
Users may not bother to enable it, which prevents connection to a
WPA3 AP. Or the AP may reset into WPA3 mode failing the re-connection.
To ensure better security, deprecate the pmf_capable flag and set it to
true internally.
Update wifi lib with below fixes -
1. In FTM Responder, add session timer for cleanup, also remove
unnecessary mutex locks
2. In FTM Responder, fix incorrect print in case of failure
while setting up the SofTAP
2. In FTM Initiator, increase FTM Request response timeout to
avoid failures in noisy environments
3. In FTM Initiator, abort for high start delta time, also fix
timeout issue in ASAP mode
* Cherry-pick important fixes to 2.1.2-esp
- CVE-2020-22283: Attacker could craft a packet that would disclose 8 bytes of some heap memory:
- icmp6: Don't copy too much data
- icmp6: Fix copying of chained pbuf in reply
- icmp6: keep to the RFC and send as much as possible with icmp6 error messages
- CVE-2020-22284: ZEP - ZigBee Encapsulation Protocol/6LoWPAN is not supported in IDF,
the netif module (zepif.c) is not included in the build, but users can still inject
the file into compilation process, implement IO interface and use this.
- zepif: Copy possibly chained output pbuf properly
- Add #define for minimum IPv6 MTU length
- pbuf: Add pbuf_copy_partial_pbuf library function
* PPPoS: Fix null-deref when processing double break packet
- pppos: fix in_tail null (espressif/esp-lwip@537c69d5)
- PPP: Add test exhibiting empty packet null-deref (espressif/esp-lwip@202a07da)
* NAPT: Fix PBUF_REF type to clone the pbuf before forwarding
- IP-FORWARD: If packet-type is PBUF_REF clone it before forwarding
- Add NAPT unit test to exercise NAT feature for both RAM and REF pbuf types
* version: Update version numbers to match 2.1.2-esp
* Minor fixes listed below: Fix client receive KOD, NAPT fixes, restore
dhcp_cb, sntp docs, vendor class id (disabled)
* Update submodule: 2195f7416f...76303df238
Detailed description of the changes:
- test/napt: Add unit test for IP forward with PBUF_REF (espressif/esp-lwip@76303df2)
- napt: Fix PBUF_REF type to clone the pbuf before forwarding (espressif/esp-lwip@39068263)
- version: Update version numbers to match 2.1.2-esp (espressif/esp-lwip@2b922919)
- pppos: fix in_tail null (espressif/esp-lwip@537c69d5)
- PPP: Add test exhibiting empty packet null-deref (espressif/esp-lwip@202a07da)
- pbuf: Add pbuf_copy_partial_pbuf library function (espressif/esp-lwip@1c9cd9c1)
- Add #define for minimum IPv6 MTU length (espressif/esp-lwip@d2dc577b)
- zepif: Copy possibly chained output pbuf properly (espressif/esp-lwip@64ab7f2a)
- icmp6: Don't copy too much data (espressif/esp-lwip@4a64731b)
- icmp6: Fix copying of chained pbuf in reply (espressif/esp-lwip@7c822ff4)
- icmp6: keep to the RFC and send as much as possible with icmp6 error messages (espressif/esp-lwip@29100ab6)
- dns: Add API to clear dns cache (espressif/esp-lwip@ee59f77d)
- CI: Fixed adding gitlab key (espressif/esp-lwip@5a2bdba7)
- test case: modify test case test_tcp_new_max_num_remove_FIN_WAIT_1 (espressif/esp-lwip@6b090f7d)
- add function for deinit lwip timers (espressif/esp-lwip@2749568f)
- dhcp: Fix build issue that set ESP_DHCP_DISABLE_VENDOR_CLASS_IDENTIFIER to true will build fail (espressif/esp-lwip@d827dbf7)
- Document that sntp_setservername doesn't copy the string (espressif/esp-lwip@54acdb59) #6786
- lwip/dhcp: add 60 option for vendor class identify (espressif/esp-lwip@ae7edc2a) espressif/esp-lwip#32
- dhcp: Restore dhcp_cb on restart after dhcp_release_and_stop() (espressif/esp-lwip@55ea9d9c) #7217
- napt: Fix disbale IPv6 and enable NAPT will build error (espressif/esp-lwip@74cf7f9f)
- napt: fix checksum of UDP (espressif/esp-lwip@bb63eed1)
- sntp: Fix client receive KOD packet that make pool MEMP_SYS_TIMEOUT not be freed (espressif/esp-lwip@1c1642fe)
- test case: add tcp state and reset test cases. (espressif/esp-lwip@67deb805)
Closes https://github.com/espressif/esp-idf/issues/8300
Closes https://github.com/espressif/esp-idf/issues/8451
1. fix(pp): fix fragment plt loss when 2td pn compare with 1th pn
2. pmf allow keyindex in big endian format to workaround faulty APs
3. docs: update miswritten and abbreviated words and syntax errors for initialize WiFi section in esp_wifi.h header file
4. allow for minimal scope of wifi_init_config_t
5.compute packet length use lldesc length instead rx_ctl sig_len for sniffer
These were called from IRAM context where the caller expect them to be inlined
and accessible when cache is disabled. This was not the case when compiled with -O0.
Closes https://github.com/espressif/esp-idf/issues/8301
Closes https://github.com/espressif/esp-idf/issues/5571
Fix the bug that if the API was called from one core to free the interrupt source on the other core, it would trigger interrupt watchdog.
(cherry picked from commit 0e8286c57b)
- Check if pip is installed for sys.executable before attempting to
create the virtual environment, bail out with an error if not.
- Don't pass --seeder argument to virtualenv if its version is
too old. For example, on Ubuntu 18.04, virtualenv 15.1.0 doesn't
support this argument.
- Pass --python argument to virtualenv to request specific interpreter
to be used.
Closes https://github.com/espressif/esp-idf/issues/8045
Avoid adding one extra fade cycle when performing a one-time duty update.
Add some notes to ledc_get_duty and ledc_update_duty APIs, so that users
are aware of when the new duty will be effective.
Closes https://github.com/espressif/esp-idf/issues/7288
(cherry picked from commit e175086226)
...and all their callers.
With the upcoming switch from sizeof(time_t)==4 to sizeof(time_t)==8,
sizeof(struct stat) is also increasing.
A few newlib functions present in ROM allocate 'struct stat' on the
stack and call _fstat_r on this structure. The implementation of
fstat is provided in ESP-IDF. This implementation will often do
memset(st, 0, sizeof(*st)), where st is 'struct stat*', before setting
some fields of this structure. If IDF is built with sizeof(st)
different from sizeof(st) which ROM was built with, this will lead
to an out-of-bounds write and a stack corruption.
This commit removes problematic ROM functions from the linker script.
Here are the functions which allocate 'struct stat':
* _isatty_r (in ROM)
* __swhatbuf_r, called by __smakebuf_r, called by __swsetup_r and
__srefill_r (in ROM)
* _fseeko_r (not in ROM)
* glob2 (not in ROM)
* _gettemp (not in ROM)
As a result, these functions are used from libc.a, and use correct
size of 'stat' structure.
Closes https://github.com/espressif/esp-idf/issues/7980
Calling "open" in CHECK_AND_CALL sets a perfectly correct errno.
There is no need to overwrite that with a value of ENOENT, since doing
so hides lower level errors like EIO.
Closes https://github.com/espressif/esp-idf/pull/8036
- Fixed logs expecting different format specifier
- Updated ignore list for check_public_header test
- Updated functions ported from mbedTLS
- Fix for make-system build errors
- Removed code regarding MBEDTLS_DYNAMIC_FREE_PEER_CERT
(config was kept for backward compatibility)
- Combined mbedTLS v2.28.x related options under a separate Kconfig menu
For RISCV, backtrace generation on device is not possible without
including and parsing DWARF sections. We extract the crash task stack
and let the host generate the backtrace
- For the wifi_prov_mgr example in release mode (with NDEBUG defined -
assertions disabled), the task to stop provisioning is never started
as it is voided by the assert function it is called in.
Closes https://github.com/espressif/esp-idf/issues/8309
export PYTHONPATH="$IDF_PATH/tools:$IDF_PATH/tools/ci/python_packages"
python -m pip install -r $IDF_PATH/tools/ci/python_packages/ttfw_idf/requirements.txt
It helps to fix the ModuleNotFoundError issue with ttfw_idf and tiny_test_fw modules.
Closes https://github.com/espressif/esp-idf/issues/7815
CMake sorts result of file(GLOB) command since version 3.6.0:
https://gitlab.kitware.com/cmake/cmake/-/commit/edcccde7d
Since ESP-IDF sets cmake_minimum_required version to 3.5, and version
3.5.1 is used in CI, sort file lists obtained from file(GLOB)
manually.
This helps obtain reproducible order of libraries passed to the linker
and to ldgen.
Reason:
For example, if an url is lack of leading 'http:' by mistake, it causes to http_parser_parse_url() cannot parse http host item,
and then pass the null host pointer to _get_host_header(), crash happens.
Fix:
http added null pointer check now.
Closes https://jira.espressif.com:8443/browse/ESPAT-953
Updated MQTT submodule: git log --oneline f10321a53b53a146ee299cfecc320b89c0cf6611...89894bd0c611b1392967fe90bb49682eba858383
* Fix build issue if cert bundle disabled
* Fix build issue if ws transport disabled
* Add config to set retransmission interval
Detailed description of the changes (f10321a53b...89894bd0c6):
* Added config option to configure custom retransmission interval
- See merge request espressif/esp-mqtt!110
- esp_mqtt commit 1b009c840b
- Related https://github.com/espressif/esp-mqtt/pull/199
* Configuration conflicts were verified, logged but not reported to the user.
- See merge request espressif/esp-mqtt!102
- esp_mqtt commit 88f4b8ed50
* Fixed build issue if cert bundle disabled
- See merge request espressif/esp-mqtt!109
- esp_mqtt commit 4a89bff610
- esp_mqtt commit 1b71980575
- esp_mqtt commit 5b3c81ee48
- Related https://github.com/espressif/esp-mqtt/pull/198
- Related https://github.com/espressif/esp-idf/issues/7535
* Removes unnecessary outbox_cleanup
- This function were used on old version to handle QoS 2 messages. It's no longer necessary in current implementation.
- See merge request espressif/esp-mqtt!108
- esp_mqtt commit ebef896b00
* Fixed return an error when fail to enqueue
- The functions that enqueue messages didn't had a return for the handler, with this the error was only logged instead of returned whichmay cause the user to have an ID for a message that was not published.
- See merge request espressif/esp-mqtt!103
- esp_mqtt commit 7471177fe7
* CI: Use qemu image based on esp-env:v4.4-1
- Replaced the temporary qemu image with the official qemu:v4.4-1-20210517 derived from the esp-env:v4.4-1 test environment
- See merge request espressif/esp-mqtt!107
- esp_mqtt commit 231b274962
Closes https://github.com/espressif/esp-idf/issues/7535
time we can't find old device to be replaced,then this can cause crash. So we need
to change the way to malloc the new device or replace the old in the list.
ringbuf: Fix bug where comparision between a signed and unsigned operand resulted in incorrect free size for no-split/allow-split buffers (v4.3)
See merge request espressif/esp-idf!15882
Current issue: output reports sent by Windows not received.
The report characteristic declaration should also support write without
response as specified by HIDS profile:
See https://www.bluetooth.com/specifications/GATT/ (page 14)
This commit fixes a bug in no-split and allow-split ring buffers free buffer size calculation.
When the free size available in the buffers less than the size of one item header,
the function prvGetCurMaxSizeNoSplit/AllowSplit() incorrectly returned the maxItemSize instead of 0.
This is due to the comparision between a negative and a positive value
where both operands are treated as unsigned during the comparision operation,
thereby treating the negative operand as a large integer.
Also added new unit tests to test buffer-full and almost-full conditions
where this scenario is likely to be hit.
Closes https://github.com/espressif/esp-idf/issues/7344
Closes https://github.com/espressif/esp-idf/pull/7371
The previous SMP freertos round robin would skip over tasks when
time slicing. This commit implements a Best Effort Round Robin
where selected tasks are put to the back of the list, thus
makes the time slicing more fair.
- Documentation has been updated accordingly.
- Tidy up vTaskSwitchContext() to match v10.4.3 more
- Increased esp_ipc task stack size to avoid overflow
Closes https://github.com/espressif/esp-idf/issues/7256
This function resets the spinlock given as a parameter after taking it
(when entering the critical section). This then results in a panic once
it tries to exit the same critical section.
* Closes https://github.com/espressif/esp-idf/issues/7725
[Coexistence]: fixed BLE scannable extended adv performance issue in case of Wi-Fi coexistence(backport v4.3)
See merge request espressif/esp-idf!16477
This bugfix contains 3 fixes:
1. .rtc_dummy section is removed (not needed for C3)
2. .rtc_text section is padded with 16B for possible CPU prefetch
3. .rtc_text section is aligned to 4B boundary to comply with PMS Memprot requirements
1. Add conditions based on Kconfig options for functions which are
compiled based on those options.
2. Static allocation is always enabled, move corresponding functions
into the common list.
Since these functions receive the pointer to reent structure, they
should set errno in it rather than using thread-local errno.
This didn't cause practical issues because console functions in IDF
are only called from threads, and in that case 'r' is a pointer to
the thread-local structure, so &errno is the same thing as
&__errno_r(r). Still, fixing this for consistency.
When CONFIG_VFS_SUPPORT_IO is disabled, _read_r and _write_r
implementations in syscalls.c are used to provide console I/O via
esp_rom_uart_tx_one_char/esp_rom_uart_rx_one_char.
When newlib opens a (FILE*) stream, it calls fstat to check if the
underlying file is character-oriented. In this case, it configures the
stream to use line buffering. Otherwise (or if fstat fails) the stream
is opened as block buffered.
Since fstat wasn't provided, stdin/stdout/stderr streams got opened in
block buffered mode. For console, we need line buffered output so that
the stream buffer is flushed each time a complete line (ending with
'\n') is sent to stdout or stderr.
Fix by implementing _fstat_r stub, setting st->st_mdoe=S_IFCHR.
* Adds implementations of __{atomic,sync}_nand_fetch_n. These builtins
were implemented for other operations but were not defined for NAND.
* Adds implementation of __atomic_OP_fetch_n for all OPs.
* Adds implementation of __sync_OP_and_fetch_n for all OPs.
Reported in https://github.com/espressif/arduino-esp32/issues/5948
Add following bugfixes
1. Station not able to connect when WPS pin is pressed first on AP.
2. PBC overlap getting detected for selected registrar PIN APs.
3. Station not considering authorised MACs for PIN method.
4. For PIN methodm If no AP is found, station will loop through
APs in its vicinity and try to do WPS with them one by one till
WPS timeout occurs. This is for some APs which do not set
selected registrar correctly.
build ble_mesh_console example on c3 as well
add test dir examples/bluetooth/esp_ble_mesh/ble_mesh_console
add test dir examples/bluetooth/hci/controller_hci_uart_esp32
The release of the semaphore indicating the item was successfully sent must be the last semaphore released. The receiver may be in another task and may delete the Ringbuffer (such as with a return code across tasks design pattern) if they are through with the Ringbuffer.
The function xRingbufferSendAcquire followed by xRingbufferSendComplete had the semaphores released in the proper order and that same pattern should have been used in xRingbufferSend and xRingbufferSendFromISR. This commit fixes this order.
Issue (IDFGH-6030) #7716 describes the problem in more detail.
Closes IDFGH-6030, https://github.com/espressif/esp-idf/issues/7716
Closes IDFGH-6036, https://github.com/espressif/esp-idf/pull/7721
In commit de22f3a4e5, combination of
hardware and software MPI (bignum) related approach was used to
work around chip (e.g. ESP32-C3) limitation of max 3072 bits support.
This was done using linker "--wrap" flag but since the relevant API is
being used in same translation (compilation unit), hardware mode was not
getting used in some cases (e.g., RSA key generation).
This commit modified internal mbedTLS API and makes software+hardware
combination deterministic.
The body of the bootloader_debug_buffer function was conditioned to
macros that were never defined, resulting in deactivated code.
Signed-off-by: Gustavo Henrique Nihei <gustavo.nihei@espressif.com>
Initial version of freemodbus master port files have been added to ESP-IDF based on https://github.com/armink/FreeModbus_Slave-Master-RTT-STM32.
The overall repository license, at the time of adding these files, has been BSD 3-clause. However at that time, several port files carried LGPL license headers. As the author of these files confirmed in https://github.com/armink/FreeModbus_Slave-Master-RTT-STM32/issues/61#issuecomment-977828450, this wasn't intentional. ESP-IDF version of modbus master port has been rewritten to target FreeRTOS instead of RT-Thread, but the license headers remained from the original version. This commit corrects this, replacing the license of these files with BSD 3-clause.
This issue was earlier fixed in commit 79e74e5d5f
but during migration to newer FreeRTOS release, it got introduced again.
This commit fixes thread safety issues with configASSERT() calls
regarding the value of uxSchedulerSuspended. A false negative
occurs if a context switch to the opposite core occurs in between
the getting the core ID and the assesment.
Relevant https://github.com/espressif/esp-idf/issues/4230
Closes https://github.com/espressif/esp-idf/issues/7726
Closes IDFGH-6041
Furthermore, RX_EOF_EN should only be set when SPI Slave is configured
for segment transfer mode and the "ms_data_bitlen" field is configured
to control the "IN_SUC_EOF" interrupt. Since "ms_data_bitlen" is not
set anymore for S2, C3 and S3, "RX_EOF_EN" should be cleared.
The maximum input length for the SPI Slave should be applied to the read
buffer configuration, not for the write buffer. Similarly, the output
configuration should also target the write buffer.
MOSI and MISO enablement were conditioned to the existence of TX
and RX buffers, respectively. This is valid for the SPI Master,
but for the SPI Slave the opposite is expected.
When the build runner has a local git mirror configured via
LOCAL_GIT_MIRROR variable, use that mirror when cloning IDF insider
the docker build job. Follows similar logic for
LOCAL_GITLAB_HTTPS_HOST, which is used for geo nodes.
mesh: fix the issue that layer2 node connect to lower-layer node when FIXED-ROOT root disappeared(backport_v4.3)
See merge request espressif/esp-idf!15660
Switching back from data (PPP) mode to command mode must be done is the following sequence:
* No characters entered for T1 time (1 second)
* "+++" characters entered with no characters in between (1 second)
* No characters entered for T1 timer (1 second)
(per specification of SIM800 SIM800_Series_AT_Command_Manual_V1.09.pdf)
Related https://github.com/espressif/esp-idf/issues/7608
Fix for packets containing unexpected domains, such as openthread.thread.home.arpa.
If we find this packet we set the name entry as invalid, but continue with parsing as the packet might contain related queries for us.
Closes https://github.com/espressif/esp-idf/issues/7694
For the CID10564,10384,10280,10098,10038,The memory was released in other place.
For the CID10365,it release the memory in the function when sent successfully.
For the CID10268,10011, we need not change the code.
the state again and run the "ble_master_soft_rst()" if neesed.
2.fix HCI_Read_Clock error
3.fix HCI_Create_Connection_Cancel error
4.fix ASSERT_WARN during epr
esp_http_client: Fix HEAD request will affect the all next HTTP requests unless we close the HTTP request(backport v4.3)
See merge request espressif/esp-idf!15714
With strict debugging, i.e. `Set-PSDebug -strict`, execution of export.ps1 will
report the following error:
```
The variable '$envars_array' cannot be retrieved because it has not been set.
At C:\path\to\export.ps1:15 char:1
+ $envars_array # will be filled like:
+ ~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (envars_array:String) [], RuntimeException
+ FullyQualifiedErrorId : VariableIsUndefined
```
Closes https://github.com/espressif/esp-idf/pull/7819
Increase reset assertion time from 100µs (as specified minimum in the datasheet) to 150µs.
Some specimen of the LAN8720 need the reset signal asserted longer than 100µs to initialise properly. Otherwise they are in a zombie state where they are establishing and loosing an Ethernet link once in a seconds interval.
During the early start, the virtual eFuse mode can call erase operations when OS is not yet running.
Possible workaround: CONFIG_SPI_FLASH_YIELD_DURING_ERASE=n
Fixed for the legacy flash driver as well.
The psram cache bug fix was also being applied to the bootloader binary (for cmake),
which doesnt do any psram access.
Applying this fix would increase the binary size, as much as 300 bytes in worst case scenarios
* CI errors led me to believe these were needed, but as it turns out the
load/store intrinsics are required even when idf is built by gcc when
linking to a clang based project.
* remove ... postfix inside `SYNC_LOCK_TEST_AND_SET` expansion
Provide emulated atomic load & store libcalls for u8, u16 & u32 integer
types. This is required when building with Clang as llvm does not lower
these operations to native load / stores, where as gcc does.
Provide `sync_lock_test_and_set` atomic implementations for all
supported integer types.
Closes https://github.com/espressif/esp-idf/issues/7591.
Closes https://github.com/espressif/esp-idf/issues/7592.
The issue is related to the non-sequential way of description when
such fields going together sequential.
Related to esp32h2 chip for eFuses: MAC_FACTORY and MAC_EXT.
The issue is in wrong indexes of MAC_EXT.
MAC_EXT got indexes like it is joined to MAC_FACTORY.
const esp_efuse_desc_t* ESP_EFUSE_MAC_FACTORY[] = {
&MAC_FACTORY[0],
&MAC_FACTORY[1],
&MAC_FACTORY[2],
&MAC_FACTORY[3],
&MAC_FACTORY[4],
&MAC_FACTORY[5],
NULL
};
const esp_efuse_desc_t* ESP_EFUSE_MAC_EXT[] = {
&MAC_EXT[6],
&MAC_EXT[7],
NULL
};
This commit fixed it to:
const esp_efuse_desc_t* ESP_EFUSE_MAC_EXT[] = {
&MAC_EXT[0],
&MAC_EXT[1],
NULL
};
The code checked CONFIG_ETH_USE_SPI_ETHERNET (which is usually set),
but CONFIG_EXAMPLE_ETH_SPI_xxx_GPIO options are only defined if
CONFIG_EXAMPLE_USE_SPI_ETHERNET is set. Fix the ifdef accordingly.
Regression from aea901f0.
It was when in the partition table there is a partition with type="data" and suptype=""(empty),
in this case type=1, suptype=0. It is similar to otadata partition.
This commit fixes it, now it will handle it as type=1, suptype=6 (ESP_PARTITION_SUBTYPE_DATA_UNDEFINED).
There was race condition where interrupt entries set by APP cpu core
could have been cleared during PRO cpu startup.
This was causing "cache access error" not being detected for ESP32 APP
CPU core.
This fix allows to NOT modify or clear any entries set by other core
(APP or PRO) and thus avoiding any race conditions during startup code.
spi_flash(bootloader): adjust unlock patch from rom patch into bootloader, and add support for GD chips (backport v4.3)
See merge request espressif/esp-idf!14605
esp_restart()/panic_restart() never resets the Digital system (so far required only by the Memprot feature) as there's a typo in the corresponding #define:
it checks CONFIG_ESP_SYSTEM_CONFIG_MEMPROT_FEATURE instead of CONFIG_ESP_SYSTEM_MEMPROT_FEATURE.
Issue fixed.
IDF-4094
When the application is being debugged it should check the call result (esp_cpu_in_ocd_debug_mode())
is not given volt.glitch attack - so the result is triple-checked by ESP_FAULT_ASSERT macro. In case
the check fails, the system is reset immediately
IDF-4014
ROM code doesn't allow loader stub to be executed in case secure boot in
enabled. Providing --no-stub flag to esptool allows user to flash new
firmware, given download mode hasn't been disabled
* Disable Tx interrupts to fix race condition of missing Rx interrupt
* Check if GPIO interrupt is asserted periodically if the ISR event missed
Closes https://github.com/espressif/esp-idf/issues/6414
Default 30s timeout is too low for a case when SD card formatting is triggered,
which could lead to tests failure. Timeout of tests is now set to 60s.
JIRA IDFCI-742
1. Added config options to chose from protocom security.
It can be chosen 0/1 or custom.
Possible to set POP as well
2. Added support in `esp_local_ctrl.py` test script for sec_ver selection
Signed-off-by: Vikram Dattu <vikram.dattu@espressif.com>
For https connection `ESP_TLS_ERR_SSL_WANT_READ` of esp_transport_read was getting treated as error.
Treated this as a timeout to fix connection abort issue!
Also handled http connection EAGAIN with `errno == EAGAIN` check.
Signed-off-by: Vikram Dattu <vikram.dattu@espressif.com>
A race condition is occuring while creating task on ESP32C3. Task is
getting created, but the function returns with a delay. Since task was
created, events start getting posted, but existing application
initializes certain threads / callbacks after stack initialization.
The same application works in different ways for bluedroid and nimble.
Hence modified the order during initialization accordingly.
When not compiling bootloader, a spinlock will be used for reading or writing
I2C internal devices/registers.
When compiling for bootloader, no need to use any lock.
* Description of unregistering was incorrect
* Made clear that event loop arg mustn't be NULL
* Added parameter check in create function
Closes https://github.com/espressif/esp-idf/issues/6761
Closes IDFGH-4969
We found conflict in "sizeof(time_t)" due to inclusion of this
header over toolchain specific "newlib.h".
Moreover, there are no users for this header and implementation
for API is also not available in ROM. Hence removing it.
Driver was using the channel ID from tx when reseting rx.
But since rx and tx is not necessarily from the same pair this could lead
to the driver reseting the wrong DMA channel.
Large SD cards (16GB+) require significant amount of time for FS formatting.
Added FS mount checkpoint in example test python, timeout set to 60 sec
Closes IDFCI-706
Allow user to select specific ESP_TARGET while setting up ESD_IDF.
Only necessary tools for given target will be downloaded and installed.
Closes https://github.com/espressif/esp-idf/issues/5113
1. Update wifi lib with fix for dropping bcast PMF deauths/disassocs
with certain reason codes
2. Fix FTM not working in connected state and some other FTM bugs
Before newlib 3.3.0, <dirent.h> bundled in newlib did not include any
function declarations. Instead, the file included the platform-
specific <sys/dirent.h>. This inclusion was inside a C++ guard block.
ESP-IDF provided sys/dirent.h inside newlib component, and this file
contained all the necessary function and structure declarations.
Since da418955f5,
common function declarations have been added to <dirent.h> in newlib.
However, the inclusion of sys/dirent.h has been moved out of the C++
guard block. However we didn't notice this change and did not update
sys/dirent.h in ESP-IDF newlib component to and the now-required
C++ guards there.
This commit adds the missing C++ guards to the platform-specific
sys/dirent.h.
The declarations of common dirent.h functions are now present both in
<dirent.h> (provided by newlib) and in sys/dirent.h (provided by IDF).
We keep the declarations in sys/dirent.h for compatibility, since some
ESP-IDF files and applications may include <sys/dirent.h> directly,
rather than <dirent.h>.
Closes https://github.com/espressif/esp-idf/issues/7204
Check Memprot lock bit(s) during the system startup, abort/reset on any Memprot parts found locked during this phase.
There is no legal reason to disallow the Memprot configuration by the system, so it's either a critical bug in the
application or an malicious attempt to bypass the system security.
Error message is printed before digital system reset.
Closes IDF-2700
Bugfix: Set LANG to en code to avoid RuntimeError during autocompletion activation & Replaced broken link to shell autocompletion (v4.3)
See merge request espressif/esp-idf!14122
- there was a small race in `uart_pattern_link_free`:
`rx_pattern_pos.data` was accessed for reading outside spinlock
- `uart_flush_input` enabled
`UART_INTR_RXFIFO_FULL|UART_INTR_RXFIFO_TOUT` intr mask on exit even
if these flags weren't set when function was called
Closes https://github.com/espressif/esp-idf/pull/7023
IRAM section didn't contain sufficient padding for possible CPU instruction prefetch,
ie instruction fetch could happen in DRAM section which is prohibited by the Memprot module.
This is fixed by adding 16B to the end of IRAM section in LD script (C3 CPU prefetch buffer depth is 4 words)
Closes IDF-3554
- Add `wifi_prov_scheme_ble_set_mfg_data` API to set custom manufacturer data
in BLE advertisements.
- Run format.sh script on modified files.
- Fix few typos in `protocomm_nimble.c`.
- Incorporate suggestion to remove extra check on protocomm_ble_mfg_data_len
- Remove few unnecessary comments.
MbedTLS: Add config option for key elements and key element extension for SSL connection
See merge request espressif/esp-idf!12898
(cherry picked from commit 76bd33e9a4)
38d67725 mbedtls: Add config option key element and key element ext
Fix the issue mentioned when using two or more encoders. Modify PCNT_CTRL_GND_IO
to avoid the affect of USB JTAG(origin pin 19 is used for USB D-). Update esp32c3.
peripherals.ld and docs for esp32s3.
Closes https://github.com/espressif/esp-idf/issues/6889
This is mostly important on ESP32 ECO3 with the
ESP32_ECO3_CACHE_LOCK_FIX, because when we stall the other CPU core
before we disable the TG1 WDT then the first CPU can get stuck
in WDT ISR handle_livelock_int routine waiting for the other CPU.
data cache is unicode. while we use bytes in RegEx expect. The index of
matched pattern is calculated with bytes, could be different from
unicode. Now we fix this issue by using unicode in expect.
1. RRM capability addition for open AP
2. Crash during scan flush
3. Station not able to connect if disassoc timer is present in BTM request
4. Memory leaks during wifi init/deinit.
Update wifi lib with below features -
1. ASAP mode for both Initiator and Responder
2. Offchannel FTM while connected to AP (ASAP only)
3. Support up to 3 Initiators simultaneously
4. Session termination, failure support etc
5. Mem-zero AP scan buffer in get_records API
After we have the performance dashboard, we have more data and no longer depend on the threshold to ensure performance.
Set looser performance thresholds to avoid CI failure.
1. Fix aes_unwrap functionality when hardware acceleration is disabled
2. Fix compilation errors when mbedTLS is disabled.
3. Disable WPA3 when mbedTLS is disabled.
This commit add following crypto changes
1. Update current crypto code with upstream supplicant code
2. Add a proper porting layer to use mbedtls APIs for all the crypto
operations used by supplicant.
Internal crypto will be used when USE_MBEDLTS flag is disabled
in supplicant's menuconfig.
This commit also removes the clutter in crypto files due to partial
porting of some APIs to mbedtls, all the code from those files have
been removed and rewritten in a generic way, this is inspired from
current upstream code.
This also reduces the lib size significantly, supplicant's lib
size reduces around ~567kb after this change(NB: lib size doesn't
indicate reduction in final bin size).
Adds ESP32-C3 support
Updates ESP32-S3 overlay
GDB 9.2 for ESP32-C3 with core dump support
Linker supports eh-frame-hdr for ESP32-C3
Newlib 3.3.0 includes fixes for <cmath> funcs, for overflow when TZ calculating, for malloc checks
Binutils 2.35.1
Closes https://github.com/espressif/esp-idf/issues/6795
WPS strict disables workarounds with different APs and may cause
IOT issues. Remove this as default and introduce as a config option.
Also add changes to declare esp device as single band mobile device since
WFA sniffer was not able to identify it in the certification setup.
* This function has been accidentally removed.
It is necessary to provide the emergency
exception memory pool size for C++ code.
Since our libstdc++ always has exceptions
enabled, this function must exist here even if
-fno-exception is set for user code.
This commit updates the documentation and register struct
of the TWAI driver for the ESP32-C3. Note that the register
fields for ESP32-S3 have also been updated.
Core dump integrity check can now be parametrized through menuconfig.
It can be performed on boot or ignored. When core dump is activated
in the menuconfig, the user can still check the core dump at any time
with the function `esp_core_dump_image_check()`.
Fix a bug where `esp_core_dump_image_get()` was not accessible
when core dump was disabled.
Closes https://github.com/espressif/esp-idf/issues/6620
This commit brings two esp-lwip fixes to IDF:
1) Add configuration to disable DHCP client identification
2195f7416f
This config could be used to disable option 61 in DHCP packets, so that
clients will be identified by their chaddr only.
(This is the lwip upstream original behaviour)
2) Fix server_idx increasing to DNS_MAX_SERVERS and trigger the LWIP_ASSERT
5a567d52f7
When lwip doesn't have DNS server and resolve a domain address, the server_idx
will increase to DNS_MAX_SERVERS, which will trigger the LWIP_ASSERT and make device crash.
Closes https://github.com/espressif/esp-idf/issues/6878
Increase the interrupt reassert level timing so the chances of missing
two consecutive events are minimal.
Enable only SIR_RECV interrupt event, so the SEND events are not used
for GPIO signal.
If the GPIO interrupt is re-asserted too quickly it could be missed. If this happens the driver goes silent and never receives any data. Recover by periodic checks of the IO signal level
The issue typically happens for link-down during Tx. Added two retry levels, one before checking the sanity of the w5500 phy register and another for the Tx done itself (if the device is in the sane state)
Closes https://github.com/espressif/esp-idf/issues/6233
Reading SPI data may come in 4-byte units and thus result in unwanted
overwrites if smaller size registers read, especially if multiple placed
one after another. Fixed by using direct reads to `trans` structure for
sizes smaller or equal to 4.
Closes https://github.com/espressif/esp-idf/issues/6579
And it fixed another case for bootloader_common_get_sha256_of_partition() when CHECK_SIGNATURE is on
- If RSA signature check is on in Kconfig then sha256 was 0xFFFFF...
because image_load gave image_len which pointed to the end of sign blocks.
And image_digest was filled from a wrong position.
Closes https://github.com/espressif/esp-idf/issues/6873
Theory is that on the runner, in rare cases, gdb may need more than
1 second to load and start responding to commands.
However it's possible these timeouts are due to some other problem
(like gdb failing)
The previous location was the return from the first ets_printf call
that prints ROM sign-on message. Since the main function was patched
in ECO3, the new address no longer works — there is no instruction at
0x40007901 in ECO3 ROM. This could be solved by setting two
breakpoints (one would work for ECO <=2, the other for ECO3), but we
would need to remove the unused breakpoint later.
Fix this by setting the breakpoint at ets_printf. This means that when
debugging a loadable ELF the ROM sign-on message will no longer be
shown, but this doesn't seem to be an issue.
Partially reverted 08f1bbe0c7.
The host should have this flexibility, which is consistent to the cs_hold argument.
However, the user should know as less as possible about the host.
So the wrapper layer (esp_flash_spi_init.c) should cover this, helping to set cs_setup to 1, to meet the common requirements.
* Move nvs flash README to common doc directory
* correct markup of functions and types in text
from old README
* Better comment of nvs_get_used_entry_count()
* Mention C++ example in API reference
* Used target instead of hard code ESP32
* Note that strings can only span one page
* Reflect that item types have been moved
* Some clarification about nvs_commit()
* Improved reference to the ESP Partition API
* fixed little mistake in documenting-code.rst
* Change of nvs_open_from_part() to
nvs_open_from_partition() reflected in docs
* Corrected documentation of
NVSHandle::get_string(), NVSHandle::get_blob()
and NVSHandle::get_item_size().
* Closes DOC-165
* Closes IDF-1563
* Closes IDF-859
* Closes https://github.com/espressif/esp-idf/issues/6123
ROM will erase the region a partition is in as soon as it receives the
first bit of the data that is in the partition. For large partitions it
takes more than 5 seconds to erase which is a hard-coded limit in
dfu-utils.
This splits large binaries and adds them by chunks which should avoid
timing-out during flashing.
Closes https://github.com/espressif/esp-idf/issues/6999
Possible for a joined task to be deleted at the moment it is logging,
meaning it might hold the stdout lock. In that case the lock isn't
released and the next task to try and take it (i.e. call printf)
will block indefinitely.
Additionally, always enable the partition MD5 check if flash encryption is on in
Release mode. This ensures the partition table ciphertext has not been modified
(CVE-2021-27926).
The exception is pre-V3.1 ESP-IDF bootloaders and partition tables, which
don't have support for the MD5 entry.
Add support to tasks stacks in RTC DRAM. Before this fix, any stack
in RTC DRAM would have been considered as corrupted, whichi is not
the case.
Fix a bug related to wrong parameters passed to esp_core_dump_get_stack.
Fix a bug reading fake stack memory, triggering a memory violation.
* Closes https://github.com/espressif/esp-idf/issues/6751
* Merges https://github.com/espressif/esp-idf/pull/6750
Building mbedtls with CMake would warn that:
"A private source from a directory other than that of target "mbedcrypto
has a relative path"
This happened due to some of the CMake variables listing sources could be empty.
Changed to only use target_sources in the code-path where we set the sources,
so we only call target_sources will non-empty variables.
Closes https://github.com/espressif/esp-idf/issues/6767
NimBLE: Add NimBLE host support to reattempt GAP connection and address MITM vulnerability (CVE-2020-26558) (release/v4.3)
See merge request espressif/esp-idf!13549
Reraising the exception before exiting was intended to help troubleshoot,
but turned out to be more confusing than helpful as it might look like the script was failing
* Patched longjmp to be context-switch safe
longjmp modifies the windowbase and windowstart
registers, which isn't safe if a context switch
occurs during the modification. After a context
switch, windowstart and windowbase will be
different, leading to a wrongly set windowstart
bit due to longjmp writing it based on the
windowbase before the context switch. This
corrupts the registers at the next window
overflow reaching that wrongly set bit.
The solution is to disable interrupts during
this code. It is only 6 instructions long,
the impact shouldn't be significant.
The fix is implemented as a wrapper which
replaces the original first instructions of
longjmp which are buggy. Then, it jumps back
to execute the rest of the original longjmp
function.
Added a comparably reliable test to the
test apps.
Since dd849ffc, _rodata_start label has been moved to a different
linker output section from where the TLS templates (.tdata, .tbss)
are located. Since link-time addresses of thread-local variables are
calculated relative to the section start address, this resulted in
incorrect calculation of THREADPTR/$tp registers.
Fix by introducing new linker label, _flash_rodata_start, which points
to the .flash.rodata output section where TLS variables are located,
and use it when calculating THREADPTR/$tp.
Also remove the hardcoded rodata section alignment for Xtensa targets.
Alignment of rodata can be affected by the user application, which is
the issue dd849ffc was fixing. To accommodate any possible alignment,
save it in a linker label (_flash_rodata_align) and then use when
calculating THREADPTR. Note that this is not required on RISC-V, since
this target doesn't use TPOFF.
It is now possible to have any alignment restriction on rodata in the user
applicaiton. It will not affect the first section which must be aligned
on a 16-byte bound.
Closes https://github.com/espressif/esp-idf/issues/6719
rodata dummy section has now the same alignment as flash text section,
and at least the same size. For these reasons, the cache will map
correctly the following rodata section.
Theory is that the large alignments in this test component are triggering linker
bug (to be fixed in next toolchain update). This component is already tested
in a dedicated config, so it doesn't need to be included in this config.
1. Fix mesh deinit blocking issue
2. Fix root has no eb for deauth frames during the networking
3. Add esp_mesh_send_block_time to set blocking time of esp_mesh_send
4. Forward Mgmt frames with skipping CCMP headers to fix parsing issues in Application for ESP32C3
1. Removed the interrupt lock operation during controller enable/disable/reset, to avoid trigger interrupt watchdog time-out due to use of mutex/semaphore in coex_st_set
2: Update libbtbb.a for ESP32-C3 to fix the Rx performance issue for CODED PHY, especially in coexistence scenario
When user forgot to add git.exe or python to the PATH, there was a not
very helpful error message.
This improves the error with which tool is misssing and shows a link to
the espressif installer tool.
disconnect event. This issue is caused by modem sleep.The sleep interrupt
will come the second time before the CLKN interrupt. If we disable the sleep
interrupt when it comes in the first time, the CLKN will never come.
Noted as a problem with thread local storage returning a different task's
pointers, but some other were APIs also accessing current task unsafely.
Regression in FreeRTOS 10 update a3c90bf59a
Currently Max GATT services count cannot be configured externally and
hence user needs to modify code ,everytime the count is to be
modified.
Added an option in menuconfig to provide a way to user to set the count.
Fixes: https://jira.espressif.com:8443/browse/BT-1508
Causes test added in parent commit to pass.
This race happens if the deleted task is running on the other CPU,
and is already spinning in a critical section waiting for xTaskQueueMutex
because it's about to be blocked for a resource.
The "deleted" task would end up blocked, possibly indefinitely, and
never actually deleted or its resources cleaned up by the idle tasks.
Details:
vTaskDelete() adds the target task to the xTasksWaitingTermination list,
expecting it to be yielded off CPU and then cleaned up later. However as soon as
vTaskDelete() releases xTaskQueueMutex, the target task runs and moves itself to the
xDelayedTaskList1. Because interrupts are already disabled on that CPU,
the "yield" to the other CPU sent by the vTaskDelete() comes afterward so
doesn't help.
mdns resolver didn't correctly resolved queries when host name wasn't
assigned. Fixed by allowing processing also if some answer present
(non-strict mode)
Closes https://github.com/espressif/esp-idf/issues/6598
The resolver was able to respond correctly, but would also resolve its
own queries and cause issues with BCT 1.5.2, specifically
* MULTIPLE QUESTIONS - DUPLICATE SUPPRESSION
* MULTIPLE QUESTIONS - DISTRIBUTED DUPLICATE SUPPRESSION
tests failed.
Strict mode was hardcoded in private header file, but it's useful for
users to enable/disable it depending on the mdns library they are using.
e.g. Avahi might not resolve the non-strict answers.
When `DIS_USB_JTAG` eFuse is NOT burned (`False`), it is not possible
to set pins 18 and 19 as GPIOs. This commit solves this by manually
disabling USB JTAG when using pins 18 or 19.
The functions shall use `gpio_hal_iomux_func_sel` instead of
`PIN_FUNC_SELELECT`.
Newer versions of doxygen will give warnings for comments in
INPUT lists
Delete all comment lines to fix these warnings, our folder structure
stil gives an OK overview of what we are including
VDD_SDIO power domain can now be configured for light sleep
by the application. It is now possible to keep the power domain
ON during light sleep, keeping the GPIOs connected to it powered.
The power domain will, by default be:
- Kept ON if CONFIG_ESP_SYSTEM_PD_FLASH is not set
- Turned OFF if not set
The application can still force it to be ON by calling
`esp_sleep_pd_config(ESP_PD_DOMAIN_VDDSDIO, ESP_PD_OPTION_ON);`
Fixes issue with DPORT init task, this task uses minimum stack size and may not be
enough if stack smashing detection is set to Overall mode.
Also reworks the way we calculate minimum stack to allow for adding multiple
contributing factors.
Closes https://github.com/espressif/esp-idf/issues/6403
Current code stopped inquiry if major class is not Phone. Modified the
condition to consider for both Phone and Audio to cover majority of real
world devices.
Closes https://github.com/espressif/esp-idf/issues/6548
Unless the option for "assert and keep running" is enabled.
This means that silent asserts now work for FreeRTOS, and disabling asserts
now also disables them in FreeRTOS without needing a separate config change.
Related to https://github.com/espressif/esp-idf/issues/6306
If silent assert configuration is enabled, LWIP asserts are now 'silent' also.
Also updates KConfig to note that LWIP asserts are also disabled when asserts
are disabled globally (this was already the behaviour, but the config item
suggested otherwise.)
Progress towards https://github.com/espressif/esp-idf/issues/5873
The CPU might prefetch instructions, which means it in some cases
will try to fetch instruction located after the last instruction in
flash.text.
Add dummy bytes to ensure fetching these wont result in an error,
e.g. MMU exceptions
1. deepsleep poweron reset bug in high temperature before ECO3;
2. brownout reset bug before ECO2;
3. bbpll voltage low bug before ECO3;
4. need xpd iph for xtal before ECO3;
As this mode uses the public keys attached to the existing app's signatures to
verify the next app, checking that a signature block is found on boot prevents
the possibility of deploying a non-updatable device from the factory.
The dirent.h shipped with the risc-v compiler lacks `extern "C"`
declartion and causes linkage declartion conflict when included in C++
files. Use the dirent.h from newlib only to avoid this issue.
(cherry picked from commit b14830c5c0)
This commit includes the refactoring of the core dump feature. Thanks to
this refactoring, it is easier to integrate the support of RISC-V
architecture for this feature.
Fixes ESP-1758
NOP instructions have been added in order to prevent the code
from executing code it shouldn't execute. This is due to a delay
between the moment an interrupt is requested and the moment it
is fired. It only happens on RISC-V SoC.
Removed the old dynamically allocated GDMA channel approach.
It proved too unreliable as we couldn't not ensure consumers of the mbedtls
would properly free the channels after use.
Replaced by a single shared GDMA channel for AES and SHA, which won't be
released unless user specifically calls API for releasing it.
1. Fix the issue that the parameters obtained from RAM cannot be saved to NVS
2. Modify not to store the default value in NVS
3. Fixed issue with hidden AP scans after connecting AP.
4. Fix watchdog issue when receiving action frame.
5. Fixed issue of reason code change from 15 to 204 when provide wrong password
6. Fix set config return value error
7. Fix ampdu age timer memory leak
On S2 the brown out detector would occasionally trigger erroneously during deep sleep.
Disable it before sleeping to circumvent this issue.
Closes https://github.com/espressif/esp-idf/issues/6179
Enable shared stack watchpoint for overflow detection
Enable unit tests:
* "test printf using shared buffer stack" for C3
* "Test vTaskDelayUntil" for S2
* "UART can do poll()" for C3
On C3 the cache is programmatically split between Icache and dcache and with the default setup we dont leave a lot pages
available for additional mmaps into instruction space. Disabling this test for now since any hypothetical use case for this
is no longer supported "out of the box"
description:Before submitting a new issue, please follow the checklist and try to find the answer.
options:
- label:I have read the documentation [ESP-IDF Programming Guide](https://docs.espressif.com/projects/esp-idf/en/latest/) and the issue is not addressed there.
required:true
- label:I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
required:true
- label:I have searched the issue tracker for a similar issue and not found a similar issue.
required:true
- type:input
id:idf_version
attributes:
label:IDF version.
description:Onwhich IDF version does this issue occur on? Run `git describe --tags` to find it.
placeholder:ex. v3.2-dev-1148-g96cd3b75c
validations:
required:true
- type:dropdown
id:operating_system
attributes:
label:Operating System used.
multiple:false
options:
- Windows
- Linux
- macOS
validations:
required:true
- type:dropdown
id:build
attributes:
label:How did you build your project?
multiple:false
options:
- Command line with Make
- Command line with CMake
- Command line with idf.py
- Eclipse IDE
- CLion IDE
- VS Code IDE
- Other (please specify in More Information)
validations:
required:true
- type:dropdown
id:windows_comand_line
attributes:
label:If you are using Windows, please specify command line type.
multiple:false
options:
- PowerShell
- CMD
validations:
required:false
- type:textarea
id:expected
attributes:
label:What is the expected behavior?
description:Please provide a clear and concise description of the expected behavior.
placeholder:I expected it to...
validations:
required:true
- type:textarea
id:actual
attributes:
label:What is the actual behavior?
description:Please describe actual behavior.
placeholder:Instead it...
validations:
required:true
- type:textarea
id:steps
attributes:
label:Steps to reproduce.
description:'How do you trigger this bug? Please walk us through it step by step. If this is build bug, please attach sdkconfig file (from your project folder). Please attach your code here.'
value:|
1. Step
2. Step
3. Step
...
validations:
required:true
- type:textarea
id:debug_logs
attributes:
label:Build or installation Logs.
description:Build or installation log goes here, should contain the backtrace, as well as the reset source if it is a crash.
placeholder:Your log goes here.
render:plain
validations:
required:false
- type:textarea
id:diag
attributes:
label:Diagnostic report archive.
description:|
Diagnostic report for ESP-IDF created using [idf.py diag](https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/tools/idf-diag.html) or [esp-idf-diag](https://github.com/espressif/esp-idf-diag). The `idf.py diag` command is available beginning with ESP-IDF version 5.5. For older versions, you may want to consider using the `esp-idf-diag` command.
In your project directory, execute the following command:
Using `idf.py diag`
1. idf.py diag
Using `esp-idf-diag`
1. pip install esp-idf-diag
2. esp-idf-diag create
Once the report is generated, the tool will guide you with the next steps.
placeholder:Please attach the diagnostic report zip file here.
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` (or `esptool.py chip_id` for ESP-IDF v5.5 and older) 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?
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. Please attach your code here.'
value:|
1. Step
2. Step
3. Step
...
validations:
required:true
- type:textarea
id:debug_logs
attributes:
label:Debug Logs.
description:Debug 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:diag
attributes:
label:Diagnostic report archive.
description:|
Diagnostic report for ESP-IDF created using [idf.py diag](https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/tools/idf-diag.html) or [esp-idf-diag](https://github.com/espressif/esp-idf-diag). The `idf.py diag` command is available beginning with ESP-IDF version 5.5. For older versions, you may want to consider using the `esp-idf-diag` command.
In your project directory, execute the following command:
Using `idf.py diag`
1. idf.py diag
Using `esp-idf-diag`
1. pip install esp-idf-diag
2. esp-idf-diag create
Once the report is generated, the tool will guide you with the next steps.
placeholder:Please attach the diagnostic report zip file here.
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.
* 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.**
- [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:clang_tidy:
rules:
- <<: *if-protected
- <<: *if-dev-push
changes: *patterns-c-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]
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
- pytest_for_ut ./efuse_tests.py
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
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
script:
- cd ${IDF_PATH}/tools/esp_app_trace/test/sysview
- ./test.sh
test_tools:
extends:
- .host_test_template
artifacts:
paths:
- ${IDF_PATH}/*.out
- ${IDF_PATH}/XUNIT_*.xml
reports:
junit:${IDF_PATH}/XUNIT_*.xml
variables:
LC_ALL:C.UTF-8
INSTALL_EXTRA_TOOLS:"qemu-xtensa qemu-riscv32"# for test_idf_qemu.py
@@ -10,12 +10,14 @@ _This entire section can be deleted if all items are checked._
* [ ] 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 `needs translation:CN` or `needs translation:EN` have been added when the other language version still needs the update. Don't add such labels if the document updated has never been translated before and requires translation from scratch.
* [ ] 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.
* [ ] Pipeline with Python 3 has been successfully run, i.e. `@bot ...; with Python3`, if the MR adds or changes Python code.
---
@@ -39,5 +41,24 @@ _For other small/non-public changes, which are not expected to be in the release
* Mention submodule MR, if there is
* Mention backport(ed) MR, if there is
<!-- Don't remove the next line - assigns the MR author as the assignee -->
/assign me
_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/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/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`.
Note: IDF v5.1.5 and v5.3.2 are compatible with C2 v2.0. However the chip revision check hasn't been updated on these releases. Enable `ESP32C2_REV2_DEVELOPMENT` config to bypass the outdated check.
## What If the ESP-IDF Version Is Lower than the `Required` Version?
Latest ESP-IDF versions can prevent from downloading to, or even execute binaries on unsupported chips. ESP-IDF of versions v4.4.5+, v5.0.1+, v5.1 and above have both esptool download check and bootloader loading check against the chip revision. While ESP-IDF v4.3.5 has only esptool downloading check.
For earlier ESP-IDF versions without such checking, which is incompatible with the given chip revision, the chips running such versions will have unpredictable behavior.
Contributions to esp-idf - fixing bugs, adding features, adding documentation - are welcome. We accept contributions via `Github Pull Requests <https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests>`_.
Before Contributing
-------------------
Before sending us a Pull Request, please consider this list of points:
* Is the contribution entirely your own work, or already licensed under an Apache License 2.0 compatible Open Source License? If not then we unfortunately cannot accept it.
* Does any new code conform to the esp-idf :doc:`Style Guide <style-guide>`?
* Have you installed the :doc:`pre-commit hook <install-pre-commit-hook>` for esp-idf project?
* Does the code documentation follow requirements in :doc:`documenting-code`?
* Is the code adequately commented for people to understand how it is structured?
* Is there documentation or examples that go with code contributions? There are additional suggestions for writing good examples in :idf:`examples` readme.
* Are comments and documentation written in clear English, with no spelling or grammar errors?
* Example contributions are also welcome. Please check the :doc:`creating-examples` guide for these.
* If the contribution contains multiple commits, are they grouped together into logical changes (one major change per pull request)? Are any commits with names like "fixed typo" `squashed into previous commits <https://eli.thegreenplace.net/2014/02/19/squashing-github-pull-requests-into-a-single-commit/>`_?
* If you're unsure about any of these points, please open the Pull Request anyhow and then ask us for feedback.
Pull Request Process
--------------------
After you open the Pull Request, there will probably be some discussion in the comments field of the request itself.
Once the Pull Request is ready to merge, it will first be merged into our internal git system for in-house automated testing.
If this process passes, it will be merged onto the public github repository.
Legal Part
----------
Before a contribution can be accepted, you will need to sign our :doc:`contributor-agreement`. You will be prompted for this automatically as part of the Pull Request process.
- Please read [the support policy](SUPPORT_POLICY.md) and [the documentation](https://docs.espressif.com/projects/esp-idf/en/latest/esp32/versions.html) for more information about ESP-IDF versions.
- Please see the [End-of-Life Advisories](https://www.espressif.com/en/support/documents/advisories?keys=&field_type_of_advisory_tid%5B%5D=817) for information about ESP-IDF releases with discontinued support.
# ESP-IDF Release and SoC Compatibility
The following table shows ESP-IDF support of Espressif SoCs where ![alt text][preview] and ![alt text][supported] denote preview status and support, respectively. The preview support is usually limited in time and intended for beta versions of chips. Please use an ESP-IDF release where the desired SoC is already supported.
There are variants of revisions for a series of chips. See [Compatibility Between ESP-IDF Releases and Revisions of Espressif SoCs](https://github.com/espressif/esp-idf/blob/master/COMPATIBILITY.md) for the details of the compatibility between ESP-IDF and chip revisions.
Espressif SoCs released before 2016 (ESP8266 and ESP8285) are supported by [RTOS SDK](https://github.com/espressif/ESP8266_RTOS_SDK) instead.
ESP-IDF is the development framework for Espressif SoCs (released after 2016<sup>[1](#fn1)</sup>) provided for Windows, Linux and macOS.
# Developing With ESP-IDF
@@ -46,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
@@ -83,7 +53,7 @@ See the Getting Started guide links above for a detailed setup guide. This is a
## Flashing the Project
When the build finishes, it will print a command line to use `esptool` to flash the chip. However you can also do this automatically by running:
When the build finishes, it will print a command line to use esptool.py to flash the chip. However you can also do this automatically by running:
`idf.py -p PORT flash`
@@ -95,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-].
@@ -116,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.
This document outlines the goals of ESP-IDF project and is shared for the convenience of our customers. It is important to clarify that this document is not a binding commitment to our customers. Instead, its primary purpose is to offer a clear roadmap and direction for the project's development. By openly sharing this information, we aim to enhance our customers' understanding, promote transparency and ensure alignment with the overarching objectives of the ESP-IDF project.
## Project Overview
### Project Goals
In both minor and major releases, we integrate new chip support to enhance our product range. By expanding the chip matrix, we broaden the scope of our offerings, catering to a wider audience with diverse needs. This proactive approach ensures that our products remain at the forefront of technological advancements, consistently meeting and exceeding customer expectations.
Furthermore, we prioritize bugfix releases for active branches, focusing on improving the stability and performance of products already in production. By addressing bugs promptly, we aim to enhance the overall user experience and provide tangible benefits to customers relying on our solutions. This proactive maintenance strategy reflects our commitment to delivering reliable, high-quality products to our valued customer base.
Below are the main objectives that ESP-IDF project/teams would like to implement in 2025.
- New Chip Support
- Add support for ESP32-C5
- Add support for ESP32-C61
- More Minor/Major Releases
- Release IDF v5.5 in the middle of 2025
- Release IDF v6.0 at the end of 2025
- More Bugfix Releases
- Release v5.0.8 and v5.0.9 before ESP-IDF v5.0 goes End of Life in May 2025
- Release v5.1.6 and v5.1.7 before ESP-IDF v5.1 goes End of Life in December 2025
- Do more bugfix releases for IDF v5.2 and IDF v5.3 before release/5.2 and release/5.3 enter maintenance period
- Do more bug fixes releases for release/5.4 and release/5.5, and push the two releases to be more stable and production-ready
- Major Changes
- We plan to upgrade MbedTLS to v4.x series in IDF v6.0. In addition, we will also be migrating to newer PSA crypto API as part of this upgrade. Please note that this may involve some breaking changes on the application side for the crypto API usage.
Please note that support status of previous silicones could be found on [ESP-IDF Release and SoC Compatibility](https://github.com/espressif/esp-idf#esp-idf-release-and-soc-compatibility).
### Roadmap Details
The ESP-IDF project prioritizes consistent maintenance and updates to ensure our customers remain at the forefront of technological advancements. Our commitment to ongoing development ensures that customers continuously benefit from the latest innovations in the field.
Moreover, we are dedicated to empowering our customers to leverage newly implemented features and enhanced functionalities through iterative improvements. Our steadfast commitment to pushing boundaries ensures that clients not only keep pace with evolving technology but also extract optimal value from the cutting-edge capabilities of our products.
Below are the main roadmap details for functional areas inside ESP-IDF.
- New Chip Support
- Add the initial support for the mass production version of ESP32-C5 in ESP-IDF v5.5, refer to [ESP32-C5 Support Status](https://github.com/espressif/esp-idf/issues/14021)
- Add the initial support for the mass production version of ESP32-C61 in ESP-IDF v5.5, refer to [ESP32-C61 Support Status](https://developer.espressif.com/pages/chip-support-status/esp32c61/#esp-idf)
- Bugfix releases
- Do bugfix releases v5.0.8 and v5.0.9 and stop maintaining ESP-IDF v5.0 in May 2025
- Do bugfix releases v5.1.6 and v5.1.7 and stop maintaining ESP-IDF v5.1 in December 2025
- Release bugfix IDF v5.2.4, IDF v5.2.5 and IDF v5.2.6 in 2025, and push release/5.2 to maintenance period from February 2025
- Release bugfix IDF v5.3.3 and IDF v5.3.4 in 2025, and push release/5.3 to maintenance period from July 2025
- Do more bug fixes releases for release/5.4 (IDF v5.4.1, IDF v5.4.2, IDF v5.4.3) and release/5.5 (IDF v5.5.1, IDF v5.5.2), and push releases to be more stable and more production-ready
## ESP-IDF Planning information
For the full list of ESP-IDF releases, please visit https://github.com/espressif/esp-idf/releases
All the information provided here is subject to change without notice, due to business reasons and other factors.
Please refer to https://docs.espressif.com/projects/esp-idf/en/latest/esp32/versions.html#support-periods for more details on ESP-IDF supported versions and support period policy.
## Reporting a Vulnerability
Please refer to [Espressif Security Incident Response Process](https://www.espressif.com/sites/default/files/Espressif%20Security%20Incident%20Response%20Process%20v1.0_EN.pdf) on the guidelines to report a security vulnerability. Please do **NOT** create a public GitHub issue.
Each ESP-IDF major and minor release (V4.1, V4.2, etc) is supported for 30 months after the initial stable release date.
Each ESP-IDF major and minor release (V4.1, V4.2, etc) is supported for
30 months after the initial stable release date.
Supported means that the ESP-IDF team will continue to apply bug fixes, security fixes, etc to the release branch on GitHub, and periodically make new bugfix releases as needed.
Supported means that the ESP-IDF team will continue to apply bug fixes,
security fixes, etc to the release branch on GitHub, and periodically
make new bugfix releases as needed.
Support period is divided into "Service" and "Maintenance" period:
@@ -16,43 +19,65 @@ Support period is divided into "Service" and "Maintenance" period:
| Service | 12 months | Yes |
| Maintenance | 18 months | No |
During the Service period, bugfixes releases are more frequent. In some cases, support for new features may be added during the Service period (this is reserved for features which are needed to meet particular regulatory requirements or standards for new products, and which carry a very low risk of introducing regressions.)
During the Service period, bugfixes releases are more frequent. In some cases,
support for new features may be added during the Service period (this is
reserved for features which are needed to meet particular regulatory
requirements or standards for new products, and which carry a very low risk of
introducing regressions.)
During the Maintenance period, the version is still supported but only bugfixes for high severity issues or security issues will be applied.
During the Maintenance period, the version is still supported but only bugfixes
for high severity issues or security issues will be applied.
Using an “In Service” version is recommended when starting a new project.
Users are encouraged to upgrade all projects to a newer ESP-IDF release before the support period finishes and the release becomes End of Life (EOL). It is our policy to not continue fixing bugs in End of Life releases.
Users are encouraged to upgrade all projects to a newer ESP-IDF release before
the support period finishes and the release becomes End of Life (EOL). It is our
policy to not continue fixing bugs in End of Life releases.
Pre-release versions (betas, previews, `-rc` and `-dev` versions, etc) are not covered by any support period. Sometimes a particular feature is marked as "Preview" in a release, which means it is also not covered by the support period.
Pre-release versions (betas, previews, `-rc` and `-dev` versions, etc)
are not covered by any support period. Sometimes a particular feature is
marked as "Preview" in a release, which means it is also not covered
by the support period.
ESP-IDF should be used in an up-to-date software environment. The operating system and other third-party tools should be supported by their maintainers. ESP-IDF cannot keep compatibility with unsupported third-party tools.
The ESP-IDF Programming Guide has information about the [different versions of ESP-IDF](https://docs.espressif.com/projects/esp-idf/en/latest/versions.html) (major, minor, bugfix, etc).
The ESP-IDF Programming Guide has information about the
[different versions of ESP-IDF](https://docs.espressif.com/projects/esp-idf/en/latest/versions.html)
(major, minor, bugfix, etc).
Example
-------
ESP-IDF V3.3 was released in September 2019. It was supported for 30 months until February 2022.
ESP-IDF V3.3 was released in September 2019. It will be supported for 30 months
until February 2022.
- The first V3.3 release was `v3.3` in September 2019.
- The ESP-IDF team continues to backport bug fixes, security fixes, etc to the release branch `release/v3.3`.
- Periodically stable bugfix releases are created from the release branch. For example `v3.3.1`, `v3.3.2`, etc. Users are encouraged to always update to the latest bugfix release.
-V3.3 bugfix releases continue until February 2022, when all V3.3.x releases become End of Life.
- The ESP-IDF team continues to backport bug fixes, security fixes,
etc to the release branch `release/v3.3`.
-Periodically stable bugfix releases are created from the release
branch. For example `v3.3.1`, `v3.3.2`, etc. Users are encouraged to
always update to the latest bugfix release.
- V3.3 bugfix releases continue until February 2022, when all V3.3.x
releases become End of Life.
Existing Releases
-----------------
ESP-IDF release V4.1 and all newer releases will follow this support period policy. The support period for each release will be announced when the release is made.
ESP-IDF release V4.1 and all newer releases will follow this support period
policy. The support period for each release will be announced when the release
is made.
For releases made before the current support period policy was announced, the original support periods apply:
For releases made before the current support period policy was announced, the
original support periods apply:
* ESP-IDF V4.0.x will be supported until October 2021
* ESP-IDF V3.3.x will be supported until February 2022
* ESP-IDF versions before V3.3 are already End of Life.
* ESP-IDF V3.1.x and V3.2.x will both be supported until October 2020.
* ESP-IDF versions before V3.1 are already End of Life.
Policy History
--------------
* September 2019. This policy splits ESP-IDF releases into Standard and Long Term Support.
* July 2020. All releases from now will have the same support period, which is equal to the previous Long Term Support period. Added “In Service” period, during which versions will receive more updates.
* September 2019. This policy split ESP-IDF releases into Standard and Long Term
Support.
* July 2020. All releases from now will have the same support period, which is
equal to the previous Long Term Support period. Added “In Service” period,
This document contains details about what the core components are, what they contain, and how they are organized.
## Organization
The core components are organized into two groups.
The first group (referred to as `G0`) includes `hal`, `arch` (where `arch` is either `riscv` or `xtensa` depending on the chip), `esp_rom`, `esp_common`, and `soc`. This group contains information about and provides low-level access to the underlying hardware. In the case of `esp_common`, it contains hardware-agnostic code and utilities. These components may have dependencies on each other within the group, but outside dependencies should be minimized. The reason for this approach is that these components are fundamental, and many other components may require them. Ideally, the dependency relationship only goes one way, making it easier for this group to be usable in other projects.
The second group (referred to as `G1`) operates at a higher level than the first group. `G1` includes the components `esp_hw_support`, `esp_system`, `esp_libc`, `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 usable 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.
#### `esp_libc`
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:
// In general tracing goes in the following way. User application requests tracing module to send some data by calling esp_apptrace_buffer_get(),
// module allocates necessary buffer in current input trace block. Then user fills received buffer with data and calls esp_apptrace_buffer_put().
// When current input trace block is filled with app data it is exposed to host and the second block becomes input one and buffer filling restarts.
// While target application fills one TRAX block host reads another one via JTAG.
// This module also allows communication in the opposite direction: from host to target. As it was said ESP32 and host can access different TRAX blocks
// simultaneously, so while target writes trace data to one block host can write its own data (e.g. tracing commands) to another one then when
// blocks are switched host receives trace data and target receives data written by host application. Target user application can read host data
// by calling esp_apptrace_read() API.
// To control buffer switching and for other communication purposes this implementation uses some TRAX registers. It is safe since HW TRAX tracing
// can not be used along with application tracing feature so these registers are freely readable/writeable via JTAG from host and via ERI from ESP32 cores.
// Overhead of this implementation on target CPU is produced only by allocating/managing buffers and copying of data.
// On the host side special OpenOCD command must be used to read trace data.
// 2. TRAX Registers layout
// ========================
// This module uses two TRAX HW registers to communicate with host SW (OpenOCD).
// - Control register uses TRAX_DELAYCNT as storage. Only lower 24 bits of TRAX_DELAYCNT are writable. Control register has the following bitfields:
// 14..0 bits - actual length of user data in trace memory block. Target updates it every time it fills memory block and exposes it to host.
// Host writes zero to this field when it finishes reading exposed block;
// 21..15 bits - trace memory block transfer ID. Block counter. It can overflow. Updated by target, host should not modify it. Actually can be 2 bits;
// 22 bit - 'host data present' flag. If set to one there is data from host, otherwise - no host data;
// 23 bit - 'host connected' flag. If zero then host is not connected and tracing module works in post-mortem mode, otherwise in streaming mode;
// - Status register uses TRAX_TRIGGERPC as storage. If this register is not zero then current CPU is changing TRAX registers and
// this register holds address of the instruction which application will execute when it finishes with those registers modifications.
// See 'Targets Connection' setion for details.
// 3. Modes of operation
// =====================
// This module supports two modes of operation:
// - Post-mortem mode. This is the default mode. In this mode application tracing module does not check whether host has read all the data from block
// exposed to it and switches block in any case. The mode does not need host interaction for operation and so can be useful when only the latest
// trace data are necessary, e.g. for analyzing crashes. On panic the latest data from current input block are exposed to host and host can read them.
// It can happen that system panic occurs when there are very small amount of data which are not exposed to host yet (e.g. crash just after the
// TRAX block switch). In this case the previous 16KB of collected data will be dropped and host will see the latest, but very small piece of trace.
// It can be insufficient to diagnose the problem. To avoid such situations there is menuconfig option
// CONFIG_APPTRACE_POSTMORTEM_FLUSH_THRESH
// which controls the threshold for flushing data in case of panic.
// - Streaming mode. Tracing module enters this mode when host connects to target and sets respective bits in control registers (per core).
// In this mode before switching the block tracing module waits for the host to read all the data from the previously exposed block.
// On panic tracing module also waits (timeout is configured via menuconfig via CONFIG_APPTRACE_ONPANIC_HOST_FLUSH_TMO) for the host to read all data.
// 4. Communication Protocol
// =========================
// 4.1 Trace Memory Blocks
// -----------------------
// Communication is controlled via special register. Host periodically polls control register on each core to find out if there are any data available.
// When current input memory block is filled it is exposed to host and 'block_len' and 'block_id' fields are updated in the control register.
// Host reads new register value and according to it's value starts reading data from exposed block. Meanwhile target starts filling another trace block.
// When host finishes reading the block it clears 'block_len' field in control register indicating to the target that it is ready to accept the next one.
// If the host has some data to transfer to the target it writes them to trace memory block before clearing 'block_len' field. Then it sets
// 'host_data_present' bit and clears 'block_len' field in control register. Upon every block switch target checks 'host_data_present' bit and if it is set
// reads them to down buffer before writing any trace data to switched TRAX block.
// 4.2 User Data Chunks Level
// --------------------------
// Since trace memory block is shared between user data chunks and data copying is performed on behalf of the API user (in its normal context) in
// multithreading environment it can happen that task/ISR which copies data is preempted by another high prio task/ISR. So it is possible situation
// that task/ISR will fail to complete filling its data chunk before the whole trace block is exposed to the host. To handle such conditions tracing
// module prepends all user data chunks with header which contains allocated buffer size and actual data length within it. OpenOCD command
// which reads application traces reports error when it reads incomplete user data block.
// Data which are transffered from host to target are also prepended with a header. Down channel data header is simple and consists of one two bytes field
// containing length of host data following the header.
// 4.3 Data Buffering
// ------------------
// It takes some time for the host to read TRAX memory block via JTAG. In streaming mode it can happen that target has filled its TRAX block, but host
// has not completed reading of the previous one yet. So in this case time critical tracing calls (which can not be delayed for too long time due to
// the lack of free memory in TRAX block) can be dropped. To avoid such scenarios tracing module implements data buffering. Buffered data will be sent
// to the host later when TRAX block switch occurs. The maximum size of the buffered data is controlled by menuconfig option
// CONFIG_APPTRACE_PENDING_DATA_SIZE_MAX.
// 4.4 Target Connection/Disconnection
// -----------------------------------
// When host is going to start tracing in streaming mode it needs to put both ESP32 cores into initial state when 'host connected' bit is set
// on both cores. To accomplish this host halts both cores and sets this bit in TRAX registers. But target code can be halted in state when it has read control
// register but has not updated its value. To handle such situations target code indicates to the host that it is updating control register by writing
// non-zero value to status register. Actually it writes address of the instruction which it will execute when it finishes with
// the registers update. When target is halted during control register update host sets breakpoint at the address from status register and resumes CPU.
// After target code finishes with register update it is halted on breakpoint, host detects it and safely sets 'host connected' bit. When both cores
// are set up they are resumed. Tracing starts without further intrusion into CPUs work.
// When host is going to stop tracing in streaming mode it needs to disconnect targets. Disconnection process is done using the same algorithm
// as for connecting, but 'host connected' bits are cleared on ESP32 cores.
// 5. Module Access Synchronization
// ================================
// Access to internal module's data is synchronized with custom mutex. Mutex is a wrapper for portMUX_TYPE and uses almost the same sync mechanism as in
// vPortCPUAcquireMutex/vPortCPUReleaseMutex. The mechanism uses S32C1I Xtensa instruction to implement exclusive access to module's data from tasks and
// ISRs running on both cores. Also custom mutex allows specifying timeout for locking operation. Locking routine checks underlaying mutex in cycle until
// it gets its ownership or timeout expires. The differences of application tracing module's mutex implementation from vPortCPUAcquireMutex/vPortCPUReleaseMutex are:
// - Support for timeouts.
// - Local IRQs for CPU which owns the mutex are disabled till the call to unlocking routine. This is made to avoid possible task's prio inversion.
// When low prio task takes mutex and enables local IRQs gets preempted by high prio task which in its turn can try to acquire mutex using infinite timeout.
// So no local task switch occurs when mutex is locked. But this does not apply to tasks on another CPU.
// WARNING: Priority inversion can happen when low prio task works on one CPU and medium and high prio tasks work on another.
// WARNING: Care must be taken when selecting timeout values for trace calls from ISRs. Tracing module does not care about watchdogs when waiting
// on internal locks and for host to complete previous block reading, so if timeout value exceeds watchdog's one it can lead to the system reboot.
// 6. Timeouts
// ===========
// Timeout mechanism is based on xthal_get_ccount() routine and supports timeout values in microseconds.
// There are two situations when task/ISR can be delayed by tracing API call. Timeout mechanism takes into account both conditions:
// - Trace data are locked by another task/ISR. When wating on trace data lock.
// - Current TRAX memory input block is full when working in streaming mode (host is connected). When waiting for host to complete previous block reading.
// When wating for any of above conditions xthal_get_ccount() is called periodically to calculate time elapsed from trace API routine entry. When elapsed
// time exceeds specified timeout value operation is canceled and ESP_ERR_TIMEOUT code is returned.
#include"sdkconfig.h"
#include"soc/soc.h"
#include"soc/dport_access.h"
#if CONFIG_IDF_TARGET_ESP32
#include"soc/dport_reg.h"
#elif CONFIG_IDF_TARGET_ESP32S2
#include"soc/sensitive_reg.h"
#endif
#include"eri.h"
#include"trax.h"
#include"esp_log.h"
#include"esp_app_trace_membufs_proto.h"
#include"esp_app_trace_port.h"
// TODO: move these (and same definitions in trax.c to dport_reg.h)
// In general tracing goes in the following way. User application requests tracing module to send some data by calling esp_apptrace_buffer_get(),
// module allocates necessary buffer in current input trace block. Then user fills received buffer with data and calls esp_apptrace_buffer_put().
// When current input trace block is filled with app data it is exposed to host and the second block becomes input one and buffer filling restarts.
// While target application fills one TRAX block host reads another one via JTAG.
// This module also allows communication in the opposite direction: from host to target. As it was said ESP32 and host can access different TRAX blocks
// simultaneously, so while target writes trace data to one block host can write its own data (e.g. tracing commands) to another one then when
// blocks are switched host receives trace data and target receives data written by host application. Target user application can read host data
// by calling esp_apptrace_read() API.
// To control buffer switching and for other communication purposes this implementation uses some TRAX registers. It is safe since HW TRAX tracing
// can not be used along with application tracing feature so these registers are freely readable/writeable via JTAG from host and via ERI from ESP32 cores.
// Overhead of this implementation on target CPU is produced only by allocating/managing buffers and copying of data.
// On the host side special OpenOCD command must be used to read trace data.
// 2. TRAX Registers layout
// ========================
// This module uses two TRAX HW registers and one Performance Monitor register to communicate with host SW (OpenOCD).
// - Control register uses TRAX_DELAYCNT as storage. Only lower 24 bits of TRAX_DELAYCNT are writable. Control register has the following bitfields:
// CRC indicator (0xA55A) is used to distinguish valid CRC values from other data that might be in the register.
// CRC16 is calculated over the entire exposed block and is updated every time a block is exposed to the host.
// This allows the host to verify data integrity of the received trace data.
// 3. Modes of operation
// =====================
// This module supports two modes of operation:
// - Post-mortem mode. This is the default mode. In this mode application tracing module does not check whether host has read all the data from block
// exposed to it and switches block in any case. The mode does not need host interaction for operation and so can be useful when only the latest
// trace data are necessary, e.g. for analyzing crashes. On panic the latest data from current input block are exposed to host and host can read them.
// It can happen that system panic occurs when there are very small amount of data which are not exposed to host yet (e.g. crash just after the
// TRAX block switch). In this case the previous 16KB of collected data will be dropped and host will see the latest, but very small piece of trace.
// It can be insufficient to diagnose the problem. To avoid such situations there is menuconfig option
// CONFIG_APPTRACE_POSTMORTEM_FLUSH_THRESH
// which controls the threshold for flushing data in case of panic.
// - Streaming mode. Tracing module enters this mode when host connects to target and sets respective bits in control registers (per core).
// In this mode before switching the block tracing module waits for the host to read all the data from the previously exposed block.
// On panic tracing module also waits (timeout is configured via menuconfig via CONFIG_APPTRACE_ONPANIC_HOST_FLUSH_TMO) for the host to read all data.
// 4. Communication Protocol
// =========================
// 4.1 Trace Memory Blocks
// -----------------------
// Communication is controlled via special register. Host periodically polls control register on each core to find out if there are any data available.
// When current input memory block is filled it is exposed to host and 'block_len' and 'block_id' fields are updated in the control register.
// Host reads new register value and according to it's value starts reading data from exposed block. Meanwhile target starts filling another trace block.
// When host finishes reading the block it clears 'block_len' field in control register indicating to the target that it is ready to accept the next one.
// If the host has some data to transfer to the target it writes them to trace memory block before clearing 'block_len' field. Then it sets
// 'host_data_present' bit and clears 'block_len' field in control register. Upon every block switch target checks 'host_data_present' bit and if it is set
// reads them to down buffer before writing any trace data to switched TRAX block.
// 4.2 User Data Chunks Level
// --------------------------
// Since trace memory block is shared between user data chunks and data copying is performed on behalf of the API user (in its normal context) in
// multithreading environment it can happen that task/ISR which copies data is preempted by another high prio task/ISR. So it is possible situation
// that task/ISR will fail to complete filling its data chunk before the whole trace block is exposed to the host. To handle such conditions tracing
// module prepends all user data chunks with header which contains allocated buffer size and actual data length within it. OpenOCD command
// which reads application traces reports error when it reads incomplete user data block.
// Data which are transffered from host to target are also prepended with a header. Down channel data header is simple and consists of one two bytes field
// containing length of host data following the header.
// 4.3 Target Connection/Disconnection
// -----------------------------------
// When host is going to start tracing in streaming mode it needs to put both ESP32 cores into initial state when 'host connected' bit is set
// on both cores. To accomplish this host halts both cores and sets this bit in TRAX registers. But target code can be halted in state when it has read control
// register but has not updated its value. To handle such situations target code indicates to the host that it is updating control register by writing
// non-zero value to status register. Actually it writes address of the instruction which it will execute when it finishes with
// the registers update. When target is halted during control register update host sets breakpoint at the address from status register and resumes CPU.
// After target code finishes with register update it is halted on breakpoint, host detects it and safely sets 'host connected' bit. When both cores
// are set up they are resumed. Tracing starts without further intrusion into CPUs work.
// When host is going to stop tracing in streaming mode it needs to disconnect targets. Disconnection process is done using the same algorithm
// as for connecting, but 'host connected' bits are cleared on ESP32 cores.
// 5. Module Access Synchronization
// ================================
// Access to internal module's data is synchronized with custom mutex. Mutex is a wrapper for portMUX_TYPE and uses almost the same sync mechanism as in
// vPortCPUAcquireMutex/vPortCPUReleaseMutex. The mechanism uses S32C1I Xtensa instruction to implement exclusive access to module's data from tasks and
// ISRs running on both cores. Also custom mutex allows specifying timeout for locking operation. Locking routine checks underlying mutex in cycle until
// it gets its ownership or timeout expires. The differences of application tracing module's mutex implementation from vPortCPUAcquireMutex/vPortCPUReleaseMutex are:
// - Support for timeouts.
// - Local IRQs for CPU which owns the mutex are disabled till the call to unlocking routine. This is made to avoid possible task's prio inversion.
// When low prio task takes mutex and enables local IRQs gets preempted by high prio task which in its turn can try to acquire mutex using infinite timeout.
// So no local task switch occurs when mutex is locked. But this does not apply to tasks on another CPU.
// WARNING: Priority inversion can happen when low prio task works on one CPU and medium and high prio tasks work on another.
// WARNING: Care must be taken when selecting timeout values for trace calls from ISRs. Tracing module does not care about watchdogs when waiting
// on internal locks and for host to complete previous block reading, so if timeout value exceeds watchdog's one it can lead to the system reboot.
// 6. Timeouts
// ===========
// Timeout mechanism is based on xthal_get_ccount() routine and supports timeout values in microseconds.
// There are two situations when task/ISR can be delayed by tracing API call. Timeout mechanism takes into account both conditions:
// - Trace data are locked by another task/ISR. When waiting on trace data lock.
// - Current TRAX memory input block is full when working in streaming mode (host is connected). When waiting for host to complete previous block reading.
// When waiting for any of above conditions xthal_get_ccount() is called periodically to calculate time elapsed from trace API routine entry. When elapsed
// time exceeds specified timeout value operation is canceled and ESP_ERR_TIMEOUT code is returned.
#define SEGGER_SYSVIEW_ID_BASE SOC_DROM_LOW // Default value for the lowest Id reported by the application. Can be overridden by the application via SEGGER_SYSVIEW_SetRAMBase(). (i.e. 0x20000000 when all Ids are an address in this RAM)
#define SEGGER_SYSVIEW_ID_SHIFT 0 // Number of bits to shift the Id to save bandwidth. (i.e. 2 when Ids are 4 byte aligned)
#define SEGGER_SYSVIEW_GET_INTERRUPT_ID() ((*(U32 *)(0xE000ED04)) & 0x1FF) // Get the currently active interrupt Id. (i.e. read Cortex-M ICSR[8:0] = active vector)
#define SEGGER_SYSVIEW_GET_INTERRUPT_ID() (__get_IPSR()) // Workaround for IAR, which might do a byte-access to 0xE000ED04. Read IPSR instead.
#else
#define SEGGER_SYSVIEW_GET_INTERRUPT_ID() ((*(U32 *)(0xE000ED04)) & 0x3F) // Get the currently active interrupt Id. (i.e. read Cortex-M ICSR[5:0] = active vector)
#endif
#else
#define SEGGER_SYSVIEW_GET_INTERRUPT_ID() SEGGER_SYSVIEW_X_GetInterruptId() // Get the currently active interrupt Id from the user-provided function.
// Description for a circular buffer (also called "ring buffer")
// which is used as up-buffer (T->H)
//
typedefstruct{
constchar*sName;// Optional name. Standard names so far are: "Terminal", "SysView", "J-Scope_t4i4"
char*pBuffer;// Pointer to start of buffer
unsignedSizeOfBuffer;// Buffer size in bytes. Note that one byte is lost, as this implementation does not fill up the buffer in order to avoid the problem of being unable to distinguish between full and empty.
unsignedWrOff;// Position of next item to be written by either target.
volatileunsignedRdOff;// Position of next item to be read by host. Must be volatile since it may be modified by host.
unsignedFlags;// Contains configuration flags
}SEGGER_RTT_BUFFER_UP;
//
// Description for a circular buffer (also called "ring buffer")
// which is used as down-buffer (H->T)
//
typedefstruct{
constchar*sName;// Optional name. Standard names so far are: "Terminal", "SysView", "J-Scope_t4i4"
char*pBuffer;// Pointer to start of buffer
unsignedSizeOfBuffer;// Buffer size in bytes. Note that one byte is lost, as this implementation does not fill up the buffer in order to avoid the problem of being unable to distinguish between full and empty.
volatileunsignedWrOff;// Position of next item to be written by host. Must be volatile since it may be modified by host.
unsignedRdOff;// Position of next item to be read by target (down-buffer).
unsignedFlags;// Contains configuration flags
}SEGGER_RTT_BUFFER_DOWN;
//
// RTT control block which describes the number of buffers available
// as well as the configuration for each buffer
//
//
typedefstruct{
characID[16];// Initialized to "SEGGER RTT"
intMaxNumUpBuffers;// Initialized to SEGGER_RTT_MAX_NUM_UP_BUFFERS (type. 2)
intMaxNumDownBuffers;// Initialized to SEGGER_RTT_MAX_NUM_DOWN_BUFFERS (type. 2)
SEGGER_RTT_BUFFER_UPaUp[SEGGER_RTT_MAX_NUM_UP_BUFFERS];// Up buffers, transferring information up from target via debug probe to host
SEGGER_RTT_BUFFER_DOWNaDown[SEGGER_RTT_MAX_NUM_DOWN_BUFFERS];// Down buffers, transferring information down from host via debug probe to target
#define SEGGER_SYSVIEW_INFO_SIZE 9 // Minimum size, which has to be reserved for a packet. 1-2 byte of message type, 0-2 byte of payload length, 1-5 bytes of timestamp.
#define SEGGER_SYSVIEW_QUANTA_U32 5 // Maximum number of bytes to encode a U32, should be reserved for each 32-bit value in a packet.
#define SEGGER_SYSVIEW_LOG (0u)
#define SEGGER_SYSVIEW_WARNING (1u)
#define SEGGER_SYSVIEW_ERROR (2u)
#define SEGGER_SYSVIEW_FLAG_APPEND (1u << 6)
#define SEGGER_SYSVIEW_PREPARE_PACKET(p) (p) + 4
//
// SystemView events. First 32 IDs from 0 .. 31 are reserved for these
/*************************** End of file ****************************/
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.
