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.

[Rainbow_carpet]

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!

[kunal1234]

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