This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF52 Bonding Error 4352 while trying to bond with a COTS Medical Device/wearable

Hi ,

I am working on the nRF52 Dk Kit and running the example code- found on the folder \ble_central_and_peripheral\experimental\ble_app_interactive. This is command line interface , where in the commands are provided through the Terminal (UART Line). When the device try to connect to a COTS Medical device it goes through the connection. The first step being the action of running is to switch on the scan (scan on) and then the device get discovered and then a Connect (connect <addr>) is taken up. But, once the nRF BLE , which is configured as master , in this case initiates a connection,the connection takes place and then it moves to the Bonding stage. The MTU is changed successfully and then the nrf)ble_lesc stage is configured. Then a disconnection of the COTS with the nrf takes place. Wondering, why this is happening? The nrf_ble also has the legacy configuration which is not being used.The peer_manager_handler through up an error namely Procedure:Bonding, error: 4352. The bonding is certainly critical to the connection and would enable the data collected by this device to be streamed across to the nRF based device, and bonding is pausing this and is roadblock.Can someone suggest me the reason and also some hint sor tips to understand or solve this issue?

With Regards,

Samarth.

Parents
  • The MTU is changed successfully

    I see a TON of devices that seem to exchange MTU sucessfully, but the connection drops immediately after that due to the radio not actually supporting higher MTU. Workaround: Use default 23 byte MTU. :-(

    The (OS) software can work with BT4.2 MTU exchange, but the actual radio chip can not.

    Many older Android/Windows machines with BT4.0 seem affected (I don't have iOS stuff here). Newer Android and Windows BT machines with  BT4.2+ hardware seem to work properly.

    TL;DR Try using default 23 byte MTU.

Reply
  • The MTU is changed successfully

    I see a TON of devices that seem to exchange MTU sucessfully, but the connection drops immediately after that due to the radio not actually supporting higher MTU. Workaround: Use default 23 byte MTU. :-(

    The (OS) software can work with BT4.2 MTU exchange, but the actual radio chip can not.

    Many older Android/Windows machines with BT4.0 seem affected (I don't have iOS stuff here). Newer Android and Windows BT machines with  BT4.2+ hardware seem to work properly.

    TL;DR Try using default 23 byte MTU.

Children
No Data
Related