1) In the ESP32-P4 SoC, we have an eFuse to disable the MSPI access
when in download mode. This commit adds relevant soc cap for esp32p4
chip.
2) Added FE related soc caps
3) Removed unwanted cap from soc_caps
4) esp_hw_support: Enable flash encryption related ll APIs for esp32p4
Sphinx would "smartly" format e.g. double dashes into typographically correct entities,
i.e. a long dash unicode character.
This doesnt always work well for our docs were sometimes a double dash could be a python
argument, which when copied would no longer work.
Fixed assert when LLCP instant passed on ESP32-C3 and ESP32-S3(b8f0db9)
Closes BLERP-298, BLERP-299, BLERP-300, BLERP-301, BLERP-310, BLERP-311, and BLERP-312
See merge request espressif/esp-idf!27477
Previously, documentation sections that were only meant for multicore ESP
targets would use tags that depend on CONFIG_FREERTOS_UNICORE or
CONFIG_ESP_SYSTEM_SINGLE_CORE_MODE. This is not ideal as project configuration
can be changed by the user.
This commit updates those tags to use SOC_HP_CPU_HAS_MULTIPLE_CORES which is
always defined in multicore targets regardless of project configuration.
This commit adds a the SOC_HP_CPU_HAS_MULTIPLE_CORES convenience macro to
soc_caps.h. This is a convenience boolean cap to represent whether or not the
target has multiple cores, and is intended to be used when writing docs for
multiple targets.
- This change will introduce a breaking change for SoCs with the HMAC
peripheral. Turning on flash encryption will no longer enable NVS
encryption automatically.
Closes https://github.com/espressif/esp-idf/issues/12549
MR espressif/esp-idf!27436 added sbom manifest file for fatfs,
but the originator is missing a prefix required by SPDX specification.
This results in malformed SPDX sbom files.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
The import_lib example contained a fallback mirror for downloading tinyxml2 sources
but this link was dead. If this mirror was used it would cause the build to fail.
This extension allows running programs in QEMU similar to running
them on a real chip:
- 'idf.py qemu' — builds and runs the program in QEMU. User gets
a QEMU instance launched, and can work with it as a normal QEMU
instance.
- 'idf.py qemu monitor' — same, but QEMU is launched in the
background, and idf_monitor runs in the foreground, showing QEMU
output. Compared to only running 'idf.py qemu' this enables, for
example, automatic backtrace decoding.
- 'idf.py qemu gdb' — launches QEMU in the background and opens an
interactive GDB prompt, connecting it to QEMU.
- 'idf.py qemu --gdb monitor' and 'idf.py gdb' in another shell:
launches QEMU in the background, keeps it suspended until GDB is
connected, and opens idf_monitor. GDB can be used in another shell
to debug the application.
IDF FreeRTOS v10.5.1 no longer accepts out of range xCoreID arguments in
"PinnedToCore" task creation functions when building for single-core. This
commit fixes those violations through ESP-IDF.
This commit does the following:
- removes the xCoreID member from the TCB when building for single-core
- xCoreID is no longer hard set to 0 when calling "PinnedToCore" task creation
functions in single-core
- Tidy up or add missing xCoreID asserts for functions that take xCoreID as an
argument:
- Functions that set/query a variable of a particular core will call
taskVALID_CORE_ID() to ensure ) 0 <= xCoreID < configNUMBER_OF_CORES
- Task creation functions that accept xCoreID also call taskVALID_CORE_ID()
but also allow tskNO_AFFINITY.
- Fix TaskStatus_t
- Remove xCoreID from TaskStatus_t if configTASKLIST_INCLUDE_COREID is not
defined.
- Set xCoreID to 0 when calling vTaskGetInfo() in single-core builds
