assert in BLE_GATTS_EVT_TIMEOUT with newer iOS iPhones

[kunal1234]

Hi, 

I am working with nrf52-ble-app-uart-relay example taken from Nordic Playground github. I have SES IDE,  nRF5_SDK_16.0.0 & nRF52840 DK. The central part of the relay device (nRF52840 DK) polls the status of a peripheral BLE device. The peripheral part of the relay is meant to get connected to a phone to pass on that status. I noticed that Android phones connect well to the relay but iPhone 10 & 11 do not connect to the relay. iPhone7 could connect to the relay device. The issue happens irrespective of whether a peripheral device is connected to the relay device. On debugging, I found that the code hangs at app_nus_server.c -> app_nus_server_ble_evt_handler() -> case BLE_GATTS_EVT_TIMEOUT. It asserts at the APP_ERROR_CHECK() in that case. I printed out the sequence of BLE event IDs in ble_evt_handler() if that helps:

Android phones (works OK):
POWER ON.
BLE eventID= 0x10
BLE eventID= 0x55
BLE eventID= 0x3A
BLE eventID= 0x24
BLE eventID= 0x30
BLE eventID= 0x32
BLE eventID= 0x32
BLE eventID= 0x33
BLE eventID= 0x38

iPhone7 iOS 13.7 (works OK):
POWER ON.
BLE eventID= 0x10
BLE eventID= 0x3A
BLE eventID= 0x24
BLE eventID= 0x23
BLE eventID= 0x24
BLE eventID= 0x50
BLE eventID= 0x50
BLE eventID= 0x50
BLE eventID= 0x50
BLE eventID= 0x50
BLE eventID= 0x50

iPhone10 & 11 iOS14 (hangs while debugging and when not debugging, it constantly resets when trying to connect to the phone):
POWER ON.
BLE eventID= 0x10
BLE eventID= 0x24
BLE eventID= 0x3A
BPOWER ON.
BLE eventID= 0x10
BLE eventID= 0x24
BLE eventID= 0x3A
BPOWER ON.

I used a generic BLE monitor app as well as my custom app on the iPhones to connect to the relay. I think the issue has something to do with failure to comply with iOS' requirements. Can you try to reproduce the issue and suggest a solution? 
Please let me know your test result. Thank you

-Kunal

[Einar Thorsrud]

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

[kunal1234]

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

[Einar Thorsrud]

Hi Kunal,

kunal1234 said:

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

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