Regression introduced in commit 79e74e5d5f
It is possible that some FreeRTOS APIs are invoked prior to
scheduler start condition (e.g. flash initialization in unicore mode).
In that condition these asserts should not trigger (scheduler state being yet to be started),
hence changes per this fix.
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.
Closes https://github.com/espressif/esp-idf/issues/4230
Since SPI flash operations can not be performed when the stack is in
external RAM, we need to switch to a different stack when doing a
core dump to flash. This is achieved by a pair of longjmp's, one of
which is crafted manually to jump into a designated function with a
specific stack set up.
The cost of this feature is a bit of IRAM, plus the DRAM required for
the extra stack.
Closes AUD-1355
arg1 = MAX(int64_t arg1, uint64_t arg2) gave the wrong result, if arg1 < 0, it was presented as a larger value.
And ALARM_REG = (uin32_t)arg1. This leads to an infinite loop.
Fixed: both args are int64_t.
Closes: WIFI-1511
1.esp_tls: fail connection if esp_tls_conn_new() timeouts
https://gitlab.espressif.cn:6688/espressif/esp-idf/merge_requests/7397
2.esp32:panic: avoid access cache in panichandler
3.Sync https://gitlab.espressif.cn:6688/espressif/esp-idf/merge_requests/7152
Even if frame->exccause != PANIC_RSN_CACHEERR, it is possible that the cache error interrupt status is set. For example, this may happen due to an invalid cache access in the panic$
Check cache error interrupt status instead of frame->exccause to decide whether to do CPU reset or digital reset.
Also remove unnecessary esp_dport_access_int_pause from esp_cache_err_get_cpuid, since the panic handler already calls
esp_dport_access_int_abort on entry.
