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

Unable to connect to our product from one particular phone

Hi

After doing a rebuild of a previously working project, my personal phone and a test phone is unable to connect to our product.

The device is discovered by the phone without a problem, but always times out when trying to connect. This happens from our app and from nRF Connect:

nRF Connect, 2020-02-08
Nordic_HRM (FD:B1:75:DE:F5:1A)
D    22:33:32.630    gatt.close()
D    22:33:32.632    wait(200)
V    22:33:32.834    Connecting to FD:B1:75:DE:F5:1A...
D    22:33:32.834    gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE, preferred PHY = LE 1M)
D    22:34:02.844    [Callback] Connection state changed with status: 133 and new state: DISCONNECTED (0)
E    22:34:02.844    Error 133 (0x85): GATT ERROR
I    22:34:02.844    Disconnected

I have used the nrf sniffer with Wireshark, and I can't see a single packet from my phone when it is trying to connect to the device. The phone can connect to the previous version of our firmware on our device and on the PCA10040 kits. It work from other phones.

If I use the unmodified ble_app_hrs examples on a PCA10040, I get the same behaviour. I can't connect from my phone, but it work from other phones.

I honestly have no idea what can be wrong, and I have spent a lot of time to try to understand this.

Does anybody have a clue? It is hard to say that there is something wrong with the Nordic stuff since it works on other phones, at the same time it is strange that my phone should be picky about this particular build since old builds and other devices with just fine with it. Is there anything I can reset to shake this out?

Environment

My phone is a Google Pixel (G-2PW4100) running Android 10.

The test phone is an 3 year old Samsung phone, running something older than Android 10.

I'm building the firmware with SES 4.40, I'm not quite sure which version we used to build the original firmware with.

The original firmware is built with SDK 15.0.0 and we used the same for our DFU build.

  • Call this a case of rubber ducking, but while thinking about my setup, I realized that my phone is in developer mode. In a desperate move I tried to turn it off and then everything just work again. This also applies to the other test phone. It is not available for me now, so I can't test the same resolution there.

    After turning developer mode back on, it still work.

    I'm not sure how relevant this issue is for this forum now, but it is also a little bit intriguing why it refused to connect to any recently compiled firmwares, original Nordic or not.

  • I spoke too soon, now I can't connect. I tried to enable developer mode, but even if I disabled it against it doesn't work. Tried to reboot the phone without it helping.

  • Hi Trygve

    What changes have you made to this rebuild of your project except adding DFU? Are there any differences in I.E. the advertising_init() function of your new build? Are pairing and bonding included in your application? In that case, do you delete bonding information on both the phone side and the nRF side when disconnecting the devices? If the bonding information is just erased on one side there will be connection issues when the devices try to reconnect.

    Using a later SES version should not cause any problems AFAIK. 

    Best regards,

    Simon

  • Hi

    There shouldn't be any changes in the firmware, but I can't be entirely sure.

    To be sure I have also done a rebuild the exact same versions (however with a new SES) as the current production hex, and these new builds of old code also have the same problem.

    This application does not use bonds or pairing. I do a full flash erase when testing. I'm not sure if I can reset anything on the phone side. The nRF connect app only shows bonds to my headset and other devices.

    Note that this also happens with an erased flash and the ble_app_hrs hex bundled with SDK 16.0.0.

  • Hi

    We just tested on a Pixel phone ourselves (not in developer mode) and had no issues connecting to the ble_app_hrs example from SDK16.0.0. I will ask the nRFConnect app developers tomorrow if they have seen something like this before, but I don't see why it would be an issue to use the nRFConnect app in developer mode. Please tell me if there are any other details you can think of that might cause this. 

    You can try flashing the ble_app_hrs.hex file onto the chip using another IDE than SES or the nRFConnect for desktop Programmer app just to make sure that's not the problem. This is a long-shot though, but worth a shot I guess.

    Best regards,

    Simon

Related