ESP_GAP_BLE_SCAN_PARAM_SET_COMPLETE_EVT event after esp_ble_gap_set_scan_params()

[foxkeys]

All samples i have found using esp_ble_gap_set_scan_params() rely on ESP_GAP_BLE_SCAN_PARAM_SET_COMPLETE_EVT event in gap callback.
But, i have two questions about this:
1. Is time between esp_ble_gap_set_scan_params and ESP_GAP_BLE_SCAN_PARAM_SET_COMPLETE_EVT limited by any way? If so, which it can be?

2. Is it possible that ESP_GAP_BLE_SCAN_PARAM_SET_COMPLETE_EVT never happens in some circumances? Or it will happen with 100% chance?

[kolban]

Howdy,
Not sure what you mean by the time between executing the request and receiving the response being "limited". Can you clarify what you mean by that.

When you execute a command that is expected to eventually post an event, we should expect that event to always occur ASSUMING we did not get a failure code from the original command. Check the return code from esp_ble_gap_set_scan_params() and if it is not ESP_OK then you won't get an event.

[foxkeys]

When you execute a command that is expected to eventually post an event, we should expect that event to always occur ASSUMING we did not get a failure code from the original command. Check the return code from esp_ble_gap_set_scan_params() and if it is not ESP_OK then you won't get an event.

Ok. So, if esp_ble_gap_set_scan_params() returns ESP_OK then ESP_GAP_BLE_SCAN_PARAM_SET_COMPLETE_EVT will occur with 100% chance. Very good.
But, i'll be happy, if you say where i can find more info about this rule. I'm explain, why this is so important. If event will not occur because of _any_ possible reason - program will hang (waiting this event).

Another question. When this event occur?
What is the maximum time between esp_ble_gap_set_scan_params() call and ESP_GAP_BLE_SCAN_PARAM_SET_COMPLETE_EVT?
What does this time depend on? And, where i can read more about this?

[kolban]

Howdy,
I'm afraid I'm just a user of the SDK and have no more internals knowledge that anyone else. The source is available on Github for the really keen who want to trace through it to see exactly what happens.

It is my understanding, that IF we get a successful return from esp_ble_gap_set_scan_params THEN we should expect to see an event response. Unfortunately it would be wrong for me to say that this happens 100% of the time. Software can contain bugs and even the ESP-IDF has been known to host 1 or 2. I'd give this post another week to see what someone with more knowledge might respond and, if no-one else posts back, consider creating an issue on the ESP-IDF Github with a well written description of the puzzle and, ideally, a small sample illustrating just the problem. Make sure you post the exact versions of all SDKs and toolchains used.

As for the latency, I would expect this in short order.

One thought strikes me. By any chance is there already a scan in progress when you are attempting to change the parameters of the scan? It "may be" that the internals prevent changing parameters when a scan is already happening and you might have to stop scanning, set the properties and restart scanning?

[chegewara]

This should have answer all your questions:
https://github.com/espressif/esp-idf/bl ... .c#L59-L76

[foxkeys]

This should have answer all your questions:
https://github.com/espressif/esp-idf/bl ... .c#L59-L76

Maybe, it answers. Just one little-little problem, find the answers
esp_ble_gap_set_scan_params() does only one thing - it calls "btc_transfer_context" function.
That send message to PID msg.pid = BTC_PID_GAP_BLE;

btc_transfer_context implementation can be found here:
https://github.com/espressif/esp-idf/bl ... btc_task.c
But.
It is just wrapper to btc_task_post(&lmsg, TASK_POST_BLOCKING);
that does
xQueueSend(xBtcQueue, msg, timeout) (where timeout is TASK_POST_BLOCKING)

And? Where to find point where this IPC message received and processed?
Where to find real timeout value? (if you look around in code - TASK_POST_BLOCKING defined as
#define TASK_POST_BLOCKING (portMAX_DELAY)
but, real portMAX_DELAY i can't find. It have more than one definition, and i have no idea, how to find correct. This is beyond my knowledge.
Same - beyond of my knowledge is - how to find correct pair of xQueueSend()
It can be any of xQueueReceive() or xQueuePeek() somewhere

This is why i'm ask this questions here. I hope, there is somebody more experienced here.

[chegewara]

This should be answer to portMAX_DELAY value:
https://github.com/espressif/esp-idf/bl ... #L189-L190

The real time should be very short, few ms, because esp_ble_gap_set_scan_params() only memcpy parameters and then ESP_GAP_BLE_SCAN_PARAM_SET_COMPLETE_EVT is pushed to Queue, picked up and fired, unless Queue is full which shouldnt have happen or is caused by bad code. (last sentence is just my opinion)

[foxkeys]

I did deep investigation of BLE functions and found that any esp_ble_* calls (with callbacks) can fail silently.
So, using esp_ble_* functions you must not rely on callbacks.
At least, you must add some sort of watchdog in app code, and restart (or do anything else) if no callback from bt stack functions in some reasonable time.

There is investigation details below:

1. All esp_ble_* functions use btc_transfer_context() function from btc_task.c

2. This function post message to xBtcQueue processed by xQueueReceive in infinite loop in btc_task() function of btc_task.c module.
And, this is first place where thing can goes wrong (worse, this can happens silently!), because xQueueReceive can return pdFALSE and nothing will happen in this case. At least, freeRTOS docs say this. I don't know in which circumstances this happen. If message left in queue - maybe it will be received next loop iteration. Doesn't matter, because - see next point

3. After message received by btc_task it is processed by appropriate function (for example, btc_ble_set_scan_params() in topic case) and answer will be returned by btc_transfer_context() in backward direction. But. btc_transfer_context() can fail. At least, with BT_STATUS_NOMEM error (it have few GKI_getbuf calls inside).
In this case, no message will be sent back to app task. No callback called. And, this affect any esp_ble_* call because they all using btc_transfer_context().

4. But. Not only btc_transfer_context() can break call silently, but target function it self. For example, esp_ble_gattc_app_register() implemented in BTA_GATTC_AppRegister() function (bta_gattc_api.c) and, this function can silently fail if GKI_getbuf failed. It just have no "else" for this case. And, therefore, ESP_GATTC_REG_EVT will never fired after esp_ble_gattc_app_register() call.
Yes, this require specific circumstances (not enough memory). But, this can be.

And, i suppose, other functions can have other problems with same result - no callback.