After startup is done and app_main is reached, all calls to
heap_caps_add_region_with_caps (adding a new heap to the list of registered
heaps) will not affect the minimum free heap size value.
For heaps created before startup, this won't apply and their size will
end up being taken into account in the calculation of the minimum.
Any idf.py invocation could hang indefinitely with no output while
spawning an unbounded chain of "idf.py --version" subprocesses,
eventually exhausting system memory.
During init_cli(), idf.py parses the project's dependencies.lock to
vet trusted component-provided idf_ext.py extensions. If the lock
contains a component whose manifest has an "if: idf_version" clause,
evaluating it calls idf-component-manager's _get_idf_version(). Outside
a CMake build the IDF_VERSION environment variable is not set, so that
function falls back to running "idf.py --version" as a subprocess,
which re-enters init_cli() and recurses without bound.
During a normal CMake build the component manager runs as a subprocess
that already has IDF_VERSION in its environment (see build/config.env),
so the fallback is never reached. The recursion happens only because
idf.py runs component-manager code in-process during its own CLI
startup, outside that context.
Seed IDF_VERSION into os.environ early in init_cli(), before any
dependencies.lock parsing, using the subprocess-free
idf_version_from_cmake() helper. This gives in-process component-manager
code the same IDF_VERSION a CMake build would provide.
Replace the eTaskGetState() polling guard in prvTaskDeleteWithCaps()
with a per-core xTaskGetCurrentTaskHandleForCore() check, so the
predicate matches vTaskDelete()'s immediate-vs-deferred decision. This
closes the taskTASK_SCHEDULED_TO_YIELD race against the IDLE-deferred
TCB cleanup on the SMP preview kernel; behaviour is unchanged on the
default IDF kernel and on single-core targets.
A typical scenario is: when XIP on PSRAM enabled, compiler optimization level is Os. Under certain binary layout, boot hangs and backtrace points to `esp_sleep_config_gpio_isolate`.
The root cause is that, during PSRAM initialization, it calls esp_gpio_reserve, which happens to place before the reported function. However, after call, there is no barrier before the clock adjustment in `mspi_timing_enter_low_speed_mode`. The clock gets changed when the cache is still fetching data, resulting in the corrupted data in the end of the cache line.
This commits add spi_flash_disable_cache as a barrier to make sure the cache transactions is finished before the clock switch.
This commit started threaded server to serve multiple clients
simultaneously in individual thread, eliminating the single-threaded
server limitation that caused the device's mid-OTA reconnect to time
out while the previous connection was still being torn down.
SSL is now wrapped per-connection inside the handler thread (in
setup()) so the main accept loop never blocks on a TLS handshake.
Closes IDFCI-3505
(cherry picked from commit 7647d54271)
