assert in BLE_GATTS_EVT_TIMEOUT with newer iOS iPhones

RE: assert in BLE_GATTS_EVT_TIMEOUT with newer iOS iPhones

kunal1234 — Mon, 26 Apr 2021 12:38:25 GMT

Hi rainbow_carpet, yes my issue is solved. See the fix above. I am not working with BLE Mesh.

RE: assert in BLE_GATTS_EVT_TIMEOUT with newer iOS iPhones

Rainbow_carpet — Mon, 26 Apr 2021 03:19:58 GMT

Hi,have you solve your problem? And also I have a small request ,did you have some demo code for develop the buletooth mesh APP for ios?or can you recommond some website or book? Thank you very much,looking forward to your replies!

RE: assert in BLE_GATTS_EVT_TIMEOUT with newer iOS iPhones

Einar Thorsrud — Tue, 20 Apr 2021 17:43:26 GMT

Hi Kunal,

[quote user="kunal1234"]Can you confirm that commenting out these event handling from app_nus_server.c is the right solution?[/quote]

Yes. It is up to you where you handle it, but each event should be handled only once.

RE: assert in BLE_GATTS_EVT_TIMEOUT with newer iOS iPhones

kunal1234 — Tue, 20 Apr 2021 16:13:10 GMT

Hi Einar,

Thank you for the quick reply.

My code execution halted in BLE_GATTS_EVT_TIMEOUT of app_nus_server.c. (not in BLE_GAP_EVT_PHY_UPDATE_REQUEST). From your explanation, I see that these 4 events are handled both in main.c and app_nus_server.c :

BLE_GAP_EVT_PHY_UPDATE_REQUEST,

BLE_GAP_EVT_SEC_PARAMS_REQUEST,

BLE_GATTC_EVT_TIMEOUT,

BLE_GATTS_EVT_TIMEOUT.

I commented them out from app_nus_server.c -> app_nus_server_ble_evt_handler(). I could connect to iphone 11 which was an issue previously.

Can you confirm that commenting out these event handling from app_nus_server.c is the right solution?

Thank you

-Kunal

RE: assert in BLE_GATTS_EVT_TIMEOUT with newer iOS iPhones

Einar Thorsrud — Tue, 20 Apr 2021 15:17:40 GMT

Hi Kunal,

You would only see this on phones which are new enough to support PHY updates.

The debug log shows this when testing with iPhone 11:

<info> app_timer: RTC: initialized.
<info> app: BLE UART central example started.
<info> app: Connecting to target D50087B15257
<info> app: Peripheral connected
<info> app: ATT MTU exchange completed.
<info> app: Ble NUS max data length set to 0xB6(182)
<error> app: ERROR 17 [NRF_ERROR_BUSY] at C:\Users\eith\SDK\nRF5_SDK_16.0.0_98a08e2\examples\other_projects\nrf52-ble-app-uart-relay\app_nus_server.c:287
PC at: 0x00030FE9
<error> app: End of error report

And the relevant code and app_error check is this from app_nus_server.c:

        case BLE_GAP_EVT_PHY_UPDATE_REQUEST:
        {
            NRF_LOG_DEBUG("PHY update request.");
            ble_gap_phys_t const phys =
            {
                .rx_phys = BLE_GAP_PHY_AUTO,
                .tx_phys = BLE_GAP_PHY_AUTO,
            };
            err_code = sd_ble_gap_phy_update(p_ble_evt->evt.gap_evt.conn_handle, &phys);
            APP_ERROR_CHECK(err_code);
        } break;

The reason you get NRF_ERROR_BUSY here is that there is a bug, as the BLE_GAP_EVT_PHY_UPDATE_REQUEST event is not only handled here, but before it was handled by the ble_evt_handler() function in main.c. So essentially the app calls sd_ble_gap_phy_update() for one BLE_GAP_EVT_PHY_UPDATE_REQUEST, and then the second will fail. So the fix is to simply remove the handling of the BLE_GAP_EVT_PHY_UPDATE_REQUEST from once of the places, for instance from app_nus_server.c.

Einar