HFP stuck after 1 or 2 commands
Posted: Thu Mar 17, 2022 11:04 am
Hello,
I'm using the IDF 4.4 with ADF on a ESP32-LyraTD-MSC_A V2.2 and am facing a problem. After opening a HFP connection to a mobile device I want to use the hfp client functions like esp_hf_client_answer_call, esp_hf_client_dial. Unfortunately they stop working after 1 or 2 uses. I mapped the Buttons on the Board to the functions so I can easily try it out. This happens both in the pipeline_a2dp_sink_and_hfp example from the ADF and in a own program that ONLY uses HFP.
I edited the Button code in the example and my own program to execute HFP functions on press
Expected Behaviour
Interesting behaviours I noticed while inspecting the verbose logs. The first first esp_hf_client_dial ([ * ] CALL) works. The mobile device starts the call, but after that no calls to esp_hf_client_* functions has any effect anymore. As you can see after the first call the btc_transfer_context keeps passing the messages, but never starts handling them (btc_thread_handler) again. This will lead to memory allocations per button press that never get free'ed again as the messages never get handled and no HFP function is ever executed again.
Is the btc_task that should handle the transferred messages somehow frozen?
What might be the reason that the btc_ layer stops handling messages?
Is there a misconception I have about the esp_hf_client_* functions?
How to debug something like that?
Would be awesome if anybody had some kind of input!
I'm using the IDF 4.4 with ADF on a ESP32-LyraTD-MSC_A V2.2 and am facing a problem. After opening a HFP connection to a mobile device I want to use the hfp client functions like esp_hf_client_answer_call, esp_hf_client_dial. Unfortunately they stop working after 1 or 2 uses. I mapped the Buttons on the Board to the functions so I can easily try it out. This happens both in the pipeline_a2dp_sink_and_hfp example from the ADF and in a own program that ONLY uses HFP.
I edited the Button code in the example and my own program to execute HFP functions on press
Code: Select all
if ((int) msg.data == get_input_play_id()) {
ESP_LOGI(TAG, "[ * ] ANSWER Call");
esp_err_t err = esp_hf_client_answer_call();
if (err != ESP_OK) {
ESP_LOGW(TAG, "[ * ] ANSWER Failed");
}
} else if ((int) msg.data == get_input_set_id()) {
ESP_LOGI(TAG, "[ * ] REJECT Call");
esp_err_t err = esp_hf_client_reject_call();
if (err != ESP_OK) {
ESP_LOGW(TAG, "[ * ] REJECT Failed");
}
} else if ((int) msg.data == get_input_volup_id()) {
ESP_LOGI(TAG, "[ * ] VOL 16");
esp_err_t err = esp_hf_client_volume_update(ESP_HF_VOLUME_CONTROL_TARGET_SPK, 16);
if (err != ESP_OK) {
ESP_LOGW(TAG, "[ * ] VOL 16");
}
} else if ((int) msg.data == get_input_voldown_id()) {
ESP_LOGI(TAG, "[ * ] VOL 0");
esp_err_t err = esp_hf_client_volume_update(ESP_HF_VOLUME_CONTROL_TARGET_SPK, 0);
if (err != ESP_OK) {
ESP_LOGW(TAG, "[ * ] VOL 0 Failed");
}
} else if ((int) msg.data == get_input_mode_id()) {
ESP_LOGI(TAG, "[ * ] CALL");
esp_err_t err = esp_hf_client_dial("XXXXXX"); // removed number
if (err != ESP_OK) {
ESP_LOGW(TAG, "[ * ] CALL Failed");
}
}
- Start ESP
- Connect with mobile device
- Press "Mode" button to init call to number
- Press "Set" button to stop call
- Repeat as often as you like
- Start ESP
- Connect with mobile device
- Press "Mode" button to init call to number
- Press "Set" button to stop call
- Doesn't respond to the buttons anymore -> Can't reject calls or init calls anymore
Code: Select all
I (19731) HFP_STREAM_C: --Inband ring state Provided
D (19741) BT_BTC: btc_transfer_context msg 0 10 1 0x0
D (19741) BT_BTC: btc_thread_handler msg 0 10 1 0x0
D (26651) BT_BTC: btc_transfer_context msg 0 8 0 0x3ffbd008
D (26651) BT_BTC: btc_thread_handler msg 0 8 0 0x3ffdfff0
D (26651) BT_BTC: btc_alarm_handler act 0
D (26661) BT_BTC: btc_transfer_context msg 1 7 31 0x3ffdb4f0
D (26661) BT_BTC: btc_thread_handler msg 1 7 31 0x3ffe37f4
D (26661) BT_BTC: btc_dm_upstreams_cback ev: 31
D (26671) BT_BTC: BTA_DM_PM_MODE_CHG_EVT mode:2
I (32831) HFP_EXAMPLE: [ * ] CALL
D (32831) BT_BTC: btc_transfer_context msg 0 17 9 0x3ffca818
D (32831) BT_BTC: btc_thread_handler msg 0 17 9 0x3ffe3dc0
D (33461) BT_BTC: btc_transfer_context msg 1 7 31 0x3ffdb4f0
D (33461) BT_BTC: btc_thread_handler msg 1 7 31 0x3ffe37f4
D (33461) BT_BTC: btc_dm_upstreams_cback ev: 31
D (33471) BT_BTC: BTA_DM_PM_MODE_CHG_EVT mode:0
D (33801) BT_BTC: btc_transfer_context msg 1 17 15 0x3ffdb520
D (33801) BT_BTC: btc_thread_handler msg 1 17 15 0x3ffdfff0
I (33801) HFP_STREAM_C: APP HFP event: AT_RESPONSE
I (33811) HFP_STREAM_C: --AT response event, code 0, cme 0
E (33921) BT_BTM: btm_sco_connected, handle 180
D (33921) BT_BTC: btc_transfer_context msg 1 17 5 0x0
D (33921) BT_BTC: btc_thread_handler msg 1 17 5 0x0
I (33921) HFP_STREAM_C: APP HFP event: AUDIO_STATE_EVT
I (33931) HFP_STREAM_C: --Audio state connected
I (33941) HFP_EXAMPLE: bt_app_hf_client_audio_open type = 0
I (37141) HFP_EXAMPLE: [ * ] REJECT Call
D (37141) BT_BTC: btc_transfer_context msg 0 17 14 0x0
I (43021) HFP_EXAMPLE: [ * ] REJECT Call
D (43021) BT_BTC: btc_transfer_context msg 0 17 14 0x0
I (44341) HFP_EXAMPLE: [ * ] REJECT Call
D (44341) BT_BTC: btc_transfer_context msg 0 17 14 0x0
I (45981) HFP_EXAMPLE: [ * ] REJECT Call
D (45981) BT_BTC: btc_transfer_context msg 0 17 14 0x0
D (48761) BT_BTC: btc_transfer_context msg 1 17 7 0x0
D (48771) BT_BTC: btc_transfer_context msg 1 17 10 0x3ffdb500
I (55461) HFP_EXAMPLE: [ * ] CALL
D (55461) BT_BTC: btc_transfer_context msg 0 17 9 0x3ffca818
D (56131) BT_BTC: btc_transfer_context msg 1 7 31 0x3ffdb4f0
I (57741) HFP_EXAMPLE: [ * ] CALL
D (57741) BT_BTC: btc_transfer_context msg 0 17 9 0x3ffca818
Is the btc_task that should handle the transferred messages somehow frozen?
What might be the reason that the btc_ layer stops handling messages?
Is there a misconception I have about the esp_hf_client_* functions?
How to debug something like that?
Would be awesome if anybody had some kind of input!