'running' - task that was running when execution stopped
'selected' - task that was selected by used in GDB (command "thread <id>")
Note that initially, after the program is interrupted 'selected' == 'running'
When ulp_lp_core_wakeup_main_processor() is called, it sets the
PMU_SW_INT_RAW bit on the HP side. The normal sleep path clears this
bit before re-entering sleep, but esp_wake_stub_sleep() did not, leaving
the wakeup cause sticky. This caused the PMU to immediately re-trigger a
wakeup as soon as sleep was requested from the wake stub, producing a
rapid re-wakeup loop that eventually triggered LP_WDT_SYS resets.
Add a test case that verifies the wake stub can return to sleep correctly
across multiple LP core wakeup cycles without the re-wakeup bug.
Closing https://github.com/espressif/esp-idf/issues/18308
Made-with: Cursor
release/v5.5 still has additional check_readme_links 404s after the
master backport. Update the remaining board and ESP32-P4 API
references so the release branch no longer fails on those URLs.
Made-with: Cursor
The hw-reference/modules-and-boards page was removed from esp-idf docs
and moved to esp-dev-kits. The ESP32-S2-Saola-1 user guide similarly
moved. The configure-builtin-jtag link used the now-obsolete chip-less
stable URL format.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Clarify that MALLOC_CAP_DEFAULT describes a memory capability
rather than the malloc() placement policy, so PSRAM-backed
capability allocations are documented correctly when malloc()
remains internal-only by default.
Closes https://github.com/espressif/esp-idf/issues/18391
Made-with: Cursor
This commit adds additional delays to the stress test where we create
and self-delete tasks on PSRAM. iSuch tasks rely on the kernel creating
a special cleanup task to delete them. Hence, the delays in the main
task allow the cleanup task to bescheduled and the deletion to go
through.
The existing spinlock mechanism possibly has an overlap of memory
operations during multi core execution, as visible in CI testing. When
running the example inter_cpu_critical_section, shared count increment
stops at 299999 instead of reaching 300000, but this only happens
randomly 1 out of 10 times. It is suspected that a memory operation
happens simultaneously from both core, even though spinlock protection
is in place.
To handle this problem, a memory barrier (fence instruction) is added
at critical places during spinlock acquire and release, to ensure that
all memory operations upto that point are completed and synchronised
before proceeding further.
PMP configurations for load and store addresses may
have different permissions (e.g., "R" vs. "RW").
Due to the timing alignment of internal signals, the address
permission check may be incorrectly applied during the second
part of a misaligned access transaction.
As a workaround, insert two instructions (e.g. ADDI/NOP) between
accessing to different memory regions. This spacing avoids the
false permission check caused by signal timing overlap.