On ESP32C2 with BT_CTRL_RUN_IN_FLASH_ONLY, the bt_default linker scheme
routes .iram1 sections to flash_text, causing BLE_LOG_IRAM_ATTR functions
to end up in flash instead of IRAM. Define a dedicated .ble_log_iram1
section for ESP32C2 and route it to iram0_bt_text unconditionally.
(cherry picked from commit a9b93ca0e5)
Co-authored-by: Zhou Xiao <zhouxiao@espressif.com>
- Use __atomic_fetch_add for stat_mgr counters to prevent lost updates
under concurrent ISR/task access (H1)
- Use __atomic_load_n with ACQUIRE ordering for ref_count spin-loops (L1)
- Remove unnecessary BLE_LOG_IRAM_ATTR from ble_log_rt_task since it
calls flash-resident functions and cannot run during flash ops (L3)
- Add parentheses to BLE_LOG_TRANS_FREE_SPACE and BLE_LOG_MAKE_FRAME_META
macro parameters to prevent operator precedence bugs (M6)
(cherry picked from commit 59536316c9)
Co-authored-by: Zhou Xiao <zhouxiao@espressif.com>
- Reorder deinit: stop RT task before destroying peripheral driver to
prevent sending transports to a NULL dev_handle on dual-core (H2)
- Drain remaining queue items in rt_deinit to clean up transport state
- Add atomic flush_in_progress guard to prevent two concurrent
ble_log_flush() callers from deadlocking on ref_count spin-wait (H5)
(cherry picked from commit 1275b78ad6)
Co-authored-by: Zhou Xiao <zhouxiao@espressif.com>
- Handle scheduler-suspended and ISR context in UART redirect path
to prevent xSemaphoreTake crash during light sleep (C1)
- Check uart_driver_install return value before setting inited flag (M1)
- Always clean up SPI device handle in deinit even if acquire_bus fails (M4)
(cherry picked from commit 3f8cfc5b1d)
Co-authored-by: Zhou Xiao <zhouxiao@espressif.com>
During light sleep transitions, the FreeRTOS scheduler is suspended but
xPortInIsrContext() returns false, causing xQueueSend with portMAX_DELAY
to hit a configASSERT. Add a check for taskSCHEDULER_SUSPENDED and use
a non-blocking send with rollback on queue-full to avoid resource leaks.
(cherry picked from commit 92979706d7)
Co-authored-by: Zhou Xiao <zhouxiao@espressif.com>
The minimum length check in `reassemble_and_dispatch()` applied the START packet minimum (`HCI_ACL_PREAMBLE_SIZE + L2CAP_LENGTH_SIZE` = 8 bytes) to **all** ACL packets, including continuation fragments. Continuation fragments only carry the 4-byte ACL preamble (handle + length) with no L2CAP header, so small but valid continuations (5-7 bytes) were incorrectly rejected as "too short."
This caused the first L2CAP PDU in a rapid burst of BLE GATT indications to be silently dropped. The partial reassembly was orphaned, then discarded when the next indication's START fragment arrived, producing:
```
E BT_HCI: ACL packet too short (len=5)
W BT_HCI: reassemble_and_dispatch found unfinished packet for handle with start packet. Dropping old.
```
Parse the ACL preamble first (requires only 4 bytes) to determine the boundary flag, then apply the L2CAP length check only to START packets. Continuation packets are now accepted with the correct minimum of `HCI_ACL_PREAMBLE_SIZE` (4 bytes).
- ESP32-S3 connected to a BLE peripheral that fragments indications at 40 bytes per L2CAP PDU
- Peripheral sends 8+ indications within ~200ms (burst of state changes)
- The final continuation fragment of the first indication is small (5-6 bytes after type stripping)
- 100% reproducible on every burst; confirmed on ESP-IDF 5.5.3, 5.5.4, and 6.0.0
Verified on ESP32-S3 with a Sub-Zero wall oven (SO3050PESP, firmware 8.5):
- **Before fix:** First indication in every burst lost (ACL reassembly failure)
- **After fix:** All indications in burst delivered correctly, including when the final continuation fragment is 5-6 bytes
Closes https://github.com/espressif/esp-idf/issues/18414
