E_2M_PHY_PREFERREDE_2M_PHY_PREFERRED
好的，我们来分析一下 CAP_UNICAST_SERVER_ASE_STATE_EVT 从 ASE_STATE_CODEC_CONFIGURED 直接跳到 ASE_STATE_RELEASING 的异常原因。这种现象表明远端设备（你的平板）尝试配置了 Codec，但紧接着发起了释放请求，说明某个关键步骤失败了，连接无法正常进入 QoS 配置和播放状态。这与官方示例的成功流程形成鲜明对比。
以下是最常见的原因和排查方向：
无效的 Codec 配置：
hci_control_le.c 中的 CONTEXT) 在 APP_BLE_Init_User() 中声明的支持能力 (sdp_presentation_format）与平板请求的 Codec 具体参数（如采样率、位深、帧长、通道分配）不完全匹配。ASE_STATE_CODEC_CONFIGURED 之后，协议栈会调用应用层注册的 aics_ctrl_cb.qos_configure 回调函数（在 hci_control_le.c 中通常名为 qos_configure_callback）。你需要在这个回调函数里做：hci_le_set_cig_parameters API（通常在代码中是 hci_le_set_cig_parameters_test）来实际配置连接组 (CIG)。hci_le_accept_iso_chronous_connection_request API（在代码中通常是 hci_le_accept_cis_request）来接受 CIS 连接请求。hci_control_le.c 中 qos_configure_callback 函数的实现：hci_le_set_cig_parameters_test 和 hci_le_accept_cis_request?qos_interval）正确计算并分配了足够大的音频 Buffer？使用 AUDIO_IN_Buffer 类型。SYS_APP_MEM_ALLOC）的返回值。ISO 连接接收失败：
qos_configure 做了部分工作，如果 hci_le_accept_cis_request 没有被调用，或者调用了但参数不正确、时机不当，远端设备就无法成功建立 CIS 连接。hci_le_accept_cis_request 在收到 QoS 配置事件后，在合理的时间内被调用。检查传递给 hci_le_accept_cis_request 的参数（如 cis_conn_handle, ac_latency, max_pdu）是否正确。这些通常需要从收到的参数中提取或根据本地能力确定。资源不足：
FreeRTOSConfig.h 中的 configTOTAL_HEAP_SIZE）。尝试增大 Heap Size。SYS_APP_MEM_ALLOC 使用的内存池大小是否足够 (SYS_APP_MEM_BUFFER_SIZE)。尝试增大该值。aics_ctrl_cb.buf_mem_pool 相关分配）是否成功。在调用分配后增加打印或断言检查返回值是否为 NULL。Audio Clock 与 ISO Interval 不一致：
qos_configured 事件中传递的 qos_interval (即每个 ISO PDU 的间隔) 是否与你音频系统的调度和硬件能力兼容。检查 map_specific.c 或类似文件中设置音频定时器的相关计算是否正确。安全配置问题 (CIS Encryption)：
gap_manager.c 中的安全初始化、配对/绑定流程以及 CIS 加密密钥的分发是否正常。在 qos_configure_callback 中，检查 ase_info->cis_conn_handle 所代表的连接的安全状态是否满足加密要求。日志与跟踪：
DBG_LOG_FULL 或 DBG_LOG_SUMMARY_HCI_CMD_EVT)，将其定向到串口输出。hci_control_le.c 的关键流程点（如 ase_state_callback, qos_configure_callback, disconnected_callback, APP_BLE_UserEvtRx）添加详细打印。输出 ASE 状态变化、事件代码、参数值、函数执行流、API 调用结果（如 hci_le_set_cig_parameters_test, hci_le_accept_cis_request 的返回值）、内存分配结果。特别关注 ASE_STATE_RELEASING 事件发生前的最后一个事件和操作是什么。qos_configure_callback 内的执行流和变量值。或者用逻辑分析仪、示波器监控关键信号（如 I²S WS/BCK、GPIO 翻转指示特定函数执行）。诊断步骤建议 (优先级递减)：
hci_control_le.c 中的 ase_state_callback 和 qos_configure_callback 函数与 BLE_Audio_TMAP_Peripheral 示例中对应的函数进行 逐行对比。尤其是 qos_configure_callback 函数中资源分配和关键 API (hci_le_set_cig_parameters_test, hci_le_accept_cis_request) 的调用位置、参数和返回值检查。ase_state_callback 时打印 state 和 ase_info->ase_index。qos_configure_callback 函数：打印参数值；打印调用 SYS_APP_MEM_ALLOC 分配 Buffer 前后的地址（检查是否 NULL）；打印调用 hci_le_set_cig_parameters_test 和 hci_le_accept_cis_request 的位置及其返回值 (ret)。检查 LOG 是否显示确实调用了这两个 API？APP_BLE_Disconnect 或其他异常断开操作被调用。qos_configure_callback 中，添加对 SYS_APP_MEM_ALLOC 返回值是否为 NULL 的检查（增加 ASSERT 或 LOG），确认 Buffer 分配成功。计算实际需要的内存大小是否超过 SYS_APP_MEM_BUFFER_SIZE。configTOTAL_HEAP_SIZE 和 SYS_APP_MEM_BUFFER_SIZE，排除内存不足的可能性。总结： 从 CODEC_CONFIGURED 直接跳到 RELEASING，核心问题几乎可以肯定发生在 qos_configure_callback 及其触发的后续流程（主要是配置 CIG/接受 CIS 请求）中。仔细检查 qos_configure_callback 函数是否正确完整地实现了资源分配（特别是大块 Audio Buffer）、调用 hci_le_set_cig_parameters_test 和 hci_le_accept_cis_request，并成功配置了硬件/软件音频路径是重中之重。内存不足 (Heap/Buffer Pool 太小) 是另一个高发原因。打开详细的 LOG 是定位这类时序和状态机问题的关键手段。坚持对比官方示例的实现细节，几乎总能发现差异点。祝排查顺利！
举报
更多回帖
