esp_restart()/panic_restart() never resets the Digital system (so far required only by the Memprot feature) as there's a typo in the corresponding #define:
it checks CONFIG_ESP_SYSTEM_CONFIG_MEMPROT_FEATURE instead of CONFIG_ESP_SYSTEM_MEMPROT_FEATURE.
Issue fixed.
IDF-4094
The following changes have been made:
1. All FreeRTOS kernel source files are now placed in the
freertos/FreeRTOS-Kernel folder to match with the upstream folder structure.
2. All kernel include files are now placed in freertos/FreeRTOS-Kernel/include.
3. All port files are now placed in freertos/FreeRTOS-Kernel/portable.
4. All additions/customizations are placed in freertos/esp_additions.
5. All other miscellaneous files (README, License files etc.) are moved to
freertos/FreeRTOS-Kernel folder to match with the upstream.
6. Updated esp-cryptoauthlib to latest commit to resolve FreeRTOS
include dependencies.
Signed-off-by: Sudeep Mohanty <sudeep.mohanty@espressif.com>
ringbuf: Fix bug where comparision between a signed and unsigned operand resulted in incorrect free size for no-split/allow-split buffers
Closes IDFGH-5624 and IDFGH-5649
See merge request espressif/esp-idf!15373
Doc/Make Classic BT related document links only visible for ESP32
Closes IDFGH-5008, IDFGH-6022, and AUD-3378
See merge request espressif/esp-idf!15635
esp_http_client: Fix HEAD request will affect the all next HTTP requests unless we close the HTTP request
Closes IDFGH-6098
See merge request espressif/esp-idf!15707
The issue is related to the non-sequential way of description when
such fields going together sequential.
Related to esp32h2 chip for eFuses: MAC_FACTORY and MAC_EXT.
The issue is in wrong indexes of MAC_EXT.
MAC_EXT got indexes like it is joined to MAC_FACTORY.
const esp_efuse_desc_t* ESP_EFUSE_MAC_FACTORY[] = {
&MAC_FACTORY[0],
&MAC_FACTORY[1],
&MAC_FACTORY[2],
&MAC_FACTORY[3],
&MAC_FACTORY[4],
&MAC_FACTORY[5],
NULL
};
const esp_efuse_desc_t* ESP_EFUSE_MAC_EXT[] = {
&MAC_EXT[6],
&MAC_EXT[7],
NULL
};
This commit fixed it to:
const esp_efuse_desc_t* ESP_EFUSE_MAC_EXT[] = {
&MAC_EXT[0],
&MAC_EXT[1],
NULL
};
This commit fixes a bug in no-split and allow-split ring buffers free buffer size calculation.
When the free size available in the buffers less than the size of one item header,
the function prvGetCurMaxSizeNoSplit/AllowSplit() incorrectly returned the maxItemSize instead of 0.
This is due to the comparision between a negative and a positive value
where both operands are treated as unsigned during the comparision operation,
thereby treating the negative operand as a large integer.
Also added new unit tests to test buffer-full and almost-full conditions
where this scenario is likely to be hit.
Closes https://github.com/espressif/esp-idf/issues/7344
Closes https://github.com/espressif/esp-idf/pull/7371
