Previously, condition_4 was making impossible the valid scenario
start > heap_start && end == heap_end.
Now, the end == heap_end and start == heap_start case is handled
separately allowing the case start > heap_start && ned == heap_end
to be considered a valid scenario
Regression was introduced in 32408b718f, which disallowed
addition of heap region with following condition:
`new_start < start && new_end == start`
This caused issues in Bluetooth APIs `esp_bt_mem_release` or `esp_bt_controller_mem_release`.
This commit fixes the problem and also adds API documentation for supported memory address
ranges in heap add region APIs.
A memory region starts from REGION_START and ends at
(REGION_START+SIZE-1).
Prior to this change, the check assumes a to-be-added region starting from REGION_START is invalid. Let's take an easy example:
A memory region: 0x1000~0x10ff
new added region: 0x1000~0x1020
This will be valid.
Valid conditions and invalid conditions are illustrated in the code comment
Problem:
The new API esp_bt_mem_release() that was added freed BTDM data to heap from esp_bt_controller_mem_release().
Now with the BT memory optimization commit ee787085f9,
the BTDM data is optimized and reduced to only 32 bytes which is not sufficient amount to be added to heap.
So, using the API leads to assert saying that the region is too small.
Solution:
Modify heap_caps_add_region_with_caps to return ESP_ERR_INVALID_SIZE in case the range is too small to create a new heap.
Do not assert if return value is ESP_ERR_INVALID_SIZE
This also fixes using API esp_bt_controller_mem_release() with ESP_BT_MODE_BTDM
Signed-off-by: Hrishikesh Dhayagude <hrishi@espressif.com>
No longer necessary to keep all reserved addresses in 'soc'.
Means 'soc' does not need to know about 'bt', for example.
Also means that Bluetooth can be enabled in config without any memory being reserved for BT
controller. Only if code calling the BT controller is linked in, will this memory be reserved...
