This commit fixes the issue when trying to allocate memory
with the MALLOC_CAP_EXEC in RTC memory. Prior to the fix,
the heap allocator was returning an address in RTC DRAM.
To fix this issue:
- modified memory_layout.c of the concerned targets to fill the iram_address
field in the rtc entry of the soc_memory_region array properly.
- modified heap component related functions to return IRAM address when
an allocation in RTC memory with MALLOC_CAP_EXEC is requested.
Closes https://github.com/espressif/esp-idf/issues/14835
- Set default value of BT_BLUEDROID_ESP_COEX_VSC to n if software coexistence is not required,
in host-controller combined Bluetooth stack configuration.
In non blocking mode, the read function is expected
to return weather data is available for reading or not.
In case data are available but the size does not match
the expected size, the function read should return whatever
data is available.
Previously, the function was returning -1 with errno set
to EWOULDBLOCK even if the size of data in the buffer was
less than the requested size. It would only return the
available data if the size in the buffer was greater or equal
to the requested size.
The implementation of cdcacm_read is modified to return the avilable
data from the buffer even is the size is lesser than the requested
size.
Although the hardware documentation suggests that SCHED_INFO is only used
for periodic channels, empirical evidence shows that omitting this configuration
on non-periodic channels can cause them to freeze.
Therefore, we set this field for all channels to ensure reliable operation.
In some cases we will need the dma's buffer to be aligned with specific
requirements. This MR add two helper function to split the unaligned
buffer and merge to the origin buffer. The cost is that each unaligned
buffer requires two stash buffers of spilt alignment size. And this
memory should be managed by callers.
Before the change described in
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631393.html it
appeared that inlining built-in GCC function __atomic_test_and_set() was
incorrect. It resulted in a non-atomic write.
For GCC toolchains which do not have such patch yet, this commit fixes
__atomic_test_and_set to be atomic in IDF's builds.
when esp_event_handler_unregister_with_internal cannot take
the loop mutex (e.g., when the handler unregisters itself),
create an event with a special base identifier and add it to
the queue of the corresponding loop to postpone the removal
of the handler from the list at a time when the loop mutex can be
successfully taken.
handler_execute function is looking to match the handler only in the
list of loop events but does not look in the base event handler list
nor the id event handler list. So unless the event handler is
registered to be triggered for all event bases and all event ids of
an event loop, its profiling fields (invoked and time) are not updated
when it is called.
This commit updates the search for the matching handler to also look
in base event list and ID event list.
Closes https://github.com/espressif/esp-idf/issues/15041
- The CMake function esptool_py_partition_needs_encryption() in the esptool_py
component used to mark NVS partition as encrypted, instead it should have marked
the NVS keys partition as encrypted.
Need to use tcpip_api_call() instead of tcpip_callback(), since the
former waits for the tcpip task to complete and thus prevents potential
data races with subsequent TCP/IP tasks.
