temperature_sensor: Fix issue that have conflict with phy / Fix phy pwdet and tsens power cannot be set twice issue (v4.4)
See merge request espressif/esp-idf!25253
For certain data lengths, the last input descriptor was not getting appended
correctly and hence the EOF flag in the DMA descriptor link list was
set at incorrect location. This was resulting in the peripheral being
stalled expecting more data and eventually the code used to timeout
waiting for the AES completion interrupt.
Required configs for this issue:
CONFIG_MBEDTLS_HARDWARE_AES
CONFIG_SOC_AES_SUPPORT_DMA
This observation is similar to the issue reported in:
https://github.com/espressif/esp-idf/issues/10647
To recreate this issue, start the AES-GCM DMA operation with data length
12280 bytes and this should stall the operation forever.
In this fix, we are tracing the entire descriptor list and then appending the
extra bytes descriptor at correct position (as the last node).
DMA operation completion must wait until the last DMA descriptor
ownership has been changed to hardware, that is hardware is completed
the write operation for entire data. Earlier for the hardware GCM case,
the first DMA descriptor was checked and it could have resulted in some
race condition for non interrupt (MBEDTLS_AES_USE_INTERRUPT disabled) case.
- Support BLE RX error packet count record
- Fixed instant setting for LLC procedures with instants
- Fixed adv random delay when adv interval is less than 20ms
- Support BLE RX error packet count record
- Fixed adv random delay when adv interval is less than 20ms
- Fixed adv random address setting when owner address type is public
1. Fix WiFi not working with Tsens on ESP32S2
2. WIFI RX multipath optimization for all chips
3. BLE TX sideband optimization for C3/S3
4. Optimize ht40 tx side band issue for esp32
1: reset p_scb->avdt_handle in cleanup function.
2: cancel comparing p_scb->codec_type and p_scb->seps[xx].codec_type to
send the error INVALID_CODEC_TYPE.
Previously, "soc/chip_revision.h" contained a static assert to check that the
CONFIG_ESP_REV_MIN_FULL <= CONFIG_ESP_REV_MAX_FULL. There are two issues with
this assert:
- Contained in a header file, so it is only compiled if the "chip_revision.h"
is included somewhere
- CONFIG_ESP_REV_MIN_FULL and CONFIG_ESP_REV_MAX_FULL are defined in
"esp_hw_support", which is a G0 component. This creates a reverse dependency
of G0 on G1.
This commit moves the static assert "revision.c" in "esp_hw_support"
1. Moves the location of null data frame TX to before channel switch during
offchannel action frame TX req.
2. Reverts Send wake up and sleep null between scanning.
Fix crash in sending new RRM neighbour report requests by removing
the call to neighbour report request timeout callback in case of
already ongoing neighbour report request timer.
1. Fix the LR rate set fail for espnow and 80211 tx
2. Fixed the RX error when softAP/station and ESP-NOW both encrypted,
and the ESP-NOW peer address is equal to the connection peer address
- For ESP32 | SPIRAM_MALLOC_ALWAYSINTERNAL=0
- Forced `esp_timer_create` to allocate resource from the internal memory
- WiFi/BT coexistence will sometimes arm/disarm timers from an ISR
where flash may be disabled. This can lead to a cache-based
exception as the timer instance will be located in the PSRAM.
Follows the approach used in Initialise-Idf.ps1 created by the tools
installer. This is the closes equivalent of "alias" used in export.bat
Closes https://github.com/espressif/esp-idf/issues/9849
SHA hardware DMA mode calculation had off-by-one error for specific
input lengths. This was causing last chunk of the input data not being
fed to the hardware accelerator and hence resulting in an incorrect
final result.
Closes: https://github.com/espressif/esp-idf/issues/11915
Current version of the test is using "git-submodule foreach", which
requires submodules to be initialized. Non-initialized submodules are
ignored. Our CI is not performing submodule initialization, but instead
it only downloads the submodule content in tools/ci/ci_fetch_submodule.py
from cache and copies it into the submodule path.
Since we already know the submodule path from .gitconfig, we can use it
as argument to git-ls-tree and avoid calling git-submodule at all. This
allows to perform the test even if the submodules are not initialization
and also it makes the code simpler.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
* Update submodule: git log --oneline 8290c3b8f2adaf82aa45ec992b87f16205f2689b..4f24c9baf9101634b7c690802f424b197b3bb685
Detailed description of the changes:
- lower the dhcp discover and request retry backoff time (esp-lwip@4f24c9ba)
- netdb:fixed bug for getaddrinfo returns null when IPV4 mapped address (esp-lwip@a4d70c7e)
1. Discard commit frame received at confirmed state in SAE STA
2. Bugfix NVS get values for sae pwe
3. Bugfix memory leak caused by assoc retry timer and assoc IE
Update wifi libs with below fixes -
1. Bugfixes in Initiator and Responder mode
2. Fix wrong RTT value in first FTM procedure without connection
3. Update FTM calibration values for ESP32S2, S3 and C3
4. Update distance estimation logic
5. Add some useful command parameters in FTM example
6. Fix bug when number of FTM measurement frames received is more
than (number_of_brusts * FTMs per brust).
Co-authored-by: Sarvesh Bodakhe <sarvesh.bodakhe@espressif.com>
- Earlier, some intermediate return values were not stored and returned,
thus incorrect return values used to get transmitted to the upper layer of APIs.
- Also, zeroised the output buffer in case of error condition.
1. Update wifi security mode
2. Add check for memory allocation in tx buffers
3. Fix association refused temporarily comeback time set to zero issue
4. Vnd ie callback can be set to null
Some APs are configured to hide the SSID, the length field of the SSID element
in the Beacon frame is set to 0. This can cause incorrect parsing of the Beacon
by the Wi-Fi MAC hardware.
Some APs send two beacon frames with different BSSID in a TBTT cycle. After
correctly parsing the beacon of the associated AP, it continue to receive the
other beacon frame, which will cause the MAC to remain in a wait RX/TXING
state, blocking the Wi-Fi go to sleep.
If CONFIG_SPIRAM_USE_MALLOC is enabled, and cache is disabled when GPIO ISR is triggered,
it would lead to Guru Meditation Error due to "Cache disabled but cached memory region accessed".
Closes https://github.com/espressif/esp-idf/issues/11876
1) Fix issue during split scan to allow for data tx.
2) Fix issue when parsing wpa_ie to set correct authmode when AP
supports both WPA_EAP and WPA_EAP_SHA256 authmode.
Closes https://github.com/espressif/esp-idf/issues/11202
3) Fix an occasional crash during sta roam.
4) Add home_channel_dwell_time to wifi_scan_config_t. This allows
configuration of the time spent between scanning consecutive
channels for tx.
5) Adds a obss scan timer disarm when a sta disconnects from an AP
bt: fix the issue that BLE scan uses high priority incorrectly and causes Wi-Fi unable to work normally on ESP32-C3 and ESP32-S3(backport v4.4)
See merge request espressif/esp-idf!24405
Fix crash due to premature deallocation of neighbour report elements
by scan_done. Post event to btm_rrm_t task to handle scan_done serially
rather than when btm_rrm_t task is processing btm request rx frame.
1. Fixed LC_AFH_UPDATE_IND has not benn processed causing memory exhaustion
2. Fixed no free elt in prog push
3. Fixed disconnect due to sniff with error Dsniff
4. Fixed the problem that the host continued to send ACL data to the controller after disconnection, which caused the connection to fail again
Early log strings used by this component are placed in DRAM.
Disabling these logs saves ~5KB of internal memory
Signed-off-by: Vikram <vikram.dattu@espressif.com>
With the default APP_RETRIEVE_LEN_ELF_SHA setting, core dump files only have a
truncated ELF SHA256 in them. Account for this when comparing the core dump SHA
with the app ELF SHA.
The comment says it returns the "SHA256 hash of the input ELF file", but this is
not true - it was the SHA256 hash of the output ELF file. As the parser may
change some bytes around in minor ways, these were often not the same.
The check that the app ELF file SHA256 matches the one stored in the core dump
would never fail, leading to gdb loading the wrong ELF file and either crashing
or producing misleading debug information.
Specifics:
The note_sec.name field was incorrectly read back as b'ESP_CORE_DUMP_INFO\x00E',
because the namesz length includes the terminating NUL byte and possible junk
padding bytes:
https://github.com/espressif/esp-idf/blob/master/components/espcoredump/src/core_dump_elf.c#L212
In addition, as 'note_sec.name' is a bytes object Python 3 would have never
successfully compared it with a string.
ESP32S2/C3/S3: fixed S2 dangerous power parameters in sleep modes and support S2/C3/S3 different sleep mode(v4.4)
See merge request espressif/esp-idf!23758
1 Fixed disconnection delay on peripheral when slave latency is not zero
2 Fixed LLCP info init for central and peripheral
3 Fixed sent cmd status evt twice when process disconnect cmd
Conflicts:
- protobuf-c submodule version and hash changed to v1.4.0
- removed pytest dependency
This adds SBOM information for submodules, which are not managed
by Espressif. Meaning there is no fork for them in the espressif
namespace. Other submodules should add sbom.yml manifest file to
the root of their git repository.
The SBOM information for submodules is stored in the .gitmodules file.
Each SBOM related variable has the "sbom-" prefix and the following
variables may be used:
sbom-version:
submodule version
sbom-cpe:
CPE record if available in NVD. This will be used by the SBOM
tool to check for possible submodule vulnerabilities. The
version in the CPE can be replaced with the "{}" placeholder,
which will be replaced by the "sbom-version" value from above.
sbom-supplier:
Person or organization who is providing the submodule.
It has to start with "Person:" or "Organization:" prefix
as required by the SPDX-2.2 standard.
sbom-url:
URL to the project if exists, e.g. github.
sbom-description:
Project description.
sbom-hash:
Submodule SHA as recorded in the git-tree. This field is used by
CI to check that the submodule checkout hash and info in .gitmodules
are in sync. IOW if submodule is updated and it has SBOM info in
.gitmodules, the .gitmodules has to be updated too. The test is
part of this commit. The checkout has of the submodule can be found
by using "git submodule status".
Example for micro-ecc submodule
---8<---
[submodule "components/bootloader/subproject/components/micro-ecc/micro-ecc"]
path = components/bootloader/subproject/components/micro-ecc/micro-ecc
url = ../../kmackay/micro-ecc.git
sbom-version = 1.0
sbom-cpe = cpe:2.3:a:micro-ecc_project:micro-ecc:{}:*:*:*:*:*:*:*
sbom-supplier = Person: Ken MacKay
sbom-url = https://github.com/kmackay/micro-ecc
sbom-description = A small and fast ECDH and ECDSA implementation for 8-bit, 32-bit, and 64-bit processors
sbom-hash = d037ec89546fad14b5c4d5456c2e23a71e554966
---8<---
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
bt: Fixed the inconsistency between the indicator event received by the HF application layer and the actually received indicator(v4.4)
See merge request espressif/esp-idf!23562
bt: Fixed the issue that the a2dp source would not send the media start command due to the connection initiated by the peer device(v4.4)
See merge request espressif/esp-idf!23555
This extends information provided in the project_description.json file.
Newly added information can be used in the SBOM generating tool and
also to improve hints regarding the the component dependency issues.
Added fields
version:
This adds versioning to the project_description.json file,
so it's easy to identify if it contains the required information.
project_version:
Can be used as a version for the resulting binary e.g. `hello_world.bin`.
idf_path:
This one is probably not necessary, but it allows tools to run even without
esp-idf environment exported(e.g. export.sh).
c_compiler:
The `CMAKE_C_COMPILER` value with full path to the compiler binary. This can
be used to get information about toolchain, which was used to build the project.
common_component_reqs:
List of common components as presented in cmake's __COMPONENT_REQUIRES_COMMON
and set in tools/cmake/build.cmake:__build_init().
build_component_info:
Detailed information about components used during build. It's a
dictionary with the component name as a key and each component has
a dictionary with detailed information. Following is an example for
the efuse component.
"efuse": {
"alias": "idf::efuse",
"target": "___idf_efuse",
"prefix": "idf",
"dir": "/home/fhrbata/work/esp-idf/components/efuse",
"type": "LIBRARY",
"lib": "__idf_efuse",
"reqs": [],
"priv_reqs": [ "bootloader_support", "soc", "spi_flash" ],
"managed_reqs": [],
"managed_priv_reqs": [],
"file": "/home/fhrbata/work/blink/build/esp-idf/efuse/libefuse.a",
"sources": [ "/home/fhrbata/work/esp-idf/components/efuse/esp32s3/esp_efuse_table.c", ... ],
"include_dirs": [ "include", "esp32s3/include" ]
}
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Currently make_json_list() returns '[ "" ]' for empty cmake list. Fix this
so empty json list is returned instead.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
The number of the DMA descriptors allocated for certain length (e.g.,
8176) were not sufficient (off by 1 error). This used to result in the
dynamic memory corruption as the region was modified beyond the
allocated range.
This change fixes the DMA descriptor calculation part and allocates
sufficient DMA descriptors based on the data length alignment considerations.
Test has also been added to cover the specific scenario in the CI.
Closes https://github.com/espressif/esp-idf/issues/11310
According to the posix standard localtime/mktime should use timezone information as though localtime/mktime() calls tzset(),
but this is not the case in older versions of Newlib.
Closes https://github.com/espressif/esp-idf/issues/11455
Fix the bug that the iPhone disconnects immediately after connecting when BLE and wifi coexist (backport v4.4)
See merge request espressif/esp-idf!23802
Use Root certificate (`DigiCert Global Root G2`) for the
`dl.espressif.com` and `espressif.com` test endpoints.
This fixes the test failure introduced due to renewal of
the intermediate certificate.
This fixes a subtle bug in which ESP_ERR_DPP_TX_FAILURE errors would
call esp_supp_dpp_stop_listen which sets the s_dpp_stop_listening flag
to true. Subsequent attempts to restart listening with
esp_supp_dpp_start_listen then only attempt to listen once more for
500ms before reading the s_dpp_stop_listening flag again and giving up.
This contributes greatly to #10615, but the fix here is still largely
a work-around as it sometimes requires manually retrying a couple times
before it works. Without this fix, any number of retries by
deinit/init again will seemingly not work as the retries for currently
unknown reasons.
Signed-off-by: Shreyas Sheth <shreyas.sheth@espressif.com>
Closes https://github.com/espressif/esp-idf/pull/10865
Inadequate locking in the esp_timer component allowed corruption
of the s_timers linked list:
1. timer_armed(timer) returns false
2. another task arms the timer and adds it to s_timers
3. the list is locked
4. the timer is inserted into s_timers again
The last step results in a loop in the s_timers list, which causes
an infinite loop when iterated. This change always locks the
list before checking if the timer is already armed avoiding
the data race.
eFuse module has a hardware bug.
It is related to ESP32-C3, C6, S3, H2 chips:
- BLOCK9 (BLOCK_KEY5) can not be used by XTS_AES keys.
For H2 chips, the BLOCK9 (BLOCK_KEY5) can not be used by ECDSA keys.
S2 does not have such a hardware bug.
esp_hw_support: Update the memory ptr location/property checks to include the unused DCACHE added to DRAM (v4.4)
See merge request espressif/esp-idf!23269
- As per the memory block diagram for ESP32-S3, the
internal memory address ranges as follows:
DRAM: 0x3FC88000 (== SOC_MEM_INTERNAL_LOW) <-> 0x3FCF0000
IRAM: 0x40378000 <-> 0x403E0000 (== SOC_MEM_INTERNAL_HIGH)
- to acknowledge the unused DCACHE added to DRAM for ESP32-S3
- For ESP32-S3, when the DCACHE size is set to 16 kB, the unused 48 kB is added to
the heap in 2 blocks of 32 kB (from 0x3FCF0000) and 16 kB (from 0x3C000000).
- But, if we try allocating memory from the 16 kB block and run an `esp_ptr_internal`
check on that memory pointer, it fails as the address block from 0x3C000000
corresponds to the external memory symbols SOC_DROM_LOW and SOC_EXTRAM_DATA_LOW.
(E.g. freertos - If the IDLE task stack buffer gets allocated from this region,
the firmware will abort due to this failure).
- Thus, the checks `esp_ptr_internal`, `esp_ptr_in_drom` and `esp_ptr_byte_accessible`
have been updated to acknowledge this memory as a part of the DRAM.
Co-authored-by: Mahavir Jain <mahavir@espressif.com>
1. Fixed crash after controller disable and re-enable
2. Fixed the crash caused by processing the HCI_Read_Remote_Extented_Features command in the non-connected state
3. Fixed disconnection due to not handling lmp_unsniff_req in LC_WAIT_SNIFF_SUB_RSP state
4. Fixed crash caused by supervision timeout greater than sniff interval
Closes https://github.com/espressif/esp-idf/issues/11164
Closes https://github.com/espressif/esp-idf/issues/10835
Fixes the custom bootloader README.md so that the example output matches
what will actually be output by default in the custom bootloader.
Signed-off-by: hasheddan <georgedanielmangum@gmail.com>
bugfix: Fixed the crash of LoadProhibited caused by invalid operation on list node in handling hci_hardware_error event (v4.4)
See merge request espressif/esp-idf!23118
1. fix sta auth failed but softap shows it connected issue
2. fix ftm procedure with peer failed status 4 issue
3. send ftm frames immediately
4. send null data when state change from association to run
5. docs: add some details for wifi scan description
1. Disable SA query timers when station disconnect and other SA query related improvements
2. Send appropriate reason code in 4 way handshake failure
3. Send deauth while going from assoc state to init, if reason is assoc timeout
1. Fix deep sleep wakeup IOs can not be unhold issue
2. Correct hold related APIs' description
3. Fix gpio_force_hold_all API
docs: Add GPIO wakeup source to sleep_modes doc for ESP32C3
1. Fix EXT0 wakeup pin error on ESP32: GPIO3 is not a RTC IO, change to use GPIO25.
2. Add ESP_ERROR_CHECK to explicitly show the runtime error
3. Improve example README
esp_efuse_utility_load_efuses_from_flash() read emul_efuse
as an encrypted partition, but that is not correct,
this partition was never encrypted.
Need to read it as not encrypted partition.
Fxed the case: If FE is already on then EFUSE VIRT mode can work with it.
Closes https://github.com/espressif/esp-idf/issues/10929
Some of the esp_sntp_...() APIs that wrap lwip's SNTP
module use tcpip_callback() to execute the lwip functionality
in the correct state (either with locked TCP/IP core,
or within the TCP/IP thread).
tcpip_callback() however doesn't wait for completion of the callback,
which doesn't prevent from using the stack variables after destroy
if used as a parameter.
Introduced in a71fa82.
Fixed by using of tcpip_api_call() instead of the tcpip_callback().
Closes https://github.com/espressif/esp-idf/issues/10611
I the shell has `set -u` (to abort on unbound variable), sourcing
export.sh currently fails when IDF_EXPORT_QUIET or IDF_PATH is not set:
> /path/to/esp-idf/export.sh:16: IDF_EXPORT_QUIET: unbound variable
This commit sets a default empty value to those variable, as done
in 16731833fb (which forgot IDF_PATH as it's usually set, the other
variable landed later in the file).
The export.fish script exits with an exit code of 4. Thus, any shell checks that make sure the source command exits successfully always failed. This was due to the last line trying to erase the __main function. In fish, you can't erase a function using the `set` command, you can only erase variables. By removing that line the script now exits with an exit code of 0 instead of 4.
Erase __main function at the end of export.fish
Closes https://github.com/espressif/esp-idf/pull/10828
* Update submodule: git log --oneline a7abf28e02282b32479f4bbaf2d90f09d2a60f4c..6bb132e3797d5449a923804c75c57d458920f8ac
Detailed description of the changes:
- tcp_in/ooseq: Fix incorrect segment trim when FIN moved (esp-lwip@6bb132e3)
- api_msg: fix tcp_abort thread safety (esp-lwip@53a6e019)
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
1. Concurrency might cause ESP_ERR_TIMEOUT when calling uart_wait_tx_done
2. Concurrency might cause RTS line being de-assreted during tx transmission for rs485 mode
Add validations for group data cipher, pairwise cipher and AKM Suites to
ensure correct ciphers are supported by AP during 192-bit Enterprise
connections.
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
The stream buffer send-receive test preivously contained the following bugs:
- "sender" task would send 101 bytes instead of 100
- The main task would return before "sender" task sends its 101st item. Thus
the sender task would cause memory corruption when accessing "tc" structure
allocated on the main task's stack
This commit fixes and simplifies the stream buffer test.
heap: Fix erroneous value returned by heap_caps_get_allocated_size() when poisoning is enabled (backport v4.4)
See merge request espressif/esp-idf!22189
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 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)
When a USB does not support a particular string dsecriptor (e.g.,
manufacturer, product, and serial number), the string descriptors corresponding
index will be set to 0 in the device descriptor (e.g., iManufacturer, iProduct,
iString).
Previously, the Hub driver would always attempt to fetch the all three string
descriptors, thus leading an error in CHECK_SHORT_SER_STR_DESC if the device
did not support the descriptor.
This commit fixes the Hub drvier by skipping the enumeration stages of a
particular descriptor if its index is 0 (i.e., not supported by the device).
USB devices may support string descriptors in multiple languages. The supported
languages are stored in a LANGID table, which itself is a string descriptor at
index 0.
When fetching the LANGID table itself, the USB 2.0 specification does not
specify what LANGID to use, thus the Hub driver would use the default LANGID
"ENUM_LANGID". However, this would cause some devices to stall.
This commit fixes the issue by always requesting the LANGID table itself using
a LANGID of 0.
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
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.
bt:Fixed the use of invalid configuration when the peer device configures the stream, and returned an incorrect error code(v4.4)
See merge request espressif/esp-idf!21623
heap: Modify the memory type of the memory used as startup stack when memory protection is enabled (backport v4.4)
See merge request espressif/esp-idf!22171
Current esp_wifi_get_config doesn't return correct value of h2e config which will cause h2e config to be overwritten in Station connected handler.
Add one preventative condition to take care of this.
During the wifi deinit last_scan_res_used pointer is not set to 0 which will cause it be used directly after reinit.
Added changes which will set it to 0 during init and deinit.
1. add check in the gdma driver, to prevent multiple channels connecting
to the same peripheral
2. memory copy DMA ID will occupy the peripheral's DMA ID on some ESP
targets (e.g. esp32c3/s3). We should search for a free one when
install async memcpy driver.
Closes https://github.com/espressif/esp-idf/issues/10575
If memory protection is enabled on esp32c3 and esp32s3, we don't want to the heap component to see
the startup stack memory as D/IRAM but as DRAM only. Introduce a new type to make this possible in
the same fashion the regular D/IRAM regions are handled.
This commit fixes an issue where paths on Windows are case insensitive, for instance when setting the build folder its name would be converted to lowercase.
The culprit is our realpath() function, that was calling os.path.normcase() internally, since we are removing that call it makes sense to just remove the function entirely and call os.path.realpath() wherever necessary.
Closes https://github.com/espressif/esp-idf/issues/10282
This commit fixes an issue where in the ULP RISC-V I2C example causes
a spurious wakeup of the main CPU because of a Trap signal when the ULP
core does not meet the wakeup threshold values. This was due to the fact
that the RTC_CNTL_COCPU_DONE signal was being set before the
RTC_CNTL_COCPU_SHUT_RESET_EN signal which was causing the the ULP RISC-V
core to not reset properly on each cycle.
Closes https://github.com/espressif/esp-idf/issues/10301
- 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
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
This fixes an attempted fix for diram size calculation where it was counted twice, however the fix did not account for cases where iram was not fully filled with cache and therefore was of non 0 size.
Now the calculation should be correct regardless of the cache size.
Closes https://github.com/espressif/esp-idf/issues/9960
Fix expected output
Simple flash read command is not supported if Secure DL mode is enabled on the target.
Remove reference of this from the relevant docs part.
Related: https://github.com/espressif/esptool/issues/810
Related: ESPTOOL-567
Closes IDF-6468
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.
usb_host_transfer_submit_control() uses the incorrect bmRequestType direction
flag. Therefore, when doing a transfer check, all transfers were mistakenly
treated as OUT transfers (only affects transfer check and not actual transfer).
This commit fixes a race condtion bug with usb_dwc_hal_chan_request_halt()
where a channel the channel is halted if it has just completed a transfer
(i.e., finished processing a QTD with the "HOC" flag set) but the channel is
still pending interrupt handling. In this case...
- usb_dwc_hal_chan_request_halt() would simply read the channel's underlying
register, determine it is not active, not set the "halt_requested" flag, and
simply return true.
- The caller assumes of usb_dwc_hal_chan_request_halt() will assume that the
channel has halted, and may proceed to reconfigure the pipe/port
- When usb_dwc_hal_chan_decode_intr() comes to process the pending interrupt
it will simply return USB_DWC_HAL_CHAN_EVENT_CPLT not knowing a halt has been
requested.
This commit updates the implementation of usb_dwc_hal_chan_request_halt() so
that a halt is properly requested even if the underlying channel has already
physically halted.
Following the file renaming to use the "usb_dwc" prefix, this commit
updates the symbol names of those files to use the "usb_dwc" as well.
Some LL functions were also renamed so that the register name is
mentioned.
This commit updates the DWC_OTG based struct/ll/hal file names to
use the prefix "usb_dwc". This naming scheme reduces ambiguity if
another USB controller implementation is added.
As a result, "hcd.c" has been renamed to "hcd_dwc.c"
This commit removes the GPL license text from various FreeRTOS port files as it
no longer matches the licensing of FreeRTOS v10.4.3 which is distributed under
the MIT license.
This commit fixes incorrect usage of memset() in the HCD's various
_buffer_parse_...() functions. The memset was not clearing the qtd lists, and
were simply setting the first qtd to a non zero value (i.e., the length of
the QTD list).
However, no bug occurred as the subsequent _buffer_fill_...() functions would
overwrite the QTD list anyways.
When a public header contains _Static_assert or static_assert, check_public_headers.py script will detect it and report it as an issue.
Indeed, public headers shall now use ESP_STATIC_ASSERT.
I'm including <hal/uart_ll.h> in my C++ application because I need to
bypass the uart driver. The inline functions in the header file fail to
compile as C++.
All of the enums need explicit casts for conversion to/from integers.
Merges https://github.com/espressif/esp-idf/pull/10106
1.Bugfix for clear bss info when wifi stop
2.Bugfix for add clear ap list interface
3.Modify wifi scan return value.
4.Change the log level of some logs to avoid misunderstanding.
5.Fix connect fail return wrong error code issue.
6.Fix WAPI issue on gtk compability and referrence to broadcast arp pkts.
7.Support WiFi tx fragment in the crypto mode of gcmp.
8.Fix tx fragment issue that pn code is less than msdu after pn code add two for tx fragment.
9.Fixed some issues on Soft-AP power save.
10.fix invalid child issue
11.fix WIFI_EVENT_AP_STADISCONNECTED event error
12.Fix SoftAP memory leak issue.
13.Fixed sta get ap info does not return connected ssid issue.
14.Fix SoftAP recv ps-poll not update inactive timer issue.
1. Adding check for ies in match security
2. Set AP rsnxe while connecting to a AP
3. Restores station status to connected when no other AP is found for roam
4. Add config option for AP retry count
5. Fix unprotected SA Query issue
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.
User's custom data are not taken into account during the CRC calculation anymore.
Which means taht the retained mem structure is not systematically erased
on each reboot anymore.
A missing flush in the serial reader implementation for
Linux target was causing input to idf.py monitor to not
be forwarded to the application. This is fixed now.
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
spi_flash: Building a framework to enable HPM when flash works under high speed mode, take GD as an example.(backport v4.4)
See merge request espressif/esp-idf!17758
bluetooth: use non-blocking coexistence callback functions so that Wi-Fi task is not blocked by Bluetooth(backport v4.4)
See merge request espressif/esp-idf!20779
Fix issue with single bus clear counter but two I2C buses (I2C0, I2C1). The previously implemented single (static) counter would impact the second bus either if one bus has counter expiry.
Merges https://github.com/espressif/esp-idf/pull/7144
This commit adds a simple flag/check in the USB Host Library that prevents
users from submitting a transfer that is already inflight.
- A transfer is considered inflight as soon as it is submitted by calling
usb_host_transfer_submit() or usb_host_transfer_submit_control()
- An inflight transfer remains inflight up until right before its callback
is called by one of the USB Host Library handler functions.
Closes https://github.com/espressif/esp-idf/issues/8748
Non-visible configs would previously not appear in the deprecated section of the sdkconfig.h,
but non-visable configs are used in IDF (and user code) and should therefor be present.
Previous the console doc is moved from api-guide to api-reference, which
broken the URL as well, this commit added a redirect link to ensure the
old URL can still work.
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.
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
In case of `esp_http_client_read` based workflow, we cache data that is received
during fetch header stage. In case, there is URL redirection and we have to close
the connection on URL, port change then we must discard earlier cached data.
Closes AUD-4158
This commit adds the missing ESP_PLATFORM preprocessor directive to
static data structures to wrap the extra variable added for SMP locks.
Closes https://github.com/espressif/esp-idf/issues/9785
This commit fixes a bug where if an unpinned task is interrupted by a level 1
ISR that users the FPU, the FPU usage will cause the interrupted task to
become pinned to the current core.
Note: This bug was already fixed in SMP FreeRTOS in commit
d6936177. This commit simply backports the fix to IDF FreeRTOS.
Similar to the fix in gpio lower layers, USB Serial JTAG pad should be disabled when the DM and DP pins want to be used as rtcio pins.
(cherry picked from commit de0401047c)
GDB now is standalone tool separated from toolchain due to frequent updates.
Added installation tests for the new tool.
Coredump tests are changed because they were wrong, see explanation:
esp32 objdump:
40084290 <esp_crosscore_int_send_yield>:
......
/builds/espressif/esp-idf/components/esp_system/crosscore_int.c:145
4008429c: 000090 retw
With previous GDB backtrace was:
#0 0x4008429c in esp_crosscore_int_send_yield (core_id=0) at /builds/espressif/esp-idf/components/esp_system/crosscore_int.c:144
This commit fixes the backtrace with the right line number:
#0 0x4008429c in esp_crosscore_int_send_yield (core_id=0) at /builds/espressif/esp-idf/components/esp_system/crosscore_int.c:145
Other tests changes have the same cause of fixing.
Closes https://github.com/espressif/esp-idf/issues/6334
For project with reduced component list, secure boot signing key
path was not getting correctly. This change sets the secure boot
signing key path explicitly based on the relevant config option.
Closes https://github.com/espressif/esp-idf/issues/9578
Close IDFGH-8075
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.
In previous transmission(s), the TX_DONE interrupt raw bit may be raised, but never been cleared.
TX_DONE interrrupt status bit should be cleared before enabling it to check the new transmission.
Introduced in 4e09d147b11ed8a094b5858642c9f60d658ef656
Internally, disable usb serial jtag DP pin's pullup when calling gpio_ll_pullup_dis and rtcio_ll_pullup_disable
At usb serial jtag setup/install, re-enable DP pin's pullup
Closes https://github.com/espressif/esp-idf/issues/9495
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
esp_light_sleep_start() will stall the other CPU via esp_ipc_isr_stall_other_cpu(). After stalling the other CPU,
will call esp_clk_... API which themselves take locks. If the other stalled CPU is holding those locks, this will
result in a deadlock.
This commit adds a workaround calling esp_clk_private_lock() to take the lock before stalling the other CPU.
esp_clk used to be protected using _lock_t (i.e., a FreeRTOS Mutex). However, esp_clk API is current called from
from critical sections, thus mutex should not be used (as they can be blocking).
This commit updates esp_clk to use spinlocks for critical sections instead.
Note: Added a small fix to exclude esp_clk.c from bootloader builds in the
legacy build system (this is already the case in CMake).
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
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
`__COMPONENT_TARGETS` is evaluated very early when components and
component directories are added to the build, which means that all
components (including the ones which are in EXCLUDE_COMPONENTS) have
a build system target defined. The component manager was given the
list of all known components (derived from the list of targets), not
the list of components after EXCLUDE_COMPONENTS were processed.
Because of that, EXCLUDE_COMPONENTS didn't effectively exclude the
component from the consideration of the component manager.
Due to unit test, we can't specify runners, for adc related tests.
Whereas adc tests are easily influenced by board hw condition, e.g.
pullup/down value.
This commit increases the thresh to 200mV.
dl.espressif.com is now using the same root certificate as github.com.
This commit replaces the previously-used ISRG X1 root certificate
with the DigiCert Root CA certificate.
As a result, even if the certificates are not installed (as it happens
on macOS with python.org installers, if the user forgets to run
'Install Certificates.command'), the download is successful.
Related to https://github.com/espressif/esp-idf/issues/4081
Fixed calling esp_ble_get_cur_sendable_packets_num() sometimes crashes when bluetooth is disconnecting (backport v4.4)
See merge request espressif/esp-idf!20042
'idf_tools.py add-version' has new options:
--override Override tool versions with new data
--checksum-file URL or path to local file with checksum/size for artifacts
Usage e.g.:
CHECKSUM_URL=https://github.com/espressif/crosstool-NG/releases/download/esp-2021r2/crosstool-NG-esp-2021r2-checksum.sha256
idf_tools.py add-version --tool xtensa-esp32-elf --version esp-2021r2 --override --checksum-file $CHECKSUM_URL
Positional argument 'files' moved to optional argument '--artifact-file'
Add tests for add-version logic
- Fixed the performance issue of BLE sync scan in coexistence scenario when PLL track is enabledFixed 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
bt:Fixed deadlock due to wrong parameter when calling btc_transfer_context() after calling esp_bluedroid_disable()(v4.4)
See merge request espressif/esp-idf!19951
If a windowoverflow8 happened after changing the SP, the exception handler would look for
the extra save area by looking at the previous frame's SP. This SP would be a garbage value
and could cause the windowoverflow exception to write to invalid memory ares.
This commit fixes gpio_hold_en(pin) function for ESP32, where after wakeup from deep sleep, the pin gets reset to default state and stop holding the pin level.
This commit extends the heap test set by adding a test to check corruption
detection in free memory block.
For each byte of the free block memory, the test changes the value of the byte,
call multi_heap_check(), make sure that the function returns 'corruption detected'
only when comprehensive poisoning is set, restore the good value of the byte, calls
multi_heap_check() again and make sure that it returns 'OK'.
Add a call to tlsf_check_hook() in tlsf_check() that calls
multi_heap_internal_check_block_poisoning() and check the memory
of every free blocks when heap poisoning is active.
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.4)
See merge request espressif/esp-idf!19692
sizeof(time_t) was previously switched from 4 to 8, ROM functions that use
time_t or dependent types (such as "struct stat") are no longer called due as
they still treat sizeof(time_t) as 4 (see commit
24c20d18).
However, there is a ROM callpath that was left out. If putchar is the first
stdio print related call, the call path will result in cantwrite() ->
__swsetup_r() -> __smakebuf_r() -> __swhatbuf_r() using the ROM "struct stat"
(where sizeof(time_t)==4).
Instead of removing all printf related ROM newlib functions (which will result
in increased binary size), this commit adds a workaround to setup the stdio
files before any print related calls occur.
This results in cantwrite() always returning false, thus the callpath described
above never being reached.
Closes https://github.com/espressif/esp-idf/issues/9269
Closes https://github.com/espressif/esp-idf/issues/7207
The description of how the xTaskGenericNotifyWait parameter is handled in the
xTaskGenericNotifyWait() function was inaccurate.
In this commit, the description was updated to match the implementation of xTaskGenericNotifyWait().
Adding prop and lit sections to the ELF will let the debugger and the disassembler
have more info about data bytes present in the middle of the Xtensa
instructions, usually used for padding.
Due to the lack of synchronized connections, the hf_client can not create audio_connection to
hf_ag. Set default number of synchronized connection to 1.
Closes https://github.com/espressif/esp-idf/issues/9537
xSemaphoreGive won't be executed in configASSERT and semaphore will stay locked if NDEBUG (idf v5) or CONFIG_FREERTOS_ASSERT_DISABLE (idf v3, v4) are defined.
The event group unit tests would previously use a single call bit (the
"BIT_CALL" macro) to unblock all the test tasks. However, if one or more tasks
were delayed in calling xEventGroupWaitBits(), the other tasks would clear the
test bits, leading to the test deadlocking.
This commit updates the bits used so that each task gets their own CALL and
RESPONSE bits.
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
For secure boot enabled cases, bootloader and firmware images have signature
appended and size is variable based on scheme being used. This appended data
must be considered while verifying image length against allocated partition
size to avoid any possibilities of going beyond reserved size.
Closes IDF-5617
Functions used for burning this efuse would log, but at this point
esp_log is not initialized. Moved to a later point in the startup process.
Closes https://github.com/espressif/esp-idf/issues/9457
Don't call heap_caps_alloc_failed() for malloc(0) and calloc(0), because it is not an error.
Improve handling of malloc(0) and calloc(0).
Merges https://github.com/espressif/esp-idf/pull/9517
heap_caps_*_prefer functions will now only call heaps_caps_alloc_failed
callback if all attempts to allocation memory fail (and not after each attempt
anymore).
* Closes https://github.com/espressif/esp-idf/issues/9086
esp-ringbuf funtion placement is now controlled by its own configs:
CONFIG_RINGBUF_PLACE_FUNCTIONS_INTO_FLASH and CONFIG_RINGBUF_PLACE_ISR_FUNCTIONS_INTO_FLASH
Closes https://github.com/espressif/esp-idf/issues/9198
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
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.
1. When setting compilier into -O2 optimization, build for classic bt demo will get wrong
2. Fix a memcpy bug that maybe get memory truncated
Closes https://github.com/espressif/esp-idf/issues/9398
Currently, we pull up cs io for spi flash/ram to reduce current leakage during
light sleep. But some kind of spi flash/ram chip need all io pull up. Otherwise,
current leakage will still exist.
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.
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.
Some users have requested this feature.
In order to avoid complete refactoring or introducing more code complexity, a design choice to create temporary files without blank lines is made.
Additionally, an extension check is added and there are multiple smaller code style and structure improvements.
Closes https://github.com/espressif/esp-idf/issues/8421
When working in continuous mode, hardware will continuously trigger
ADC to do conversions. On esp32s2, 2 bytes will be generated per
conversion. Prior to this commit, driver assumes 4 bytes per conversion
(on s2). This commit fixed this issue.
Prior to this change, esp32s3 ADC continuous mode output resolution is 13 bits.
This commit correct the `adc_digi_output_data_t` on esp32s3. Correct
output bits should be 12 bits. Corresponding definition in `soc_caps.h`
is also updated.
Was: Backtrace: N:M N:M N:M ...
Now: Backtrace:N:MN:M N:M ...
The problem with the new format is that it is hard to parse and
breaks the parser that is used by PlatformIO. The old format
is much more reasonable. I do not see how the pattern in IDFDUT.py
can work with the new format, due to the missing space after the :
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 cleand 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()
1. Rename MACROs SYSTEM_WIFI_RST_EN register bit fields to be more recognizable
2. reset Bluetooth baseband and MAC bits to fix the issue of task watchdog triggered during controller initialization due to invalid hardware state
Idle tick hook that indicates completion of scheduler init must be launched
on other core than the one where main task runs. Earlier it was assumed that
main task shall always run on PRO cpu but that behavior can be changed with
ESP_MAIN_TASK_AFFINITY_CPU1 and hence this fix.
Closes https://github.com/espressif/esp-idf/issues/9247
Closes IDFGH-7705
The Xtensa FreeRTOS port does not save the threadptr register when
doing a voluntary yield. This can result in a crash when multiple
tasks used the threadptr register and call "taskYIELD()".
This commit adds the threadptr register to the solicited stack frame.
The change fixes thread-local-storage size by removing .srodata section
from it. It initially was included in TLS section by mistake.
The issue was found when stack size increased after building applications
with GCC-11.1 compiler. Stack size became bigger because some new data
appeared in .srodata. See more details here:
adce62f53d
1.Update wifi doc for espnow/LR/fix rate/disable 11b/multiple antennas
2.Optimization example of wifi station
3.Optimize the null pointer judgment of eb
4.Bugfix for close sniffer mode when wifi stop
5.Fix deep sleep can't reconnect to ap when pmf enable.
6.Fix some ap will ignore auth when rx deauth for a while.
7.Fixed espnow recv unencrypted packets issue
8.Fix not update phy according to country code.
9.Update regdomain max channel according to country info from nvs and or AP.
10.Channel 14 is allowed only 11b mode.
11.Remove csa when switch channel from/to 14 channel.
12.Update phy mode nvs when softap channel from 14 to other.
13.Fix the bug that check whether channel parameter is valid.
The following functions are only defined when CONFIG_PM_ENABLE is defined:
- wifi_apb80m_request()
- wifi_apb80m_release()
This commit makes their linker script mapping statements also dependent on CONFIG_PM_ENABLE
thus fixing some linker errors when CONFIG_PM_ENABLE is disabled.
This commit enables ULP FSM support for esp32s3 and updates ULP FSM code
flow for other chips.
It adds C Macro support for the ULP FSM instruction set on esp32s2 and
esp32s3.
The unit tests are also updated to test ULP FSM on ep32s2 and esp32s3.
The previously used splits between memory allocated for ROM code,
2nd stage bootloader and the app were somewhat safe and conservative.
This resulted in some space being unavailable for static allocation
in the app.
This commit increases the space available for static allocation to the
maximum possible amount.
1. Some of the ROM code static allocation is only used in UART/USB/SPI
download modes. This region ("shared buffers") has been placed at
the lower end of ROM memory area, to be reusable in flash boot
mode. The 2nd stage bootloader linker script is modified to "pack"
all sections exactly up to the end but with roughly 8K margin between
startup stacks.
2. Instead of calculating the sections placement and hardcoding the
addresses in the LD script again, rewrite it to calculate the
start address of each memory region automatically based on the
logic above.
3. Adjust the app memory layout (SRAM_IRAM_END) accordingly,
increasing the space available for static allocation.
Overall these changes increase the space available for static
allocation by about 78kB.
The downside of these changes is that the 2nd stage bootloader .data
segment is now directly adjacent to the startup stack on the PRO CPU.
Previously, there was effectively about 78kB of extra stack space for
the PRO CPU, before the stack would run into the data segment.
On riscv core, core cycle counter counts the clock cycles only when core is active (not sleeping).
In spi_slave/sender example, it uses ccount (core cycle counter) to do a simple debounce.
Therefore, when using spi_slave/sender and spi_slave/receiver, program will be stuck.
This commit fix this issue by using esp_timer
Defining CMake variables from the command-line or from another CMake project,
such as `-DCMAKE_C_FLAGS= -DCMAKE_CXX_FLAGS=`, caused a link failure as ESP
CMake was unable to set its proper compilation flags.
Additional CMake compiler flags can now be provided by another project.
* Closes https://github.com/espressif/esp-idf/issues/7507
add: private include header
add: macro encapsulation for assertion or error check
add: ESP_FAIL return code documentation in public headers
change: replaced all assertions by NVS_ASSERT_OR_RETURN macro
change: few internal function return values from void to esp_err_t
change: ESP_ERR_NVS_VALUE_TOO_LONG macro comment
This fixes the issue where multiline strings and strings with delimiters inside the nvs input csv file were incorrectly parsed, and adds back the ability to add comment lines anywhere in the CSV file.
The issue stems from the move away from the python built in csv module to manual parsing, which was made after moving away from using the csv module to parse mfg data.
This reverts back to using the csv module for parsing and writing csv data in both mfg_gen and nvs_partition_gen, fixes the original issue in mfg_gen and improves code quality which makes the code more readable and maintainable.
Closes https://github.com/espressif/esp-idf/issues/7175
Refactor examples to build with MBEDTLS_CERTIFICATE_BUNDLE disabled. Only examples
that can work with certificate bundle disabled have been modified here.
Use local python server to test client session tickets
Update example test to test the client session tickets
Check for minimum heap info in the example test.
mktime function uses tm_isdst member as an indicator whether the time
stamp is expected to be in daylight saving time (1) or not (0).
FAT filesystem uses local time as mtime, so no information about DST
is available from the filesystem.
According to mktime documentation, tm_isdst can be set to -1, in which
case the C library will try to determine if DST was or wasn't in
effect at that time, and will set UTC time accordingly.
Note that the conversion from UTC to local time and then back to UTC
(time_t -> localtime_r -> FAT timestamp -> mktime -> time_t) does not
always recover the same UTC time. In particular, the local time in the
hour before DST comes into effect can be interpreted as "before DST"
or "after DST", which would correspond to different UTC values. In
this case which option the C library chooses is undefined.
Closes https://github.com/espressif/esp-idf/issues/9039
Originally reported in https://github.com/espressif/arduino-esp32/issues/6786
`vTaskGetSnapshot` is being used in coredump module to collect diagnostic information.
It is possible that input arguments are invalid and `assert` in this situation is not
correct.
This commit modifies API signature to return pdTRUE in case of success, and pdFALSE
otherwise. Caller can verify return value and then take appropriate decision.
Previously linenoiseProbe would accept any 4 byte response, even one
that isn't expected. This adds a check that the first byte of the
response is ESC.
Suggested in https://github.com/espressif/esp-idf/issues/8839.
Replaces the previously used Docker Hub autobuild infrastructure.
This allows for more flexible configuration of the build process,
at the expense of some extra maintenance of CI workflow files
required.
These two arguments can be used to reduce the size of the Docker
image:
- Setting IDF_CLONE_SHALLOW enables shallow cloning.
- Setting IDF_INSTALL_TARGETS to the comma separated list of targets
results in toolchains being installed only for these targets.
Purpose:
This will allow for easily automating periodic updates to
"cacrt_all.pem" file.
Note:
For now newly created "cacrt_local.pem" contains single "DST Root CA X3"
which we are keeping to manage compatibility with endpoints like
"howsmyssl.com". Please note this Root CA is expired and is not part of
Mozilla’s NSS root certificate store.
This commit fixes the systimer_counter_value_t by adding a resreved field so that the
type fills 64-bits.
Without the reserved field, when compiling with -O0 optimization, the unoccupied high
bits would not be initalized by the compiler, leading to systimer_hal_get_counter_value()
returning a garbage value.
if COAP_CONSTRAINED_STACK is defined (is for esp-idf), the mutexes set up
to protect the critical sections were not working as expected and were just
dummy entries.
Use the pthread_ version of the mutex instead by defining HAVE_PTHREAD_H
and HAVE_PTHREAD_MUTEX_LOCK.
Since ulp wakeup signal are connected to ulp int raw(except esp32), we
need to clear ulp int raw before sleep when ulp wakeup enabled. Otherwise,
if the ulp int raw is already set, chip will not sleep properly.
Closes https://github.com/espressif/esp-idf/issues/6229
This fixes a potential race condition in select() if both a socket-fd
and non-socket fd trigger simultaneously to unblock this select.
In case of both fds, we use lwip's local thread semaphore, so we only
have to try return it (if it was taken/triggered more than once) when
we exit select().
Closes https://github.com/espressif/esp-idf/issues/8896
Bluetooth: disable PLL track function for ESP32-C3/ESP32-S3 as it introduced coexistence issues(bacport v4.4)
See merge request espressif/esp-idf!18139
Clang outputs performance warnings by default for atomic operations with
access size more then 4 bytes. So add "-Wno-atomic-alignment add" flag to
ESP-IDF cmake script.
'read' function should return 0 when encountering an end of file. When
newlib calls read and sees EOF returned, it assumes that this
condition is permanent and never calls 'read' for this file again
(unless the read pointer is moved using fseek).
The correct behavior in case no characters were received over UART is
to return -1. In this case newlib will retry reading from file on next
call to fread, fgetc or another function which calls __srefill_r.
introduced in e44ead5356
1. The int8M power domain config by default is PD. While LEDC is using
RTC8M as clock source, this power domain will be kept on.
But when 8MD256 is used as RTC clock source, the power domain should
also be kept on.
On ESP32, there was protection for it, but broken by commit
e44ead5356. Currently the power domain
will be forced on when LEDC is using RTC8M as clock source &&
!int8m_pd_en (user enable ESP_PDP_DOMAIN_RTC8M in lightsleep). Otherwise
the power domain will be powered off, regardless of RTC clock source.
In other words, int8M domain will be forced off (even when 8MD256
used as RTC clock source) if LEDC not using RTC8M as clock source, user
doesn't enable ESP_PDP_DOMAIN_RTC8M, or in deep sleep.
On later chips, there's no such protection, so 8MD256 could't be used as
RTC clock source in sleep modes.
This commit adds protection of 8MD256 clock to other chips. Fixes the
incorrect protection logic overriding on ESP32. Now the power domain
will be determiend by the logic below (order by priority):
1. When RTC clock source uses 8MD256, power up
2. When LEDC uses RTC8M clock source, power up
3. In deepsleep, power down
4. Otherwise determined by user config of ESP_PDP_DOMAIN_RTC8M,
power down by default. (This is preferred to have highest
priority, but it's kept as is because of current code structure.)
2. Before, after the macro `RTC_SLEEP_CONFIG_DEFAULT` decides dbias, the
protection above may force the int8m PU. This may cause the inconsistent
of dbias and the int8m PU status.
This commit lifts the logic of pd int8m/xtal fpu logic to upper layer
(sleep_modes.c).
Related: https://github.com/espressif/esp-idf/issues/8007, https://github.com/espressif/esp-idf/pull/8089
temp
fix(server): Fix websocket server not support handle multiple connections when client send CLOSE frame (backport v4.4)
See merge request espressif/esp-idf!18018
ESP-IDF v4.4 supports Python 3.6 or newer. F-strings are available there
but idf_tools.py can fail if run with older Pythons because the Python
version check is done later.
Closes https://github.com/espressif/esp-idf/issues/8890
Prior to this change "esp_wifi_clear_default_wifi_driver_and_handlers"
will not remove netif pointer from table when both AP and STA interfaces were
created and destroying default wifi interfaces is done in unfortunate
order. As a result there is dangling pointer left and it may cause crash in
later code (i.e. when esp_wifi_stop() is called).
ESP32-S2 and ESP32-S3
supports up to 1 GB of external flash and RAM
add support for
- 32MB
- 64MB
- 128MB ( example NOR spiFLASH 1G-BIT W25Q01JVZEIQ Winbond 0xEF 0x40 0x21 )
Merges https://github.com/espressif/esp-idf/pull/7688
Signed-off-by: Ivan Grokhotkov <ivan@espressif.com>
The compiler was not informed that the assembly block should be
treated as a memory barrier and could optimize out the initialization
of local arrays which could be used as semihosting arguments.
This resulted in garbage values being passed as semihosting call
arguments.
Additionally this commit changes the approach for placing values into
specific register. Instead of clobbers, local register variables are
used. This results in simpler generated code, since the compiler is
able to place values directly into the registers used for semihosting
arguments, avoiding additional moves.
LVGL porting examples are temporarily left in test folder.
Now we can remove it, as we have lvgl examples in esp-idf.
And lvgl v7 is legacy, we recommend to use lvgl v8
* Move filesystem mounting code into a separate file to simplify the
main source file.
* Clean up SDMMC and SDSPI related code. Move pin configuration into
Kconfig.
* Use same base_path ('/data') for either SPIFFS or SD. Remove the
check in file_server.c about the base path.
* Update README according to the changes above.
- Added a config option to set the minimum Certificate Verification
mode to Optional
- When this option is enabled, the peer (the client) certificate
is checked by the server, however the handshake continues even if
verification failed.
- By default, the peer certificate is not checked and ignored by the server.
Closes https://github.com/espressif/esp-idf/issues/8664
* Cherry-pick important fixes to 2.1.2-esp
- CVE-2020-22283: Attacker could craft a packet that would disclose 8 bytes of some heap memory:
- icmp6: Don't copy too much data
- icmp6: Fix copying of chained pbuf in reply
- icmp6: keep to the RFC and send as much as possible with icmp6 error messages
- CVE-2020-22284: ZEP - ZigBee Encapsulation Protocol/6LoWPAN is not supported in IDF,
the netif module (zepif.c) is not included in the build, but users can still inject
the file into compilation process, implement IO interface and use this.
- zepif: Copy possibly chained output pbuf properly
- Add #define for minimum IPv6 MTU length
- pbuf: Add pbuf_copy_partial_pbuf library function
* PPPoS: Fix null-deref when processing double break packet
- pppos: fix in_tail null (espressif/esp-lwip@537c69d5)
- PPP: Add test exhibiting empty packet null-deref (espressif/esp-lwip@202a07da)
* NAPT: Fix PBUF_REF type to clone the pbuf before forwarding
- IP-FORWARD: If packet-type is PBUF_REF clone it before forwarding
- Add NAPT unit test to exercise NAT feature for both RAM and REF pbuf types
* version: Update version numbers to match 2.1.2-esp
* Update submodule: 2749568fe1...76303df238
- test/napt: Add unit test for IP forward with PBUF_REF (espressif/esp-lwip@76303df2)
- napt: Fix PBUF_REF type to clone the pbuf before forwarding (espressif/esp-lwip@39068263)
- version: Update version numbers to match 2.1.2-esp (espressif/esp-lwip@2b922919)
- pppos: fix in_tail null (espressif/esp-lwip@537c69d5)
- PPP: Add test exhibiting empty packet null-deref (espressif/esp-lwip@202a07da)
- pbuf: Add pbuf_copy_partial_pbuf library function (espressif/esp-lwip@1c9cd9c1)
- Add #define for minimum IPv6 MTU length (espressif/esp-lwip@d2dc577b)
- zepif: Copy possibly chained output pbuf properly (espressif/esp-lwip@64ab7f2a)
- icmp6: Don't copy too much data (espressif/esp-lwip@4a64731b)
- icmp6: Fix copying of chained pbuf in reply (espressif/esp-lwip@7c822ff4)
- icmp6: keep to the RFC and send as much as possible with icmp6 error messages (espressif/esp-lwip@29100ab6)
- dns: Add API to clear dns cache (espressif/esp-lwip@ee59f77d)
- CI: Fixed adding gitlab key (espressif/esp-lwip@5a2bdba7)
- test case: modify test case test_tcp_new_max_num_remove_FIN_WAIT_1 (espressif/esp-lwip@6b090f7d)
Closes https://github.com/espressif/esp-idf/issues/8300
Closes https://github.com/espressif/esp-idf/issues/8451
mask_get_id and gpio_hal_iomux_func_sel were called while cache
is disabled, but were not inlined as expected at -0O.
Force these functions to always be inlined.
These were called from IRAM context where the caller expect them to be inlined
and accessible when cache is disabled. This was not the case when compiled with -O0.
Closes https://github.com/espressif/esp-idf/issues/8301
While using esp_wifi_set_config, flag pmf_capable defaults to 0.
Users may not bother to enable it, which prevents connection to a
WPA3 AP. Or the AP may reset into WPA3 mode failing the re-connection.
To ensure better security, deprecate the pmf_capable flag and set it to
true internally.
This commit updates the USB Host Library as follows:
- usb_helpers.h
- Removed dependency on USB Host Library API
- Added function to print string descriptors
- usbh
- Fixed bug where an interface/endpoint could be claimed/allocated multiple times
- Removed redundant device ref_count change
- Added unit test for USB Host Library API usage
This commit updates the Hub Driver and USBH as follows:
- Updated communication mechanism between Hub Driver and USBH
- USBH notifies the Hub Driver via Hub request callback (usbh_hub_req_cb_t)
- Hub Driver notifies the USBH via usbh_hub_pass_event()
- Hub Driver now defers all event handling to hub_process.
- Hub Driver and USBH will now automatically recover the port after a disconnected
device has been closed.
- Fixed incorrect assert in usbh_dev_close()
Hub Driver is refactored as follows:
This commit update and refactors the Hub Driver as follows:
- Refactored enumeration state machine and stage functions
- Enumeration stage is now incremented
- Combined transfer stages of enumeration into common functions
- Comments updated
- Fixed usbh_hal_disable_debounce_lock() that would cause root_port_handle_events()
to fail the HCD_PORT_CMD_RESET call because the previous port connection interrupt
was not cleared.
The following features were added to the Hub Driver
- Enumeration config descriptor is now fetched in two separate stages
- Header is fetched first to determine the wTotalLength of the descriptor
- Fetching the full descriptor will request exactly wTotalLength bytes
- This works around some non-compliant devices that will babble/return zero
when requesting a length > wTotalLength
- Closes https://github.com/espressif/esp-idf/issues/7799
- Enumeration now stores string descriptors
- The Manufacturer, Product, and Serial Number string descriptors are
now read and stored during enumeration
- String descriptors are now part of usb_device_info_t
- Added unit test to test enumeration
This commit updates the USB Host stack to use the USB PHY driver. The
USB PHY and the OTG Controller should now both be setup/deleted using
usb_new_phy() and usb_del_phy() respectively.
- The hcd_install() now expects the USB PHY and OTG Contorller to be
already setup before it is called
- usb_host_install() now has an option to skip calling usb_del_phy() if
the user wants to setup their own USB PHY (e.g., in the case of using
and external PHY).
- CDC-ACM and MSC examples/test updated to use internal PHY
Closes https://github.com/espressif/esp-idf/issues/8061
This commit fixes the following bugs in the HCD
- HCD control pipes fill incorrect transfer size
_buffer_fill_ctrl() would fill the transfer descriptors length with
wLength instead of transfer->num_bytes. Therefore, the remaining length
would be incorrect when a control transfer requests more bytes than are
available.
- Fix USB_TRANSFER_FLAG_ZERO_PACK behavior
The previous behavior of USB_TRANSFER_FLAG_ZERO_PACK was incorrect, and did not
support interrupt pipes. A zero length packet can now be added to Bulk/Interrupt
OUT transfers where the length is a multiple of the endpoint's MPS.
- Fixed HCD port suspend and resume test case
Halting a control pipe mid control transfer can lead some test devices to get stuck
Avoid adding one extra fade cycle when performing a one-time duty update.
Add some notes to ledc_get_duty and ledc_update_duty APIs, so that users
are aware of when the new duty will be effective.
Closes https://github.com/espressif/esp-idf/issues/7288
(cherry picked from commit e175086226)
Closes https://github.com/espressif/esp-idf/issues/5571
Fix the bug that if the API was called from one core to free the interrupt source on the other core, it would trigger interrupt watchdog.
(cherry picked from commit 0e8286c57b)
As ESP32C3 does not have support for REF_TICK source clock, it is now not
possible to select it anymore.
Auto cfg clock has been improved for all boards.
Add following bugfixes
1. Station not able to connect when WPS pin is pressed first on AP.
2. PBC overlap getting detected for selected registrar PIN APs.
3. Station not considering authorised MACs for PIN method.
4. For PIN methodm If no AP is found, station will loop through
APs in its vicinity and try to do WPS with them one by one till
WPS timeout occurs. This is for some APs which do not set
selected registrar correctly.
Initial version of freemodbus master port files have been added to ESP-IDF based on https://github.com/armink/FreeModbus_Slave-Master-RTT-STM32.
The overall repository license, at the time of adding these files, has been BSD 3-clause. However at that time, several port files carried LGPL license headers. As the author of these files confirmed in https://github.com/armink/FreeModbus_Slave-Master-RTT-STM32/issues/61#issuecomment-977828450, this wasn't intentional. ESP-IDF version of modbus master port has been rewritten to target FreeRTOS instead of RT-Thread, but the license headers remained from the original version. This commit corrects this, replacing the license of these files with BSD 3-clause.
Calling "open" in CHECK_AND_CALL sets a perfectly correct errno.
There is no need to overwrite that with a value of ENOENT, since doing
so hides lower level errors like EIO.
Closes https://github.com/espressif/esp-idf/pull/8036
...and all their callers.
With the upcoming switch from sizeof(time_t)==4 to sizeof(time_t)==8,
sizeof(struct stat) is also increasing.
A few newlib functions present in ROM allocate 'struct stat' on the
stack and call _fstat_r on this structure. The implementation of
fstat is provided in ESP-IDF. This implementation will often do
memset(st, 0, sizeof(*st)), where st is 'struct stat*', before setting
some fields of this structure. If IDF is built with sizeof(st)
different from sizeof(st) which ROM was built with, this will lead
to an out-of-bounds write and a stack corruption.
This commit removes problematic ROM functions from the linker script.
Here are the functions which allocate 'struct stat':
* _isatty_r (in ROM)
* __swhatbuf_r, called by __smakebuf_r, called by __swsetup_r and
__srefill_r (in ROM)
* _fseeko_r (not in ROM)
* glob2 (not in ROM)
* _gettemp (not in ROM)
As a result, these functions are used from libc.a, and use correct
size of 'stat' structure.
Closes https://github.com/espressif/esp-idf/issues/7980
- Fixed logs expecting different format specifier
- Updated ignore list for check_public_header test
- Updated functions ported from mbedTLS
- Fix for make-system build errors
- Removed code regarding MBEDTLS_DYNAMIC_FREE_PEER_CERT
(config was kept for backward compatibility)
- Combined mbedTLS v2.28.x related options under a separate Kconfig menu
- For the wifi_prov_mgr example in release mode (with NDEBUG defined -
assertions disabled), the task to stop provisioning is never started
as it is voided by the assert function it is called in.
Closes https://github.com/espressif/esp-idf/issues/8309
fix: re-enabled fatfs r/w test on sdspi
fix: copyright notice
add: pin definitions for esp32c3
fix: Changed fixed spi dma channel to a macro definition
docs: Update incorrect pins for S3 documentation, set a default value for future targets, and remove line breaks inside paragraphs (backport v4.4)
See merge request espressif/esp-idf!16367
export PYTHONPATH="$IDF_PATH/tools:$IDF_PATH/tools/ci/python_packages"
python -m pip install -r $IDF_PATH/tools/ci/python_packages/ttfw_idf/requirements.txt
It helps to fix the ModuleNotFoundError issue with ttfw_idf and tiny_test_fw modules.
Closes https://github.com/espressif/esp-idf/issues/7815
- Check if pip is installed for sys.executable before attempting to
create the virtual environment, bail out with an error if not.
- Don't pass --seeder argument to virtualenv if its version is
too old. For example, on Ubuntu 18.04, virtualenv 15.1.0 doesn't
support this argument.
- Pass --python argument to virtualenv to request specific interpreter
to be used.
Closes https://github.com/espressif/esp-idf/issues/8045
Some tests check if certain files are rebuilt when source files are
'touch'ed. With ccache, 'touch'ing source files doesn't cause a
rebuild, hence the test fails. In case IDF_CCACHE_ENABLE was set in
the environment, unset it before starting the tests.
This commit refactors the FreeRTOS documentation as follows:
- Rewrite FreeRTOS SMP changes document (ESP-IDF FreeRTOS SMP)
- Reorganized sections in kernel behavior changes
- Rewrote descriptions of each kernel behavior changes
- Added notes about using ESP-IDF FreeRTOS for single core targets
- Moved TLSP callback section to FreeRTOS Additions document
- Moved FreeRTOS configuration section to FreeRTOS API document
- Added notes about FreeRTOS applications in ESP-IDF
- add missing Wi-Fi header MD5 checks for esp32c3, esp32s3
- check PHY libraries for references to ets_printf, in addition to
checking Wi-Fi libraries. This used to happen until libphy.a was
moved into a separate submodule.
Reported in https://github.com/espressif/esp-phy-lib/issues/3
time we can't find old device to be replaced,then this can cause crash. So we need
to change the way to malloc the new device or replace the old in the list.
Reason:
For example, if an url is lack of leading 'http:' by mistake, it causes to http_parser_parse_url() cannot parse http host item,
and then pass the null host pointer to _get_host_header(), crash happens.
Fix:
http added null pointer check now.
Closes https://jira.espressif.com:8443/browse/ESPAT-953
xPortStartScheduler calls vPortSetupTimer -> _frxt_tick_timer_init,
which enables tick timer interrupt and sets up the first timeout.
From that point on, the interrupt can fire. If the interrupt happens
while _frxt_dispatch is running, the scheduler will enter an infinite
loop. This is because _frxt_dispatch isn't supposed to be preemptable,
and the tick interrupt will overwrite some of the registers used by
_frxt_dispatch.
Note that this situation doesn't practically occur on the real
hardware, where the execution of vPortSetupTimer and _frxt_dispatch
happens quickly enough. However it can be reproduced on an emulator
if the tick period is set to 1ms.
Add an explicit call to portDISABLE_INTERRUPTS in xPortStartScheduler
to guarantee that _frxt_dispatch doesn't run with interrupts enabled.
This is similar to the esprv_intc_int_set_threshold(1); call in
RISC-V version of port.c.
Current issue: output reports sent by Windows not received.
The report characteristic declaration should also support write without
response as specified by HIDS profile:
See https://www.bluetooth.com/specifications/GATT/ (page 14)
This bugfix contains 3 fixes:
1. .rtc_dummy section is removed (not needed for C3)
2. .rtc_text section is padded with 16B for possible CPU prefetch
3. .rtc_text section is aligned to 4B boundary to comply with PMS Memprot requirements
[Coexistence]: fixed BLE scannable extended adv performance issue in case of Wi-Fi coexistence(backport v4.4)
See merge request espressif/esp-idf!16476
Fix a bug that could return a chunk of memory smaller than requested,
easily leading to a memory corruption, when the required memory alignment
passed to the allocator is 4.
This commit adds missing INCLUDE_ configurations to FreeRTOSConfig.h for
the following functions:
- xTaskAbortDelay()
- xTaskGetHandle()
Unit tests for these functions were also added.
Closes https://github.com/espressif/esp-idf/issues/7902
* Adds implementations of __{atomic,sync}_nand_fetch_n. These builtins
were implemented for other operations but were not defined for NAND.
* Adds implementation of __atomic_OP_fetch_n for all OPs.
* Adds implementation of __sync_OP_and_fetch_n for all OPs.
Reported in https://github.com/espressif/arduino-esp32/issues/5948
1. fix(pp): fix fragment plt loss when 2td pn compare with 1th pn
2. pmf allow keyindex in big endian format to workaround faulty APs
3. docs: update miswritten and abbreviated words and syntax errors for initialize WiFi section in esp_wifi.h header file
4. allow for minimal scope of wifi_init_config_t
ADC calibration scheme and algorithm are not changed. Only the eFuse bit BLOCK1_VERSION is changed. This MR updated the logic to recognize the adc efuse version
"can set sleep wake stub from stack in RTC RAM" would randomly fail on S3 due to stack overflow.
Fixed wrong usage of stack size and slightly increased it.
1. Fix FTM failures after repeated operations
2. Update Mexico channel refer to FCC
3. Mesh: fix the issue that layer2 node connect to lower-layer node when FIXED-ROOT root disappeared
4. Decouple softap and 8684 support
lw-ip: Update LWIP_DHCP_OPTIONS_LEN default value when LWIP_DHCP_DISABLE_VENDOR_CLASS_ID disabled(backport v4.4)
See merge request espressif/esp-idf!16253
In commit de22f3a4e5, combination of
hardware and software MPI (bignum) related approach was used to
work around chip (e.g. ESP32-C3) limitation of max 3072 bits support.
This was done using linker "--wrap" flag but since the relevant API is
being used in same translation (compilation unit), hardware mode was not
getting used in some cases (e.g., RSA key generation).
This commit modified internal mbedTLS API and makes software+hardware
combination deterministic.
The release of the semaphore indicating the item was successfully sent must be the last semaphore released. The receiver may be in another task and may delete the Ringbuffer (such as with a return code across tasks design pattern) if they are through with the Ringbuffer.
The function xRingbufferSendAcquire followed by xRingbufferSendComplete had the semaphores released in the proper order and that same pattern should have been used in xRingbufferSend and xRingbufferSendFromISR. This commit fixes this order.
Issue (IDFGH-6030) #7716 describes the problem in more detail.
Closes IDFGH-6030, https://github.com/espressif/esp-idf/issues/7716
Closes IDFGH-6036, https://github.com/espressif/esp-idf/pull/7721
ringbuf: Fix bug where comparision between a signed and unsigned operand resulted in incorrect free size for no-split/allow-split buffers (v4.4)
See merge request espressif/esp-idf!15881
This function resets the spinlock given as a parameter after taking it
(when entering the critical section). This then results in a panic once
it tries to exit the same critical section.
* Closes https://github.com/espressif/esp-idf/issues/7725
When building with BOOTLOADER_LOG_LEVEL lesser then VERBOSE, an error
code variable was being set but not consumed, resulting in a compiler
warning.
Signed-off-by: Gustavo Henrique Nihei <gustavo.nihei@espressif.com>
Builds for every chip other than ESP32 resulted in a compiler warning
due to "drom_load_addr_aligned" and "irom_load_addr_aligned" not being
used, besides being possible to actually reuse them.
Furthermore, extended the logic for the other similar variables.
Signed-off-by: Gustavo Henrique Nihei <gustavo.nihei@espressif.com>
This issue was earlier fixed in commit 79e74e5d5f
but during migration to newer FreeRTOS release, it got introduced again.
This commit fixes thread safety issues with configASSERT() calls
regarding the value of uxSchedulerSuspended. A false negative
occurs if a context switch to the opposite core occurs in between
the getting the core ID and the assesment.
Relevant https://github.com/espressif/esp-idf/issues/4230
Closes https://github.com/espressif/esp-idf/issues/7726
Closes IDFGH-6041
When the build runner has a local git mirror configured via
LOCAL_GIT_MIRROR variable, use that mirror when cloning IDF insider
the docker build job. Follows similar logic for
LOCAL_GITLAB_HTTPS_HOST, which is used for geo nodes.
The body of the bootloader_debug_buffer function was conditioned to
macros that were never defined, resulting in deactivated code.
Signed-off-by: Gustavo Henrique Nihei <gustavo.nihei@espressif.com>
For the CID10564,10384,10280,10098,10038,The memory was released in other place.
For the CID10365,it release the memory in the function when sent successfully.
For the CID10268,10011, we need not change the code.
Add TRY_ENTRY_CRITICAL() API to all for timeouts when entering critical sections.
The following port API were added:
- portTRY_ENTER_CRITICAL()
- portTRY_ENTER_CRITICAL_ISR()
- portTRY_ENTER_CRITICAL_SAFE()
Deprecated legacy spinlock API in favor of spinlock.h. The following API were deprecated:
- vPortCPUInitializeMutex()
- vPortCPUAcquireMutex()
- vPortCPUAcquireMutexTimeout()
- vPortCPUReleaseMutex()
Other Changes:
- Added portMUX_INITIALIZE() to replace vPortCPUInitializeMutex()
- The assembly of the critical section functions ends up being about 50 instructions longer,
thus the spinlock test pass threshold had to be increased to account for the extra runtime.
Closes https://github.com/espressif/esp-idf/issues/5301
During the early start, the virtual eFuse mode can call erase operations when OS is not yet running.
Possible workaround: CONFIG_SPI_FLASH_YIELD_DURING_ERASE=n
Fixed for the legacy flash driver as well.
This prevents the compiler error for the implicit declaration of
function "esp_rom_printf".
Signed-off-by: Gustavo Henrique Nihei <gustavo.nihei@espressif.com>
With strict debugging, i.e. `Set-PSDebug -strict`, execution of export.ps1 will
report the following error:
```
The variable '$envars_array' cannot be retrieved because it has not been set.
At C:\path\to\export.ps1:15 char:1
+ $envars_array # will be filled like:
+ ~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (envars_array:String) [], RuntimeException
+ FullyQualifiedErrorId : VariableIsUndefined
```
Closes https://github.com/espressif/esp-idf/pull/7819
This commit updates the USB Host Library API in the following wasy:
- usb_host_client_handle_t and usb_device_handle_t made into struct pointers
to generate compiler warnings about conflicting handle types
- usb_host_client_config_t changed to future proof API for Synchronous Clients
- Added usb_host_lib_unblock()
- Added usb_host_device_addr_list_fill()
- Return of usb_host_device_free_all() updated to indicate whether there
are still devices yet to be freed.
- Blockg APIs are now marked explicitly
- Fixed a bug in usb_host_transfer_submit_control() when checking the bEndpointAddress
of a control transfer.
Tests are also refactored to move some common macros into shared headers
Closes https://github.com/espressif/esp-idf/issues/7786
This commit fixes how the USBH handling of a sudden device disconnection,
more specifically handling of device gone.
- Previously the USBH would only halt, flush, and dequeue the device's
default EP, then send a device gone event to the Host Library layer.
- Now the USBH will also halt and flush all non-default EPs, allowing
all of the URBs to be dequeud.
- Some internal object members are now protected by a mutex instead of
a spinlock.
Closes https://github.com/espressif/esp-idf/issues/7505
This commit fixes how the USB Host HCD handles sudden disconnections.
Bugs:
- HW channels remain active when the port suddenly disconnects, and
previously the channel would be disabled by setting the disabled bit,
then waiting for a disabled interrupt. However, ISOC channels do not
generate the disabled interrupt when the port is invalid, thus leading
to tasks getting indefinitely blocked in hcd_pipe_command().
Fix:
On a sudden disconnection, forcibly treat all channels as halted even
if their HCCHAR.ChEna bit is still set. We do a soft reset after a port
error anyways, so the channels will eventually be reset.
Closes https://github.com/espressif/esp-idf/issues/7505
This commit addes the 8/16 bit register field access workarounds to
the DWC_OTG peripheral. This workaround was applied to all other
peripherals in commit 874a720286.
The previous SMP freertos round robin would skip over tasks when
time slicing. This commit implements a Best Effort Round Robin
where selected tasks are put to the back of the list, thus
makes the time slicing more fair.
- Documentation has been updated accordingly.
- Tidy up vTaskSwitchContext() to match v10.4.3 more
- Increased esp_ipc task stack size to avoid overflow
Closes https://github.com/espressif/esp-idf/issues/7256
This commit removes the following critical nested macros as follows:
- portENTER_CRITICAL_NESTED()
- portEXIT_CRITICAL_NESTED()
They are replaced with portSET_INTERRUPT_MASK_FROM_ISR() and
portCLEAR_INTERRUPT_MASK_FROM_ISR() which are the proper FreeRTOS interfaces.
Created a portmacro_deprecated.h for each port to contain deprecated API
that were originally from portmacro.h
This commit fixes a bug in no-split and allow-split ring buffers free buffer size calculation.
When the free size available in the buffers less than the size of one item header,
the function prvGetCurMaxSizeNoSplit/AllowSplit() incorrectly returned the maxItemSize instead of 0.
This is due to the comparision between a negative and a positive value
where both operands are treated as unsigned during the comparision operation,
thereby treating the negative operand as a large integer.
Also added new unit tests to test buffer-full and almost-full conditions
where this scenario is likely to be hit.
Closes https://github.com/espressif/esp-idf/issues/7344
Closes https://github.com/espressif/esp-idf/pull/7371
FATFS provides a disk status and disk initialize callback which were not
implemented. Implementation has very low impact on SD/MMC speed and
fixes issues, when trying to open file when SD card was removed from
slot and not deinited.
If disk_status returns STA_NOINIT, it will always continue with
disk_initialize. If that returns 0, it will continue like everything is
working normally. So there has to be the same check as in disk_status.
Return of disk_initialize is always checked like this for STA_NOINIT or
STA_PROTECT so if command fails, we return the STA_NOINIT.
stat = disk_initialize(pdrv);
if (stat & STA_NOINIT) return FR_NOT_READY;
if (stat & STA_PROTECT) return FR_WRITE_PROTECTED;
Closes IDF-4125
This commit fixes issue where empty (unprogrammed) digest slot out of
multiple supported (e.g. 3 for ESP32-C3) could cause issue in
workflow enablement process.
Notes:
1. This issue was applicable for chips supporting "secure-boot-v2"
scheme with multiple digests slots
2. This issue was affecting only manual workflow, where digest of
public was pre-flashed in efuse
3. Change in "flash_encrypt.c" is only for additional safety purpose
Increase reset assertion time from 100µs (as specified minimum in the datasheet) to 150µs.
Some specimen of the LAN8720 need the reset signal asserted longer than 100µs to initialise properly. Otherwise they are in a zombie state where they are establishing and loosing an Ethernet link once in a seconds interval.
Tokenizing data by '\n' will effectively replace all LF characters by '\0' so checking for phantom lines has to be adjusted:
* minimal empty line is CR only (strlen = 1)
* checking for lines containing CR only
This commit adds the following hook functions to obtain memory
for the IDLE and Timer Daemon tasks when configSUPPORT_STATIC_ALLOCATION
is enabled:
- vApplicationGetIdleTaskMemory()
- vApplicationGetTimerTaskMemory()
Currently, both functions simply allocate from the same memory as
regular tasks (i.e., internal memory for both the stack and TCB)
Closes https://github.com/espressif/esp-idf/issues/7511
esp_restart()/panic_restart() never resets the Digital system (so far required only by the Memprot feature) as there's a typo in the corresponding #define:
it checks CONFIG_ESP_SYSTEM_CONFIG_MEMPROT_FEATURE instead of CONFIG_ESP_SYSTEM_MEMPROT_FEATURE.
Issue fixed.
IDF-4094
The issue is related to the non-sequential way of description when
such fields going together sequential.
Related to esp32h2 chip for eFuses: MAC_FACTORY and MAC_EXT.
The issue is in wrong indexes of MAC_EXT.
MAC_EXT got indexes like it is joined to MAC_FACTORY.
const esp_efuse_desc_t* ESP_EFUSE_MAC_FACTORY[] = {
&MAC_FACTORY[0],
&MAC_FACTORY[1],
&MAC_FACTORY[2],
&MAC_FACTORY[3],
&MAC_FACTORY[4],
&MAC_FACTORY[5],
NULL
};
const esp_efuse_desc_t* ESP_EFUSE_MAC_EXT[] = {
&MAC_EXT[6],
&MAC_EXT[7],
NULL
};
This commit fixed it to:
const esp_efuse_desc_t* ESP_EFUSE_MAC_EXT[] = {
&MAC_EXT[0],
&MAC_EXT[1],
NULL
};
esp_http_client: Fix HEAD request will affect the all next HTTP requests unless we close the HTTP request(backport v4.4)
See merge request espressif/esp-idf!15715
In 4972605, high-level interrupt handler hook was renamed from
ld_include_highint_hdl to ld_include_panic_highint_hdl. However the
change wasn't applied in GNU Make based build system. As a result,
the default interrupt handler was linked and features which depended
on the high-level interrupt didn't work.
Closes https://github.com/espressif/esp-idf/issues/7759
Closes https://github.com/espressif/esp-idf/issues/7447
Switching back from data (PPP) mode to command mode must be done is the following sequence:
* No characters entered for T1 time (1 second)
* "+++" characters entered with no characters in between (1 second)
* No characters entered for T1 timer (1 second)
(per specification of SIM800 SIM800_Series_AT_Command_Manual_V1.09.pdf)
Related https://github.com/espressif/esp-idf/issues/7608
Regression from e68afcb45036901ebc9174b2c8f3804f7921410c causing
non-clean builds for standard asio-ssl example (warning was
suppressed in the CI build only)
In esp_dte_handle_line(), it tokenize the data to call handlers separately
for each *line*. So it needs to post the tokenized data when report unknown
line instead of the first token (which could be a '\r' in my test).
Fixes: 336de29413 ("Examples/pppos_client: Fix manual parsing to accept unexpected lines")
Signed-off-by: Axel Lin <axel.lin@gmail.com>
2021-10-18 10:14:31 +08:00
21385 changed files with 1796122 additions and 3537440 deletions
description:Before submitting a new issue, please follow the checklist and try to find the answer.
options:
- label:I have read the documentation [ESP-IDF Programming Guide](https://docs.espressif.com/projects/esp-idf/en/latest/) and the issue is not addressed there.
required:true
- label:I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
required:true
- label:I have searched the issue tracker for a similar issue and not found a similar issue.
required:true
- type:input
id:idf_version
attributes:
label:IDF version.
description:Onwhich IDF version does this issue occur on? Run `git describe --tags` to find it.
placeholder:ex. v3.2-dev-1148-g96cd3b75c
validations:
required:true
- type:dropdown
id:operating_system
attributes:
label:Operating System used.
multiple:false
options:
- Windows
- Linux
- macOS
validations:
required:true
- type:dropdown
id:build
attributes:
label:How did you build your project?
multiple:false
options:
- Command line with Make
- Command line with CMake
- Command line with idf.py
- Eclipse IDE
- CLion IDE
- VS Code IDE
- Other (please specify in More Information)
validations:
required:true
- type:dropdown
id:windows_comand_line
attributes:
label:If you are using Windows, please specify command line type.
multiple:false
options:
- PowerShell
- CMD
validations:
required:false
- type:textarea
id:expected
attributes:
label:What is the expected behavior?
description:Please provide a clear and concise description of the expected behavior.
placeholder:I expected it to...
validations:
required:true
- type:textarea
id:actual
attributes:
label:What is the actual behavior?
description:Please describe actual behavior.
placeholder:Instead it...
validations:
required:true
- type:textarea
id:steps
attributes:
label:Steps to reproduce.
description:'How do you trigger this bug? Please walk us through it step by step. If this is build bug, please attach sdkconfig file (from your project folder). Please attach your code here.'
value:|
1. Step
2. Step
3. Step
...
validations:
required:true
- type:textarea
id:debug_logs
attributes:
label:Build or installation Logs.
description:Build or installation log goes here, should contain the backtrace, as well as the reset source if it is a crash.
placeholder:Your log goes here.
render:plain
validations:
required:false
- type:textarea
id: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` 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/api-guides/tools/idf-monitor.html), or [coredumps](https://docs.espressif.com/projects/esp-idf/en/latest/api-guides/core_dump.html).
4. Providing as much information as possible under **Other items if possible** will help us locate and fix the problem.
5. Use [Markdown](https://guides.github.com/features/mastering-markdown/) (see formatting buttons above) and the Preview tab to check what the issue will look like.
6. Delete these instructions from the above to the below marker lines before submitting this issue.
**IMPORTANT: If you do not follow these instructions and provide the necessary details, your issue may not be resolved.**
- [Manifest File to Control the Build/Test apps](#manifest-file-to-control-the-buildtest-apps)
- [Grammar](#grammar)
- [Special Rules](#special-rules)
- [Upload/Download Artifacts to Internal Minio Server](#uploaddownload-artifacts-to-internal-minio-server)
- [Users Without Access to Minio](#users-without-access-to-minio)
- [Users With Access to Minio](#users-with-access-to-minio)
- [Env Vars for Minio](#env-vars-for-minio)
- [Artifacts Types and File Patterns](#artifacts-types-and-file-patterns)
- [Upload](#upload)
- [Download](#download)
## General Workflow
@@ -55,21 +45,22 @@
-`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`
-`integration_test[_wifi/ble]`
-`iperf_stress_test`
-`macos`
-`macos_test`
-`nvs_coverage`
-`submodule`
-`unit_test[_esp32/esp32s2/...]`
-`weekend_test`
-`windows`
There are two general labels (not recommended since these two labels will trigger a lot of jobs)
-`target_test`: includes all target for `example_test`, `custom_test`, `component_ut`, `integration_test`
-`target_test`: includes all target for `example_test`, `custom_test`, `component_ut`,`unit_test`,`integration_test`
-`all_test`: includes all test labels
### How to trigger a `detached` pipeline without pushing new commits?
@@ -117,7 +108,7 @@ curl -X POST --header "PRIVATE-TOKEN: [YOUR PERSONAL ACCESS TOKEN]" [GITLAB_SERV
```yaml
check_docs_lang_sync:
extends:
- .pre_check_template
- .pre_check_job_template
- .rules:build:docs
script:
- cd docs
@@ -145,11 +136,10 @@ check if there's a suitable `.if-<if-anchor-you-need>` anchor
1. if there is, create a rule following [`rules` Template Naming Rules](#rules-template-naming-rules).For detail information, please refer to [GitLab Documentation `rules-if`](https://docs.gitlab.com/ee/ci/yaml/README.html#rulesif). Here's an example.
```yaml
.rules:patterns:clang_tidy:
.rules:dev:
rules:
- <<: *if-protected
- <<: *if-trigger
- <<: *if-dev-push
changes: *patterns-c-files
```
2. if there isn't
@@ -198,7 +188,7 @@ if a name has multi phrases, use `-` to concatenate them.
-`target_test`
a combination of `example_test`, `custom_test`, `component_ut`, `integration_test` and all targets
a combination of `example_test`, `custom_test`,`unit_test`,`component_ut`, `integration_test` and all targets
#### `rules` Template Naming Rules
@@ -233,26 +223,3 @@ To run these commands in shell script locally, place `source tools/ci/utils.sh`
-`info`: log in green color
-`run_cmd`: run the command with duration seconds info
-`retry_failed`: run the command with duration seconds info, retry when failed
## Manifest File to Control the Build/Test apps
`.build-test-rules.yml` file is a manifest file to control if the CI is running the build and test job or not. The Supported Targets table in `README.md` for apps would be auto-generated by `pre-commit` from the app's `.build-test-rules.yml`.
### Grammar
We're using the latest version of [idf-build-apps][idf-build-apps]. Please refer to their [documentation][manifest-doc]
- if [ -n "$LOCAL_GITLAB_HTTPS_HOST" ]; then export LOCAL_CI_REPOSITORY_URL="https://gitlab-ci-token:${CI_JOB_TOKEN}@${LOCAL_GITLAB_HTTPS_HOST}/${CI_PROJECT_PATH}"; fi
- if [ -n "$LOCAL_GIT_MIRROR" ]; then export LOCAL_CI_REPOSITORY_URL="${LOCAL_GIT_MIRROR}/${CI_PROJECT_PATH}"; fi
- echo "Using repository at $LOCAL_CI_REPOSITORY_URL"
- git diff --exit-code -- ${IDF_TARGET}/esp_efuse_table.c || { echo 'Differences found for ${IDF_TARGET} target. Please run idf.py efuse-common-table and commit the changes.'; exit 1; }
- git diff --exit-code -- ${IDF_TARGET}/esp_efuse_table.c || { echo 'Differences found for ${IDF_TARGET} target. Please run make efuse_common_table or idf.py efuse-common-table and commit the changes.'; exit 1; }
@@ -10,7 +10,8 @@ _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.
@@ -39,5 +40,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.
The following table shows ESP-IDF support of Espressif SoCs where ![alt text][preview] and ![alt text][supported] denote preview status and support, respectively. In preview status the build is not yet enabled and some crucial parts could be missing (like documentation, datasheet). Please use an ESP-IDF release where the desired SoC is already supported.
There are variants of revisions for a series of chips. See [Compatibility Between ESP-IDF Releases and Revisions of Espressif SoCs](https://github.com/espressif/esp-idf/blob/master/COMPATIBILITY.md) for the details of the compatibility between ESP-IDF and chip revisions.
Espressif SoCs released before 2016 (ESP8266 and ESP8285) are supported by [RTOS SDK](https://github.com/espressif/ESP8266_RTOS_SDK) instead.
# Developing With ESP-IDF
@@ -46,9 +31,11 @@ See https://idf.espressif.com/ for links to detailed instructions on how to set
### Non-GitHub forks
ESP-IDF uses relative locations as its submodules URLs ([.gitmodules](.gitmodules)). So they link to GitHub. If ESP-IDF is forked to a Git repository which is not on GitHub, you will need to run the script [tools/set-submodules-to-github.sh](tools/set-submodules-to-github.sh) after git clone.
The script sets absolute URLs for all submodules, allowing `git submodule update --init --recursive` to complete. If cloning ESP-IDF from GitHub, this step is not needed.
ESP-IDF uses relative locations as its submodules URLs ([.gitmodules](.gitmodules)). So they link to GitHub.
If ESP-IDF is forked to a Git repository which is not on GitHub, you will need to run the script
[tools/set-submodules-to-github.sh](tools/set-submodules-to-github.sh) after git clone.
The script sets absolute URLs for all submodules, allowing `git submodule update --init --recursive` to complete.
If cloning ESP-IDF from GitHub, this step is not needed.
## Finding a Project
@@ -83,7 +70,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 +82,7 @@ You don't need to run `idf.py build` before running `idf.py flash`, `idf.py flas
## Viewing Serial Output
The `idf.py monitor` target uses the [esp-idf-monitor tool](https://github.com/espressif/esp-idf-monitor) to display serial output from Espressif SoCs. esp-idf-monitor also has a range of features to decode crash output and interact with the device. [Check the documentation page for details](https://docs.espressif.com/projects/esp-idf/en/latest/get-started/idf-monitor.html).
The `idf.py monitor` target uses the [idf_monitor tool](https://docs.espressif.com/projects/esp-idf/en/latest/get-started/idf-monitor.html) to display serial output from Espressif SoCs. idf_monitor also has a range of features to decode crash output and interact with the device. [Check the documentation page for details](https://docs.espressif.com/projects/esp-idf/en/latest/get-started/idf-monitor.html).
Exit the monitor by typing Ctrl-].
@@ -124,8 +111,6 @@ This can be combined with other targets, ie `idf.py -p PORT erase-flash flash` w
* Documentation for the latest version: https://docs.espressif.com/projects/esp-idf/. This documentation is built from the [docs directory](docs) of this repository.
* [Beginner's Guide to Key Concepts and Resources of ESP-IDF](https://youtu.be/J8zc8mMNKtc?feature=shared)
* The [esp32.com forum](https://esp32.com/) is a place to ask questions and find community resources.
* [Check the Issues section on github](https://github.com/espressif/esp-idf/issues) if you find a bug or have a feature request. Please check existing Issues before opening a new one.
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,36 +19,58 @@ Support period is divided into "Service" and "Maintenance" period:
| Service | 12 months | Yes |
| Maintenance | 18 months | No |
During the Service period, bugfixes releases are more frequent. In some cases, support for new features may be added during the Service period (this is reserved for features which are needed to meet particular regulatory requirements or standards for new products, and which carry a very low risk of introducing regressions.)
During the Service period, bugfixes releases are more frequent. In some cases,
support for new features may be added during the Service period (this is
reserved for features which are needed to meet particular regulatory
requirements or standards for new products, and which carry a very low risk of
introducing regressions.)
During the Maintenance period, the version is still supported but only bugfixes for high severity issues or security issues will be applied.
During the Maintenance period, the version is still supported but only bugfixes
for high severity issues or security issues will be applied.
Using an “In Service” version is recommended when starting a new project.
Users are encouraged to upgrade all projects to a newer ESP-IDF release before the support period finishes and the release becomes End of Life (EOL). It is our policy to not continue fixing bugs in End of Life releases.
Users are encouraged to upgrade all projects to a newer ESP-IDF release before
the support period finishes and the release becomes End of Life (EOL). It is our
policy to not continue fixing bugs in End of Life releases.
Pre-release versions (betas, previews, `-rc` and `-dev` versions, etc) are not covered by any support period. Sometimes a particular feature is marked as "Preview" in a release, which means it is also not covered by the support period.
Pre-release versions (betas, previews, `-rc` and `-dev` versions, etc)
are not covered by any support period. Sometimes a particular feature is
marked as "Preview" in a release, which means it is also not covered
by the support period.
ESP-IDF should be used in an up-to-date software environment. The operating system and other third-party tools should be supported by their maintainers. ESP-IDF cannot keep compatibility with unsupported third-party tools.
ESP-IDF should be used in an up-to-date software environment. The operating system
and other third-party tools should be supported by their maintainers.
ESP-IDF cannot keep compatibility with unsupported third-party tools.
The ESP-IDF Programming Guide has information about the [different versions of ESP-IDF](https://docs.espressif.com/projects/esp-idf/en/latest/versions.html) (major, minor, bugfix, etc).
The ESP-IDF Programming Guide has information about the
[different versions of ESP-IDF](https://docs.espressif.com/projects/esp-idf/en/latest/versions.html)
(major, minor, bugfix, etc).
Example
-------
ESP-IDF V3.3 was released in September 2019. It was supported for 30 months until February 2022.
ESP-IDF V3.3 was released in September 2019. It will be supported for 30 months
until February 2022.
- The first V3.3 release was `v3.3` in September 2019.
- The ESP-IDF team continues to backport bug fixes, security fixes, etc to the release branch `release/v3.3`.
- Periodically stable bugfix releases are created from the release branch. For example `v3.3.1`, `v3.3.2`, etc. Users are encouraged to always update to the latest bugfix release.
-V3.3 bugfix releases continue until February 2022, when all V3.3.x releases become End of Life.
- The ESP-IDF team continues to backport bug fixes, security fixes,
etc to the release branch `release/v3.3`.
-Periodically stable bugfix releases are created from the release
branch. For example `v3.3.1`, `v3.3.2`, etc. Users are encouraged to
always update to the latest bugfix release.
- V3.3 bugfix releases continue until February 2022, when all V3.3.x
releases become End of Life.
Existing Releases
-----------------
ESP-IDF release V4.1 and all newer releases will follow this support period policy. The support period for each release will be announced when the release is made.
ESP-IDF release V4.1 and all newer releases will follow this support period
policy. The support period for each release will be announced when the release
is made.
For releases made before the current support period policy was announced, the original support periods apply:
For releases made before the current support period policy was announced, the
original support periods apply:
* ESP-IDF V4.0.x will be supported until October 2021
* ESP-IDF V3.3.x will be supported until February 2022
@@ -54,5 +79,8 @@ For releases made before the current support period policy was announced, the or
Policy History
--------------
* September 2019. This policy splits ESP-IDF releases into Standard and Long Term Support.
* July 2020. All releases from now will have the same support period, which is equal to the previous Long Term Support period. Added “In Service” period, during which versions will receive more updates.
* September 2019. This policy split ESP-IDF releases into Standard and Long Term
Support.
* July 2020. All releases from now will have the same support period, which is
equal to the previous Long Term Support period. Added “In Service” period,
@@ -8,9 +8,16 @@ This document contains details about what the core components are, what they con
The core components are organized into two groups.
The first group (referred to as `G0`) includes `hal`, `arch` (where `arch` is either `riscv` or `xtensa` depending on the chip), `esp_rom`, `esp_common`, and `soc`. This group contains information about and provides low-level access to the underlying hardware. In the case of `esp_common`, it contains hardware-agnostic code and utilities. These components may have dependencies on each other within the group, but outside dependencies should be minimized. The reason for this approach is that these components are fundamental, and many other components may require them. Ideally, the dependency relationship only goes one way, making it easier for this group to be usable in other projects.
The first group (referred to as `G0` from now on) contains `hal`, `xtensa` and `riscv` (referred to as `arch` components from now on), `esp_rom`, `esp_common`, and `soc`. This
group contain information about and low-level access to underlying hardware; or in the case of `esp_common`, hardware-agnostic code and utilities.
These components can depend on each other, but as much as possible have no dependencies outside the group. The reason for this is that, due to the
nature of what these components contain, the likelihood is high that a lot of other components will require these. Ideally, then, the dependency
relationship only goes one way. This makes it easier for these components, as a group, to be usable in another project. One can conceivably implement
a competing SDK to ESP-IDF on top of these components.
The second group (referred to as `G1`) operates at a higher level than the first group. `G1` includes the components `esp_hw_support`, `esp_system`, `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.
The second group (referred to as `G1` from now on) sits at a higher level than the first group. This group contains the components `esp_hw_support`, `esp_system`, `newlib`, `spi_flash`,
`freertos`, `log`, and `heap`. Like the first group, circular dependencies within the group are allowed; and being at a higher level, dependency on the first group
is allowed. These components represent software mechanisms essential to building other components.
## Descriptions
@@ -25,7 +32,7 @@ into routines that achieve a meaningful action or state of the peripheral.
Example:
-`spi_flash_ll_set_address` is a low-level function part of the hardware abstraction `spi_flash_hal_read_block`
-`spi_flash_ll_set_address` is a low-level function part of the hardware abstraction `spi_flash_hal_read_block`
#### `arch`
@@ -34,19 +41,19 @@ This can also contain files provided by the architecture vendor.
Example:
-`xt_set_exception_handler`
-`rv_utils_intr_enable`
-`ERI_PERFMON_MAX`
-`xt_set_exception_handler`
-`riscv_global_interrupts_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).
Contains hardware-agnostic definitions, constants, macros, utilities, 'pure' and/or algorithmic functions that is useable by all other components (that is, barring there being a more appropriate component to put them in).
Example:
-`BIT(nr)` and other bit manipulation utilities in the future
-`IDF_DEPRECATED(REASON)`
-`ESP_IDF_VERSION_MAJOR`
-`BIT(nr)` and other bit manipulation utilities in the future
-`IDF_DEPRECATED(REASON)`
-`ESP_IDF_VERSION_MAJOR`
#### `soc`
@@ -54,9 +61,9 @@ Contains description of the underlying hardware: register structure, addresses,
Example:
-`DR_REG_DPORT_BASE`
-`SOC_MCPWM_SUPPORTED`
-`uart_dev_s`
-`DR_REG_DPORT_BASE`
-`SOC_MCPWM_SUPPORTED`
-`uart_dev_s`
#### `esp_rom`
@@ -64,8 +71,8 @@ Contains headers, linker scripts, abstraction layer, patches, and other related
Example:
-`esp32.rom.eco3.ld`
-`rom/aes.h`
-`esp32.rom.eco3.ld`
-`rom/aes.h`
### `G1` Components
@@ -85,26 +92,14 @@ Logging library.
Heap implementation.
#### `esp_libc`
#### `newlib`
Some functions n the standard library are implemented here, especially those needing other `G1` components.
Example:
-`malloc` is implemented in terms of the component `heap`'s functions
-`gettimeofday` is implemented in terms of system time in `esp_system`
#### `esp_mm`
Memory management. Currently, this encompasses:
- Memory mapping for MMU supported memories
- Memory synchronisation via Cache
- Utils such as APIs to convert between virtual address and physical address
#### `esp_psram`
Contains implementation of PSRAM services
-`malloc` is implemented in terms of the component `heap`'s functions
-`gettimeofday` is implemented in terms of system time in `esp_system`
#### `esp_system`
@@ -112,10 +107,10 @@ Contains implementation of system services and controls system behavior. The imp
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
- Startup and initialization
- Panic and debug
- Reset and reset reason
- Task and interrupt watchdogs
#### `esp_hw_support`
@@ -123,19 +118,19 @@ Contains implementations that provide hardware operations, arbitration, or resou
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.
// 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.
@@ -119,29 +110,6 @@ extern "C" { /* Make sure we have C-declarations in C++ programs */
#define SEGGER_MIN(a,b) (((a) < (b)) ? (a) : (b))
#define SEGGER_MAX(a,b) (((a) > (b)) ? (a) : (b))
#ifndef SEGGER_USE_PARA // Some compiler complain about unused parameters.
#define SEGGER_USE_PARA(Para) (void)Para // This works for most compilers.
#endif
#define SEGGER_ADDR2PTR(Type, Addr) (/*lint -e(923) -e(9078)*/((Type*)((PTR_ADDR)(Addr)))) // Allow cast from address to pointer.
#define SEGGER_PTR2ADDR(p) (/*lint -e(923) -e(9078)*/((PTR_ADDR)(p))) // Allow cast from pointer to address.
#define SEGGER_PTR2PTR(Type, p) (/*lint -e(740) -e(826) -e(9079) -e(9087)*/((Type*)(p))) // Allow cast from one pointer type to another (ignore different size).
SEGGER_BUFFER_DESC*pBufferDesc;// Buffer descriptor to use for output.
void(*pfFlush)(SEGGER_SNPRINTF_CONTEXT*pContext);// Callback executed once the buffer is full. Callback decides if the buffer gets cleared to store more or not.
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. Flags[31:24] are used for validity check and must be zero. Flags[23:2] are reserved for future use. Flags[1:0] = RTT operating mode.
unsignedFlags;// Contains configuration flags
}SEGGER_RTT_BUFFER_UP;
//
@@ -337,7 +106,7 @@ typedef struct {
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. Flags[31:24] are used for validity check and must be zero. Flags[23:2] are reserved for future use. Flags[1:0] = RTT operating mode.
unsignedFlags;// Contains configuration flags
}SEGGER_RTT_BUFFER_DOWN;
//
@@ -351,9 +120,6 @@ typedef struct {
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_RTT_HASDATA_UP(n) (((SEGGER_RTT_BUFFER_UP*)((uintptr_t)&_SEGGER_RTT.aUp[n] + SEGGER_RTT_UNCACHED_OFF))->WrOff - ((SEGGER_RTT_BUFFER_UP*)((uintptr_t)&_SEGGER_RTT.aUp[n] + SEGGER_RTT_UNCACHED_OFF))->RdOff) // Access uncached to make sure we see changes made by the J-Link side and all of our changes go into HW directly
// Operating modes. Define behavior if buffer is full (not enough space for entire message)
//
#define SEGGER_RTT_MODE_NO_BLOCK_SKIP (0) // Skip. Do not block, output nothing. (Default)
#define SEGGER_RTT_MODE_NO_BLOCK_TRIM (1) // Trim: Do not block, output as much as fits.
#define SEGGER_RTT_MODE_BLOCK_IF_FIFO_FULL (2) // Block: Wait until there is space in the buffer.
#define SEGGER_RTT_MODE_MASK (3)
#define SEGGER_RTT_MODE_NO_BLOCK_SKIP (0U) // Skip. Do not block, output nothing. (Default)
#define SEGGER_RTT_MODE_NO_BLOCK_TRIM (1U) // Trim: Do not block, output as much as fits.
#define SEGGER_RTT_MODE_BLOCK_IF_FIFO_FULL (2U) // Block: Wait until there is space in the buffer.
#define SEGGER_RTT_MODE_MASK (3U)
//
// Control sequences, based on ANSI.
// Can be used to control color, and clear the screen
//
#define RTT_CTRL_RESET "\x1B[0m" // Reset to default colors
#define RTT_CTRL_CLEAR "\x1B[2J" // Clear screen, reposition cursor to top left
#define RTT_CTRL_RESET "[0m" // Reset to default colors
#define RTT_CTRL_CLEAR "[2J" // Clear screen, reposition cursor to top left
#define RTT_CTRL_TEXT_BLACK "\x1B[2;30m"
#define RTT_CTRL_TEXT_RED "\x1B[2;31m"
#define RTT_CTRL_TEXT_GREEN "\x1B[2;32m"
#define RTT_CTRL_TEXT_YELLOW "\x1B[2;33m"
#define RTT_CTRL_TEXT_BLUE "\x1B[2;34m"
#define RTT_CTRL_TEXT_MAGENTA "\x1B[2;35m"
#define RTT_CTRL_TEXT_CYAN "\x1B[2;36m"
#define RTT_CTRL_TEXT_WHITE "\x1B[2;37m"
#define RTT_CTRL_TEXT_BLACK "[2;30m"
#define RTT_CTRL_TEXT_RED "[2;31m"
#define RTT_CTRL_TEXT_GREEN "[2;32m"
#define RTT_CTRL_TEXT_YELLOW "[2;33m"
#define RTT_CTRL_TEXT_BLUE "[2;34m"
#define RTT_CTRL_TEXT_MAGENTA "[2;35m"
#define RTT_CTRL_TEXT_CYAN "[2;36m"
#define RTT_CTRL_TEXT_WHITE "[2;37m"
#define RTT_CTRL_TEXT_BRIGHT_BLACK "\x1B[1;30m"
#define RTT_CTRL_TEXT_BRIGHT_RED "\x1B[1;31m"
#define RTT_CTRL_TEXT_BRIGHT_GREEN "\x1B[1;32m"
#define RTT_CTRL_TEXT_BRIGHT_YELLOW "\x1B[1;33m"
#define RTT_CTRL_TEXT_BRIGHT_BLUE "\x1B[1;34m"
#define RTT_CTRL_TEXT_BRIGHT_MAGENTA "\x1B[1;35m"
#define RTT_CTRL_TEXT_BRIGHT_CYAN "\x1B[1;36m"
#define RTT_CTRL_TEXT_BRIGHT_WHITE "\x1B[1;37m"
#define RTT_CTRL_TEXT_BRIGHT_BLACK "[1;30m"
#define RTT_CTRL_TEXT_BRIGHT_RED "[1;31m"
#define RTT_CTRL_TEXT_BRIGHT_GREEN "[1;32m"
#define RTT_CTRL_TEXT_BRIGHT_YELLOW "[1;33m"
#define RTT_CTRL_TEXT_BRIGHT_BLUE "[1;34m"
#define RTT_CTRL_TEXT_BRIGHT_MAGENTA "[1;35m"
#define RTT_CTRL_TEXT_BRIGHT_CYAN "[1;36m"
#define RTT_CTRL_TEXT_BRIGHT_WHITE "[1;37m"
#define RTT_CTRL_BG_BLACK "\x1B[24;40m"
#define RTT_CTRL_BG_RED "\x1B[24;41m"
#define RTT_CTRL_BG_GREEN "\x1B[24;42m"
#define RTT_CTRL_BG_YELLOW "\x1B[24;43m"
#define RTT_CTRL_BG_BLUE "\x1B[24;44m"
#define RTT_CTRL_BG_MAGENTA "\x1B[24;45m"
#define RTT_CTRL_BG_CYAN "\x1B[24;46m"
#define RTT_CTRL_BG_WHITE "\x1B[24;47m"
#define RTT_CTRL_BG_BLACK "[24;40m"
#define RTT_CTRL_BG_RED "[24;41m"
#define RTT_CTRL_BG_GREEN "[24;42m"
#define RTT_CTRL_BG_YELLOW "[24;43m"
#define RTT_CTRL_BG_BLUE "[24;44m"
#define RTT_CTRL_BG_MAGENTA "[24;45m"
#define RTT_CTRL_BG_CYAN "[24;46m"
#define RTT_CTRL_BG_WHITE "[24;47m"
#define RTT_CTRL_BG_BRIGHT_BLACK "\x1B[4;40m"
#define RTT_CTRL_BG_BRIGHT_RED "\x1B[4;41m"
#define RTT_CTRL_BG_BRIGHT_GREEN "\x1B[4;42m"
#define RTT_CTRL_BG_BRIGHT_YELLOW "\x1B[4;43m"
#define RTT_CTRL_BG_BRIGHT_BLUE "\x1B[4;44m"
#define RTT_CTRL_BG_BRIGHT_MAGENTA "\x1B[4;45m"
#define RTT_CTRL_BG_BRIGHT_CYAN "\x1B[4;46m"
#define RTT_CTRL_BG_BRIGHT_WHITE "\x1B[4;47m"
#define RTT_CTRL_BG_BRIGHT_BLACK "[4;40m"
#define RTT_CTRL_BG_BRIGHT_RED "[4;41m"
#define RTT_CTRL_BG_BRIGHT_GREEN "[4;42m"
#define RTT_CTRL_BG_BRIGHT_YELLOW "[4;43m"
#define RTT_CTRL_BG_BRIGHT_BLUE "[4;44m"
#define RTT_CTRL_BG_BRIGHT_MAGENTA "[4;45m"
#define RTT_CTRL_BG_BRIGHT_CYAN "[4;46m"
#define RTT_CTRL_BG_BRIGHT_WHITE "[4;47m"
#endif
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.
