The SoC RC_FAST approximation is a nominal figure that can be off by ~10%
from the clock the LP core actually runs at, which made
ulp_lp_core_delay_us() over-delay by up to 9% and the LP core delay test
flake on ESP32-C5 and ESP32-C6.
Use a measured per-target value instead, and fail the build for targets
that have no measured value so that new chips cannot silently inherit a
wrong one.
Configure the shared LCDCAM core clock through guarded LCD and CAM LL APIs,
and unify LCD functional clock LL calls around group IDs across supported targets.
Co-authored-by: Cursor <cursoragent@cursor.com>
The loops waiting for the card to leave its busy state started their yield
backoff at 100 ms. A card is typically busy for a few milliseconds after a
write, so the backoff never fired and every write was followed by hundreds
of back-to-back CMD13 commands. Occupying the host controller like this
slows down unrelated work on both cores, not just the calling task.
Delay between polls instead, starting at CONFIG_SD_READY_POLL_PERIOD_START_US
(100 us) and doubling. Both the delay and the configured start period are
capped at one FreeRTOS tick period, where vTaskDelay() already yields and one
command per tick is not a storm. A typical wait now costs a handful of
commands instead of hundreds.
Applies to sdmmc_wait_for_idle(), sdmmc_init_sd_wait_data_ready() and
read_tuning_block().
Closes https://github.com/espressif/esp-idf/issues/19034
Auto-detect used to pick the first Espressif device, even when it did
not match IDF_TARGET. With several boards attached, flash/monitor could
talk to the wrong chip.
Pass the project target into esptool so unmatched ports are skipped.
Resolve the port after ensure_build_directory() so the target is known.
For monitor on an unconfigured project, probe the connected chip and
pass it directly to idf_monitor without configuring the project.
The Wi-Fi task deletes itself when esp_wifi_deinit() is called, and FreeRTOS
only reclaims its TCB and stack from the idle task afterwards. Test apps that
read the heap right after deinit therefore see that memory as still allocated
and report a leak, most visibly as the eloop unit tests failing on ESP32.
Wait for the idle task at every point where a test deinitialises Wi-Fi
before a leak check, replacing the single-tick delays that only matched what
esp_wifi_deinit() already waits for internally.
(cherry picked from commit bff264775a)
Move 6 trace-related examples (app_trace_basic, app_trace_to_plot,
esp_trace, gcov, sysview_tracing, sysview_tracing_heap_log) from
examples/system/ into a dedicated examples/system/tracing/
subdirectory for better organization.
Update all path references across documentation (en + zh_CN),
build-test-rules, CI configs and component READMEs.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KZAGzon27T12sGbDPPbZ8G
The return value of on_color_trans_done ("whether a high priority task
has been waken up by this function", see esp_lcd_types.h) was discarded
by the SPI backend. A task unblocked from inside the callback (e.g. via
xSemaphoreGiveFromISR) therefore did not get scheduled until the next
FreeRTOS tick, adding up to 10 ms of latency per color transfer with the
default CONFIG_FREERTOS_HZ=100. The i80 backend already honors the
contract (need_yield -> portYIELD_FROM_ISR); do the same here.
